[spion]

> You don't think you're maybe contorting yourself to make some of these arguments work?

First of all, I still prefer TypeScript to Python when it comes to language features. So no, I'm not defending my favorite language here - if anything, I'm "attacking" it.

Secondly, I don't really think in terms of defending favorite languages - they all come with strenghts and weaknesses and I think that its important to talk about and acknowledge both aspects even for languages we really enjoy. That's the only way for languages to move forward and improve.

That said, being embedded into an ecosystem for a long time makes us used to its strenghts and desensitised to its weaknesses. This in turn makes it harder for us to really see the ecosystem's standing compared to others.

I'm trying to provide a perspective as someone who has worked in the ecosystem for a long time and has recently started exploring other options.

Are JS package managers better than Python's? Certainly. If you took a sampling of various tools and libraries in Python, would you be far more likely to have them work together than a sampling of various tools in JS? Absolutely.

I'm a relative beginner to Python compared to JS/TS, but I had a chance to work with it more recently. I had no trouble dealing with pip, venvs and poetry. Yes, there were challenges and annoyances but at least it was possible to overcome them with sufficient knowledge. I agree though - Python has long ways to go to improve this.

However, if I compare this with my previous JS experience, its a different order of magnitude. No amount of knowledge would've made styled components work with next's app router - I simply had to start over and make different choices for my SSR framework and UI library (the alternative was to help with Mantine's migration away from Emotion). So what do I do with my other, already well-developed side project that uses Mantine and Next pages router? I can continue to use the pages router, but for how long? Who knows - its not like there is any kind of concept of LTS or even any kind of thought on that topic when it comes to Next.js anyway (e.g. https://github.com/vercel/next.js/discussions/41906)

At the end of the day, IMO the main difference is attitude. There is broad acknowledgement in the Python community about their problems and they're considered important to solve. I don't see anything like that in JS - compatibility and providing continuity is just not something most authors want to think about. Innovation is (still) priority #1

I realize its hard to make a convincing statement about frequency/magnitude/probability/attitude though. Similar examples will exist across ecosystems. What kind of data would convince you that the situation in the JS ecosystem is bad enough that it warrants a priority shift in the community?

[throwitaway1123]

> what do I do with my other, already well-developed side project that uses Mantine and Next pages router? I can continue to use the pages router, but for how long?

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. Generating actual stylesheets at build time is obviously more performant (using Linaria, PandaCSS, Tailwind, CSS Modules, etc).

Even one of Emotion's maintainers proclaimed he was "breaking up with css-in-js" over a year ago [1]. He had this to say (before the app router was even announced): "With CSS-in-JS, there's a lot more that can go wrong, especially when using SSR and/or component libraries. In the Emotion GitHub repository, we receive tons of issues that go like this: I'm using Emotion with server-side rendering and MUI/Mantine/(another Emotion-powered component library) and it's not working because...".

Granted, even if css-in-js solutions are less than ideal, I still think Next should continue to support them for compatibility reasons. Neither of us can predict the future, but I would bet that Vercel will continue to support the pages router given that they have customers to answer to. Money is a powerful motivator.

> At the end of the day, IMO the main difference is attitude.

> I realize its hard to make a convincing statement about frequency/magnitude/probability/attitude though.

Like you said the problem is that it's hard to make a convincing statement about community attitude. All we can do is go back and forth with anecdotal evidence.

You'll speculate about whether or not Vercel will continue to support its pages router, and I'll provide my own anecdotes like the example I gave of InfluxDB (a Go time series database) deprecating its entire database query language on two different occasions, which fundamentally broke the entire product.

> What kind of data would convince you that the situation in the JS ecosystem is bad enough that it warrants a priority shift in the community?

The only data either of us have is anecdata, which is why we're kind of at a standstill here.

[1] https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-...

[spion]

> 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.

[throwitaway1123]

> - can I additively introduce features that are not prone to the issues

> 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

[spion]

> well some guy named 'somedude82' in an unpopular HN post compared it to npm

It implies that the JS ecosystem is well known for behavior just like the InfluxDB example - its the benchmark example of such behavior. That was my point.

> The state of the art has advanced.

Here is where I have the most fundamental disagreement. My position is: "It hasn't advanced significantly because the JS ecosystem wants to restart every time it gets difficult". Well ok, its a bit more complex than that (external pressures from React and other driving force libraries / frameworks), FOMO and all that - but at the end of the day, the actual progress has been very slow.

> This discussion has had the exact opposite effect for me.

I'm sorry about that, and if I think about it I guess discussion didn't do that for me either. In fact if I look at my hacker news history, I was probably arguing the opposite side quite a bit until 2-3 years ago. For me it was probably trying out Rust. Which isn't to say I think Rust is perfect (I'm still not sure that it makes sense to spend any effort thinking about memory management in the vast majority of cases, even with a compiler helping) but it provided a very interesting high-contrast point of comparison for me.

[throwitaway1123]

> It implies that the JS ecosystem is well known for behavior just like the InfluxDB example - its the benchmark example of such behavior. That was my point.

To me it implies that rather than self reflecting and admitting that other ecosystems have their own continuity problems, developers would rather respond with these tired tropes about npm. Sometimes a technology or ecosystem gains a bad initial reputation, and because of the tribalism that's so prevalent in tech, it's hard to dispel these tropes. Before JS it was PHP that was the butt of every joke, despite PHP making massive strides in usability, performance, and security. It took years for developers to stop thinking of PHP as a "fractal of bad design" [1]. JS is struggling with these same reputation problems. But I'm not sure if that random HN comment even warrants this much discussion — it's not like the author provided any actual examples.

> "It hasn't advanced significantly because the JS ecosystem wants to restart every time it gets difficult".

> but at the end of the day, the actual progress has been very slow.

I think you're drastically overestimating the scale of these changes. React hasn't "restarted". You act like the React developers decided to throw out the whole api and add Vue/Svelte style templates or something.

The InfluxDB example I gave you is actually a much better fit for your criticism. A database is nothing if you can't query it, so changing the query language twice is much closer to restarting. And given that they've reintroduced the original query language from version 1 in version 3, not only is actual progress slow, but it's actually a regression rather than a progression. This would be the equivalent of React deprecating hooks, and going back to class components after spending years promoting hooks.

> In fact if I look at my hacker news history, I was probably arguing the opposite side quite a bit until 2-3 years ago. For me it was probably trying out Rust.

Rust is cool and I like that the Rust developers are trying something innovative with the borrow checker, but I don't find my self pining for the rust development experience after having played with it for a bit.

- The compile times can be horrendous.

- Cross compiling is much more complex compared to Go.

- The standard library is lacking a bit (which says a lot coming from a JS developer). I don't expect every language to ship with an http server like JS and Go do, but I remember needing to pull in third party crates for simple things like making an http request, or calculating the shasum of a file. One of the most popular libraries for making http requests has 49 dependencies [2]. The entire async runtime has been outsourced to a third party package (tokio).

- The 6 week release cadence is a bit fast for me, and despite all your talk of standardization, Rust still doesn't have a formal specification [3].

- The 'unsafe' keyword gets thrown around a lot in Rust crates. As a newcomer, my options are to audit every dependency and hope there isn't a memory safety vulnerability, or cross my fingers and hope the packages are of high quality.

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[2] https://crates.io/crates/reqwest/0.11.23/dependencies

[3] https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...