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