Tons of developers coming out of bootcamps (and even a few designers with no coding experience) who know how to string together a few react components but have problems with basic JS.
It's not necessarily bad, it's just higher level coding. What's bad is when these people get hired as engineers.
But even before this evolution much of jQuery was just sugar to make cross-browser problems manageable.
I am not actually aware, I think, of any developer that just knows React but if they exist I suspect they would have an even harder time of it when deprived of their favored framework than those developers back in the day that just knew jQuery.
For those interested in build-time CSS in JS, also called Zero-runtime CSS in JS, you might also want to check out:
- Linaria (https://github.com/callstack/linaria) I use on my personal site. I ran into trouble/bugs trying to integrate it with Notion’s build process; the Webpack/babel bits are very brittle.
- Treat requires that you write the JS that computes your styles in esperare xxx.treat.js files which is annoying from my point of view - I want single file components. (https://seek-oss.github.io/treat/)
- No idea about this one, but it’s more recent. Has some other interesting things in the inspiration section of the README https://github.com/CraigCav/css-zero
It marries in-line style props (like JSXStyle) with SwiftUI style stack views.
It’s very much alpha, on my GitHub.
I hate to be a grumpy puss but using this sounds like a step backwards.
So, engineers working on UI toolkits often reach for CSS code generation to ease maintenance. At first it was all PHP templates. Then it was Sass (206), is a popular purpose-built language for generating CSS which saw a lot of use in the Rails community. Sass is very good at its job because it handles a lot of CSS niceties in nice ways, but it’s a lot of extremely domain specific complexity. A whole new Turing-complete language JUST for CSS? Not ideal.
The next step is to move all the UI definition into a single place, i using a single language that abstracts the underlying HTML/CSS/JS files & semantics. We do that by writing JS, and having a compiler program extract the CSS bits. This gets us ideal performance & ideal maintainability at the cost of build complexity. This is a worth while trade, because in the long run the compiler will get so good that the cost becomes minimal; compare to other ecosystems, for example the Kotlin compiler is quite complex, but I never think about x86 assembly when writing Kotlin.
It's good to have a level of separation between style and content. The problem with HTML and CSS is that often times you need to change your HTML to change the style of your application.
This is because HTML+CSS was meant to be for documents. It took ages to evolve into what we have today and it still has a lot of baggage. Designing apps with it is a hack which became mainstream.
If we want to improve the situation, I think we need a couple of standards to define application content and application style which can be compiled to HTML + CSS (as browsers are probably going to stay around for a bit longer).
Component based libraries (like react) are well placed to do something like this and it would help developers faced with this uneven separation of style, content and markup.
That sounds like a gigantic step backwards, and one which does not follow the example you've mentioned.
The point of Sass was to introduce backwards-incompatible changes to CSS which adds nice human-readable syntactic sugar to CSS. Being turing-complete is besides the point and even it's regular use. In fact, I worked in projects where Sass was introduced just for it's support for nesting and partials alone.
Mixing content and presentation in scripts misses any of the lessons from the last couple of decades. It feels like yet another example of the cargo cult of javascript, where people mindlessly argue that dragging everything into a script solves anything at all.
- 0.7 KB (gzipped)
- Zero dependencies
- High performance ("fast af")
- Deduplicates repeated styles
- Dead-code elimination
- Media queries and pseudoclasses supported
It is closer to https://www.styletron.org/ in that regard.
So reducing the JS "load" is a performance win on the client.
For a big complex app (eg, https://www.notion.so which I work on), a significant fraction of JS code size is spent describing styles. There can also be JS cycles spent doing color math like lighten, darken, hue shifting on base colors, etc. With runtime CSS-in-JS, all of that style JS code must be parsed and executed by the JS runtime on every page load by every user. That’s a lot of CPU time and user wait time multiplied out.
Zero-runtime improves page load performance by moving this extra code from the JS vm to static CSS files. The majority of style computation happens at build time. The CSS can then be downloaded and parsed in parallel with the JS (woo threads?). The separation may improve caching compared to all-JS solution as well, depending on how granular the CSS and JS output files are.
But that was not good either, so welcome buildtime JS generated CSS.
Brilliant!
export const Button = styled.button``;
Why is there a string right after the field "button" of the object "styled"? How is this valid JS? What does it do?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
JS syntactic sugar complexity is getting out of hand.
> How is this valid JS? What does it do?
I'm curious if Python (or a similar whitespace-sensitive syntax) is your first/familiar programming language.
The extra whitespace here does nothing.
The semicolon in JS is an (optional) expression separator, similar to in Bash/Shell. It can occur at the end of a line or at the beginning of a line, or in between lines. Or in between two expressions on a single line. Any whitespace chars before or after it are irrelevant/ignored.
Their question was:
>Why is there a string right after the field "button" of the object "styled"?
which unambiguously refers to the double backtick characters between "styled.button" and the semicolon in this expression:
> export const Button = styled.button``;
That is, in JavaScript, an empty string. There is not whitespace and Python has nothing at all to do with the question. Similarly, an explanation of what a semicolon does in JavaScript does not answer the question.
I also can't answer the question for them as I haven't kept up with newer JavaScript standards, but I thought it important that you realise you misunderstood something here.
i was reading the landing page for a js library and it said something like "battery-pack included", makes me feel kind sick....or maybe i'm just a grumpy sod