Big surprise that using CSS the original way it was supposed to be used... is the most performant. CSS-in-JS has always been a sort of "hack" for me. Sure it's a great DX, but it's really just an abuse of JavaScript to have CSS capabilities "just because we can".
Real-world CSS vs. CSS-in-JS performance comparison
131–140 of 165 posts
Re: Real-world CSS vs. CSS-in-JS performance comparison
#132Earlier quoted context omitted.
Might not be a fair comparison, but there are people who are looking at changing up how their css is written so it makes sense to be aware of the differences in performance.
Definitely should be aware, and I would highly recommend static files over large JS apps. The options are there to have both now with frameworks like Gatsby and Next.
Can confirm from multiple sites, Gatsby with CSS modules runs like lightning
Re: Real-world CSS vs. CSS-in-JS performance comparison
#133Earlier quoted context omitted.
Completely agree. This whole discussion feels silly after a day building things with Tailwind. The system, defaults, docs and tooling are excellent. And dev speed is ludicrous.
Haven't heard of this until now. Looks like a cleaner version of Bootstrap?
It's kind of like bootstrap except it's more focused on the developer building styles instead of having a number of prebuilt styles.
It also is more based on what css can do instead of having it's own abstraction. Most of the class names in Tailwind are very close to their css key+value equivalents. For example if you wanted to write `float: right` in css you'd use the Tailwind class `float-right`.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#134Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?
I've worked on and off with React since its inception, and the main reason I would use it is simple ergonomics. If you are working with an MVP or a small widget project, you gain a lot of velocity. You don't need to worry about scoping, naming collisions, class toggles, etc. and as long as you use decently small components, it all fits snuggly in the same file as the component definition. The price you pay comes in t…
I've found it easier to maintain CSS-in-JS since I know exactly what will be affected when I change it. I'm always scared to touch the .css files on large projects.
I haven't used SCSS modules though.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#135Earlier quoted context omitted.
Fully agree. It's usually the people that have never worked with it that share their opinion, always ending with "why do we need this" Can encourage others to give it a try as well. Dev productivity through the roof indeed :)
Comparing Tailwind with Web Components might be a bit unfair. It is well known that Web Components have terrible dev ergonomics. It would be more fair to compare with frameworks that work with scoped styles (such as Svelte or Vue’s single file components). Developing in these is also an excellent productivity boost.
Can anyone give some references on that Web Components have bad dev ergonomics? Is it just that Web Components don't allow passing of complex types so you have to stringify everything?
Re: Real-world CSS vs. CSS-in-JS performance comparison
#136Great effort and I have no dispute with the methodology. The conclusion, however, is naïve. Specifically this part: "Great developer experience shouldn’t come at the expense of the user experience." Great developer experience can conceivably deliver better user experience. A more capable, responsive and lower defect application that load 10% slower may be a net improvement. I'm not arguing that CSS-in-JS actually del…
I very much agree that load time is not the only metric that should be measured. Unfortunately, it's one of the easiest to measure. It's also one which does not sacrifice any other UX metric like low completion time leading to less satisfaction sort of corruptible metrics. Although, in my experience, usage of react is not indicative of a more capable, responsive, or lower defect application. Quite the opposite (for m…
As someone working predominantly on React sites for the last 4 years or so I absolutely agree. Of course you can write quick, responsive and solid sites with React but it’s not the automatic process some would like you to believe, you still have to try and often the effort required is not trivial. The problem I often find is that optimising React sites needs a bunch of knowledge and skills which are only tangentially and most related to those which you’d use to optimise a more traditional site. This is related to the topic of the OP i think; knowing how to write good css is a skill which css-in-js tries to pretend doesn’t matter but which absolutely does - things like Styled Components effectively enforce certain good practices but don’t remove the need to understand whats going on under the hood in all but the most basic of situations.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#137My gripes with traditional CSS styling are: - Styles are global - Styles are targeted via brittle, untyped, and opaque "magic strings” basically. This means mistakes are more likely to be caught at run time than compile time. Eg, I wouldn't get a compile time error if I did `position: oops` or `class="oops"`. - Styles are often "far away" from their target which makes mistakes more likely; ie this deeply nested HTML…
>"- Styles are global
- Styles are targeted via brittle, untyped, and opaque 'magic strings' basically.
- Styles are often 'far away' from their target which makes mistakes more likely; ie this deeply nested HTML element in one file is coupled to a deeply nested style sheet in another file"
You can get a long way to solving those three issues with good organization, but only if you control your whole project, stick to the plan, and don't have any libraries.
But over the course of a long lived project CSS is a real foot-gun that even well meaning developers will shoot themselves with. It's hard to unweave a tightly woven CSS nest, and once you introduce third party libraries and custom CSS things start to get wild. Who hasn't seen a "custom.css" overriding the "global.css" which was itself just a bandaid to fix an issue with some third party library.
I use a method I called "Contexts and Components". It starts with a reset. 98% of the CSS is inside the component files, and target component classes, eg . But of course things can change depending on what page they're on, and those are called contexts. Maybe a product card on the home-page has a border or whatever. That gives you a way to address client requests for things to differ but without making crazy complicated configurable components.
That way things are really shallow, only one level deep unless they are modified by a context, which makes it two levels deep. I find I need way less CSS, no crazy hard to reason about selectors, and it's all very easy to understand. Best of all, it's easy to remove stuff entirely, so you don't end up with overrides over overrides.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#138Earlier quoted context omitted.
We'll have to agree to disagree.
CSS is not a programming language. I find it hard to believe you think you can do more with plain CSS than with the full power of the Javascript programming language.
Sure CSS isn't a programming language.
However, when used correctly you can create a system that will allow you maintain and apply your presentation layer in an efficient, extensible, consistent and reusable way.
Lack of knowledge isn't an excuse for believing otherwise.
--
Edit: I'm actually shocked by how much bad feeling there is for standard front-end technology.
A domain specific solution is a benefit.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#139Re: Real-world CSS vs. CSS-in-JS performance comparison
#140Earlier quoted context omitted.
Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.
HN randomly mods posts. Don't assume malice.
Could you please explain what you mean?