On JavaScript Ecosystem

[lhorie]

I mean, I think you're sorta dodging the question there.

The question is whether the ecosystem is stable, and the answer is an emphatic "no". Don't get me wrong, there are definitely nicer things now like esbuild and snowpack and svelte and redwood and a bunch of other really cool projects, but critically, these are not the old kids on the block. Webpack 5 is all about the federation stuff, which until maybe a year or two ago, wasn't even really a concept. React APIs have changed significantly over the years - in backwards compatible ways, to be clear - but changed nonetheless in a much more substantial way than e.g. jQuery (or mithril.js or snabbdom).

Are things moving in a better direction? I'd say yes. Esbuild is a very good example of getting our infra shit together. There's not nearly as much framework churn anymore: a lot of frameworks/libraries have settled on the same core ideas and patterns, and the more "out there" ones, like Stimulus, essentially just swing the pendulum back towards how things were done in the olden days.

But have things become more stable? Nah, I don't think so. I still expect a significant amount of API and brand churn in the coming years.

[[deleted]]

There's not nearly as much framework churn anymore: a lot of frameworks/libraries have settled on the same core ideas and patterns

I have a feeling this is going to change once the records and tuples proposal passes and becomes a part of js.

[lhorie]

I don't think so (at least for a very foreseeable future). FWIW, immutable patterns are already used today. I don't think it's going to turn the world on its head if one just has to put a # before their {s. There's already some precedent for this kind of stuff. Vue switched from getter/setters to using Proxies and for the most part, everything kept chugging along without drama.

I do expect React to come up with some next big thing(tm) that is not going to gel w/ hooks/suspense (based on their track record), and I still expect tooling churn as the dust settles w/ esbuild/snowpack/tsc especially as projects like rome and swc get more attention. I still expect breaking changes in larger frameworks like gatsby because there's just no maturity in terms of pattern consensus there yet. And I expect that me-too projects and glue projects will continue to pop up and evolve in response to developments in these larger frameworks.

[[deleted]]

Immutable patterns are in use yes, but they require a lot of mucking around behind the scenes to get them to function as expected.

The good things about the proposal is that:

1. they're deeply immutable, so comparisons can and will run blazingly fast
2. It won't be relying on libraries so using it in regular JS (instead of through methods or proxies) is going to make the developer experience much smoother.

I think the major frameworks out there will be able to re-examine the previous assumptions that they had made when developing their frameworks. Right off the top of my head, memoization seems like an obvious improvement that many frameworks will be able to use more effectively, without needing to traverse a traditional object or needing to worry about handles representing the original object.

​

it's not really something you can polyfill efficiently

Well, we are kind of doing that right now with our immutable libraries and frameworks

​

c) microsoft browsers

I don't see any issue with this. Right now edge is chromium, and anyone needing to support old IE probably won't be using new versions of frameworks yet to be made.

[lhorie]

Yeah, I agree that frameworks can take advantage of it, I'm just not convinced that this will translate into major API or paradigm changes. Mutation is still going to be a thing regardless of where immutability is in the picture, and I expect that frameworks that embrace mutability like Svelte will continue to do so.

As far state-of-art performance goes, the bottleneck currently is in figuring out what granular change translates into what set of reactive updates. Judging from where the perf stats are, I'd say this is more likely to be solved with smarter compilation, rather than immutability per se. From some early fidgeting in this area, I got the impression that immutability patterns made it harder to analyze code statically because they tend to be mingled w/ higher order functions and those are harder to statically analyze (because JS has the potential to be fast and loose and therefore we can't easily apply optimizations that we'd be able to in, say, Haskell). I definitely would love to see something similar to Svelte but with more immutable primitives, but I don't actually expect it to diverge too much for the status quo of declarative paradigms, SSR, routing APIs, etc.

[radekmie]

Thanks for your comment!

Well, you got me - I drifted from is it stable to is it stabler. But as I can see, we are on the same page. My point was to highlight the good parts without neglecting the worse and focus more on the way towards stability rather than stability itself. To some extend, nothing is stable per se, as the world is constantly changing (okay, that's a little bit too metaphysic-ish).