| > I honestly think css-in-js solutions that inject styles into the document head at runtime like Styled Components and Emotion were never really sustainable or performant, and server components just revealed the inadequacy of these techniques. Sure. But here we have one that happens to be used by most popular UI toolkits. Forget about Mantine, it feels like MUI is in every other project. Now again anecdotally, outside of the JS community, the approach and attitude of maintaners would typically be: - how do I make this extremely widely used package have less issues with minimal backward compatibility breakage - can I additively introduce features that are not prone to the issues not "I'm starting over" Just in the article comments there are 5 other people pointing out a variety of issues with the author's new favorite choice. And they're all kinda right - all choices have tradeoffs. That's precisely why only dedication to compatibility and continuity can grow any one of them into something that is still sensible to use while acknowledging its limitations. This is IMO a more sensible approach to software engineering - Start with an approach that is significantly stronger in a certain aspect - Acknowledge its limitations - Work to ameliorate those as much as possible P.S. the article about Emotion is also an example of how React's "no wait, this was always a bad idea because <X>" (where X in this case was concurrent mode) is causing rippling breaking changes. Again, this is their prerogative and at the end of the day, they have their own priorities internally at Facebook. But that's not necessarily healthy for the wider community. Also FWIW, InfluxDB's approach to breaking changes has been compared to "a random npm library" https://news.ycombinator.com/item?id=37206194 > The only data either of us have is anecdata, which is why we're kind of at a standstill here. This discussion has been also been useful for helping me pinpoint what exactly is different about JS when I'm working with it. I'm still hoping I was at least somewhat convincing, because I don't think this is a problem that can be tackled without wider acknowledgement from the JS community. |
> not "I'm starting over"
React and Next DID additively introduce server components. The old way of doing things is not deprecated. Your entire argument is predicated on the idea that the old way of doing things will eventually be supplanted (which is pure speculation).
> P.S. the article about Emotion is also an example of how React's "no wait, this was always a bad idea because <X>" (where X in this case was concurrent mode) is causing rippling breaking changes.
It's not a bad idea because of concurrent mode, it's a bad idea because generating styles at runtime in a user's browser is much slower than building a static css file at compile time and serving it like any other static file. Ironically you want JS to be like every other ecosystem and that's what we're doing (everyone else outside of JS is using Tailwind and static stylesheets), and you're upset about it.
The frontend ecosystem would have done this from the beginning but analyzing components with dynamic styling, and extracting those styles at build time is non-trivial. It's essentially like building a small compiler (Tailwind in fact built a just in time compiler in v2.1). The simplest solution (from an implementation perspective) is to just use JS to dynamically generate styles at runtime and that's what early frameworks like Emotion and Styled Components did. The state of the art has advanced, which as a technology oriented person, I'm ok with. Like I said several comments ago, technology should be stable not frozen. But again, you're allowed to keep using these bloated UI toolkits because server components are optional.
> Also [for what it's worth], InfluxDB's approach to breaking changes has been compared to "a random npm library" https://news.ycombinator.com/item?id=37206194
It's worth very little. I gave you an example of a massive breaking change in another ecosystem and your rejoinder is "well some guy named 'somedude82' in an unpopular HN post compared it to npm". The arguments are getting weaker as this discussion drags on. By the way, I actually read that comment as saying "a paid database product shouldn't be as unstable as a random package". Since we're trotting out supporting HN comments, here's one from this very discussion that disagreed with you about React's stability [1].
> This discussion has been also been useful for helping me pinpoint what exactly is different about JS when I'm working with it.
This discussion has had the exact opposite effect for me. You seem to be willing to excuse any and all flaws in other ecosystems (Python's packaging story, the InfluxDB breaking changes, etc).
[1] https://news.ycombinator.com/item?id=38742422