ecosystem is king
If only the article had dedicated a section to how React trained us that things need to be built specifically for a certain framework, and how no other modern frontend framework is as stubbornly incompatible with the platform as React is.
This isn't really any different from frameworks in general: JQuery had its own massive ecosystem that assumed JQuery was being used; trying to use something from the Rails ecosystem in Padrino was unlikely to work well; Vim vs Emacs; etc etc. Frameworks accumulate ecosystems around them and have since pretty much the beginning of programming — I don't think React has nefariously trained ecosystems into the community; I think people tend to build libraries on top of other libraries they know, and React is popular, so it's the basis for more libraries (the ecosystem).
Less popular platforms will get more isolated rather than less as the wave of generated code that “works out the box” only works with stuff like react…
To elaborate further: I don't believe ecosystem is king. Success can mean different things to different people, and is not always a single dimension of "popularity units".
> I’ve had to deal with a nightmare Elm project. The difference is, I know what I’m doing. I solved all the problems, created examples to lead other devs and everything was fine. Have your company contact me if you need help.
I’ve had to deal with a nightmare React project. The difference is, I know what I’m doing. I solved all the problems, created examples to lead other devs and everything was fine. Have your company contact me if you need help.
shipping as wasm is not an option as it increase bundle size for very little gain (unless you're running something super performance intensive).
We would need a bridge between sane languages and a JS framework, not just JS in general.
5 years ago I would have done a Haskell -> hyperscript bridge to build frontend applications. Today I would do a Rust -> Solid.js bridge to build frontend applications.
Logic could be compiled down to JS, UI could be compiled to Solid.js components.
Source: 7 years of Haskell in production
Not a single bit of "React" in the code. It has absolutely NOTHING to do with React. But I've seen it in projects I've inherited... just because, "we're using React, may as well get the React version of the library".
Likewise Svelte is mature and well understood enough that like React, enough nobody could get fired for choosing it either.
So you refuse to work with people who do not want to re-invent the wheel for a shiny new framework because it is "better"?
if you don't want to reinvent a feature that another framework has a solution for, then i'll ask you to show that this other framework solves more problems than the current one, and it's worth the cost of switching (or switching back).
but, like you, i don't like to switch to a new framework just because it promises to be better.
i prefer to avoid switching frameworks as long as i can. i'll only switch in a project when i run into a problem that the current framework can't solve at all.
Probably because they had already moved on to do the same thing at some other company for more money.