I've been sitting on writing this article for 2 years. In my heart this was the article I was going to write even before I read @swyx's quintessent...
For further actions, you may consider blocking this person and/or reporting abuse
@ryansolid Thank you for another great article Ryan. The only thing that worries me is whether Marko, Solid, Svelte etc. are going to be able to challenge React, as the predominant solution for anything web related.
It's true. But I can't really afford to be pessimistic about it. Otherwise nothing changes or evolves. When I created Solid I wasn't being concerned with that, I just made something that made sense for me with no expectations. And if you go back to the early 2010s there wasn't a single predominate declarative library. It's only been in the past 7 or so years that things consolidated the way they have. Part of it to avoid "JavaScript Fatigue" etc.. And also to provide stability and maturity to the job market. But there was a time not too long ago when you were like, I'm going to build our application in Ember, or Knockout and no one would blink an eye.
Now if you try to suggest not React, your team might accuse you of trying to sabotage their career and be severely jeopardizing their future FAANG hire-ability. Anyone with industry experience it seems almost comical to think that experience wouldn't translate, but then you recognize the real tragedy is they aren't wrong. React supersedes web fundamentals especially in junior to intermediate levels.
So I don't know. This has been my message because it's not that I dislike React. I just think the current state of "ecosystem maturity" is stifling to innovation. It isn't enough that a single other solution checks all the boxes. No we need to surround this ecosystem with many solutions otherwise should it ever be dethroned we just repeat ourselves.
Don't get me wrong I completely agree and I was that person using Knockout and Backbone before all this craziness.
I've met younger developers in their 20s and 30s completely enthralled in React and everything hippie this time around. Same people who are unfortunately completely oblivious how to use HTML or CSS. Moreover, even when it comes to JS they are also completely unready to implement the simplest of algorithms, but instead try to use some obscure library.
But it is also unfortunately true that the market insists on asking for React even if not the fastest or with the best DX. Personally, I have been asked questions about how React operates internally, plus why its the fastest.
I worry if the trend will change and I am all in having all the other options as well e.g. solid, svelte, marko, in case most developers realize where we are heading to, which is a React-ified world, which still lacks commonality, since no two React projects are the same.
@ryansolid by the way, when is Marko hitting v6 :-)???
Things have been coming together. We have basically a big bingo card as we are filling in features right now. We just got end to end hydration tentatively working the last day or so (made our Hackernews Demo). There are still quite a few missing features on the more complex side, including automatic async handling (ie.. what enables streaming) so there is still quite a bit of work. I think when you consider documentation, migration plans, integrations there are lot more moving parts that need to be tackled beyond just implementing this. But since the new year we've been able to focus on this more and have been making good progress.
To bring a somewhat different perspective to this, my concern isn't sabotaging anyone's career progression, but sabotaging my tiny, bootstrapped company's ability to hire within our budget. (Well, in a sense, I'm concerned about my own career, in that I want to be able to get some tasks off my plate.) So, as much as a focus on web fundamentals resonates with me, and I've been watching Solid and (especially) Marko with interest, I may still use React for future projects.
I think this may actually be a cultural/industry issue rather than a technical one.
My jaw dropped when I first ran across this on the Thoughtworks Technology Radar SPA by default Hold:
"We generally avoid putting blips in Hold when we consider that advice too obvious, including blindly following an architectural style without paying attention to trade-offs … Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
i.e. at least even the perception is now bad enough for TW to call it out to their clients (2021 was the first year where React surpassed jQuery in the Stack Overflow Developer Survey as the most used web framework).
Despite of the associated complexity somehow the available tooling has created a "developer comfort zone" (which is ironic because of the continued complaints of how complex everything has become) that potential detrimental effects downstream on the end product are usually ignored (or even denied).
On the surface the SPA-preference can be explained by trying to compete with native applications (in the long run competing on native application's terms is a losing proposition).
The problem: web performance is other people:
"I believe this is why Kroger.com used a SPA in the first place — if disparate teams’ APIs can’t be trusted, at least they won’t affect other teams’ code."
This suggests that SPAs may be (ab)used to keep organizational issues at bay. And perhaps the complexity leads to teams that are larger—possibly large enough that individuals can specialize fairly narrowly where they don't think about any trade-offs that don't affect them directly. Objective analyses of the drawbacks of SPAs aren't nearly as common as the declarations of perceived DX and productivity benefits that SPA frameworks can bring.
The fact that some people seem to treat React as (the future of) the web is more than a bit disconcerting. React's design goal is to enable reuse over the React Web/React Native divide—so React is about React, not the web.
There is no inherent incentive to align with the realities of the web unless it directly benefits React and doesn't interfere with the "Native" end. React's "re-implementing the browser" could be explained by the "Native" end needing whatever is being re-implemented.
To some degree even the Thoughtworks commentary isn't helpful:
"SPAs incur complexity that simply doesn't exist with traditional server-based websites … We believe that many websites will benefit from the simplicity of server-side logic, and we're encouraged"
While Marko, Astro, and Qwik are server-first solutions they are by no means traditional, trying to "go back to the old days". They do not eliminate the need for SPAs where they are appropriate but instead offer an "optimized for the web" alternative for a wide range of applications where SPAs can be an ill fit (or difficult/high effort to get right).
So it's not really about "Marko, Solid, Svelte etc. challenging React" but getting the industry and individual developers to realize that SPAs aren't the one-size-fits-all tool they clearly want them to be and that using them as a golden hammer isn't going to be helpful in the long run.
The educational discussion has been slowly gaining momentum over the past few years but the fact that there is a significant "developer comfort zone" attached to the SPA/React ecosystem means that it is going to take more time and effort.
What we need is a lib or framework that does SPA or MPA all in one. There are cases when we need client-side routing, and cases when we don't, etc, but the average dev would rather not have to switch frameworks just to change those semantics.
Which system gets us closest to having the choice in all four sectors of that graph, with resumable hydration in every case? I think that's where we're going.
Qwik (City) is the one. As you prefaced by mentioning resumability ;-)
Sounds interesting. I don't see the docs mention this though. Can you explain? How do we choose when a route is client side or full-page refresh?
The FAQ explains a bit, just search for SPA and MPA there: qwik.builder.io/docs/faq/
Qwik City apps basically do a full page refresh for every link (MPA style), unless you use their Link component (in which case it does a client side SPA style navigation).
I think there is a more interesting tension. Should be trying to mix SPA and MPA in the same app. This is essentially SvelteKit or Qwik's approach is. What Rich Harris called Transitional Apps. Or should be working on something that has the best aspects of both like I talk about here:
Client-side Routing without the JavaScript
Ryan Carniato for This is Learning ・ Nov 7 '22 ・ 6 min read
So many frameworks to choose is not positive/exciting for developers in JS world, in fact it's a mess. Life is too short to learn all of them or figure out which one fits me the best each month. It's a never ending chase that slows down get-the-job-done, it's a shame.