If you’ve been in web development for more than five minutes, you know the drill. Every few months, a new JavaScript framework pops up, promising t...
For further actions, you may consider blocking this person and/or reporting abuse
There are many things you got right and almost as many wrong.
The Right Ones
I don't intend to make this section the smaller one. Is just that, because these are the things we agree on, there's nothing else to add. The next section will be more elaborated.
The Wrong Ones
Being a Svelte fan I just have to ask about Svelte's "but": Why "but you're locked into a compiler". So what? C++ has one, and I don't hear anyone saying "it is so much better to just write assembly". This is not a "but" in any shape or flavor.
Yes, it is true that many frameworks don't really advance anything. However, some do, and a few of those really do it. Let's go back to the jQuery days. jQuery is awesome, even if it is already in the list of banned technologies at companies. I agree. But the "ridiculous amount" of websites still using it may not be due to its greatness. It might be because of its timing: It was the first of its kind.
Moving forward, we encounter React. This one was the child with the silver spoon: Not only was it the child of a big company, it appeared early enough to wow the world. In retrospective, people should have stuck with knockout.js, but that's a different story.
Moving forward, enter Vue, Svelte, SolidJS. Vue did a great job bringing simplicity to the now chaotic React, but then, the next kings came. Yes, I do consider Svelte and SolidJS the next royalty. Why? Because these are the frameworks that really did it. But I'll talk about that a bit later.
Point being here: If we discourage innovation, if we are dismissive of new attempts, we will not advance. Just because only a few percentage is worth it, we should... nay, we must never stop trying new things.
About the money: Job security is around React and Angular, true. But will this hold true forever? No chance. Actually, if you're really smart, you'll promote and foster change and research. Better than hoping things will never change is driving the change yourself. Embracing change is always the better option, but has to be done responsibly.
The New Royalty
Before Svelte, "React is so performant because of its Virtual DOM algorithm". After Svelte, "React is so slow because of its Virtual DOM algorithm". This is a well-proven fact. What once was a great strength, Rich Harris tore down to tiny pieces and fed the dogs with the remains.
Close by was Ryan Carniato cooking something just as awesome, aguably more awesome to be exact: Signals. Well, at this point I should bring knockout.js again, as it was, to the best of my knowledge, the first signal-based library. Still, full credit to Ryan Carniato, author of SolidJS. He saw it, he evolved it, and damn, it was great. So great, Svelte favored signals over compiled reactivity, which brings us to present times.
Have We Advanced?
Yes! There is no doubt. For people that are unaware, see the benchmarks for yourself. The once great React is in the bottom. Angular? Definitely hotter, but still significantly down. And who's on top? You guessed it: The new royalty. Svelte and SolidJS are the top performers that are in good enough shape to be seriously considered to take over.
But we haven't advanced in performance only. Svelte is so much simpler than React it's scary. Svelte can do React's job in around 30% less code, and can do it better. Svelte's DX is superior, and I don't say this, developers around the world say this.
So what should we infer of all this? That trying and failing is not a futile exercise, because without trying there won't be successful instances. We just need to be cool-headed about the "next best thing".
Svelte is one of the most beautiful things that have ever happened to frontend development.
So, your next jump will from tree to tree (
js -> rs) instead of branch to branch (react -> vue -> angular -> solid).I think, you should focus more on frontend (UI) instead of DevEnd, mean to say you should stick to one base framework (although you can choose from a variety of js and ts libs for third party tasks) that fits your level and favor (speed or style or support) and try inventing new things in frontend (UI) and that matters the most, in my perspective.
I completely agree with your perspective, and I've been following a similar approach for quite some time now. It's crucial to focus on understanding core concepts and problem-solving techniques rather than getting caught up in the ever-changing landscape of syntax variations.
Front-End domain is constantly bombarded with new NPM packages claiming to be the next big thing. However, more often than not, these are just repackaged versions of existing solutions with slightly different syntax and API names.
My strategy is that keeping things simple (KISS and DRY principle) and minimal is the best approach which involves writing custom code where it's truly needed and only use NPM packages when they provide significant value. This approach has benefited me in keeping my applications healthy and performant, makes scaling much easier, improves maintainability and manageability.
I can't help myself being a bit nostalgic for the days when web development was more straightforward – just HTML, CSS, and vanilla JavaScript (No bells and whistles). Those technologies, in their purest form, were often all we needed to create functional and efficient websites. I hope many agree with me if you are from the era of IE 5.5 :)
While modern frameworks and libraries certainly have their place, there's something to be said for the elegance and simplicity of the basics. By focusing on fundamental skills and concepts, we can adapt more easily to new tools and technologies as they emerge, rather than becoming overly reliant on specific frameworks or libraries that may become obsolete.
GP, I share your feeling nostalgia for simple web standards. In a recent project we have abandoned JS frameworks in favour of HTMX for server interaction, Alpine for progressive enhancement of the UI and Web Components based on Lit. I have found this combination, with the backend (templating engine) of your choice, to hit the sweet spot. Say goodbye to building/bundling the frontend. It's working well for our CRUD applications.
You're absolutely right.
I'd prefer those three than any frameworks anyday
I also think front-end frameworks change too quickly. We should focus on understanding the core theories and design ideas of these frameworks, rather than getting caught up in their syntax.
There are also state management libs other than Pinia and VueX for vue.js like rstore and nanostores, although I haven't tested them.
P.S. - I know it's not place to write ps at top, I just wanna say that I'm still newbie, 1 year old I guess and currently learning React😅
If.im being honest, I read this yesterday night and thought about this that you were correct from start to end but in those midnight thoughts, I researched with myself and found many conflicting things.
There are many rights which were totally right like don't go in hype ( your hype cycle was totally agreed. I also found someone who had same thoughts just like me🤣🤣🤣 ), but then my mind came to something when you said there's still thousands of websites running on jQuery the og, it's not because people loved that, it's because at that time it was only one and just like you said companies can't change thier working app ( just because someone hyped it ), same goes for php, there are Manu sites running on it not because it's great but because at that time it was only one.
Most old thing came to end, found better alternatives, jQuery is nearly dead ( as from current people choice, php is dead.
Only Bootstrap I guess is exception ( I know it's not js, it's css framework, I mentioned this cause just like js, css also has nearly same lib/firework hype and new new things ), cause it's great and then few years back came tailwind, which gave more customization and became favorite, and I don't think for next several years they are going anywhere.
Now come to React and Angular, yeah, they have great community and people, has nearly job securance so why would I learn to go towards Solid or Svelete where in my country React, Angular, Vue is dominant. I know it's cowardness to support wrong ( which still isn't wrong ), but I can learn other things when I've a job, then after learning I can tell anyone with my own experience that what is nice or not, should we change over app framework to x to y just for few milliseconds/microseconds. I also learnt React Router, Redux cause they were ( are ) popular, but I just finished learning of TanStack router ( I can't give my real opinion until I taste that with thousands of time ), learnt Zustand, and I can tell that not all needs Redux, if can work with smaller, go for smaller.
All I just wanna say is If I've job then I'd like to try new things, just because it's fast and better but no job then what imm gonna do with that thing.
And bro, I don't know what's future of React, Angular, thay can also become just like jQuery or php, and more better things come ( always hopeful ) which actually changes WINDS.
I've heard from many people that Svelte and Solid are great ( even I talked with Solid creator ), and heard many people saying that React becoming chaos tonnage, don't go for react, but instead of listening to any of those, you've a family to feed, should consider for yourself first.
Note : I know flow of this replay is total mess🤯
Edit : same goes for code editors, many IDE came and many IDE gone, many came with built in AI and gone and many of people are still comparing one with another, after writing this article, I just found a article Co.aring two AI ides and came back here to edit this. People still love VS code even I tried few of them and always found VSC as per needs, it gave me confortaness, it has mostly all features I think of ( if you belive I've 250+ modifications in my settings of vscode which shows how greatly customizable it is and each month they're adding new to it ), and for something which isn't builtin in default, I finds an extention. And 2 Iade foeyself ( 1. I guess majorly for react, you all time needs to create 2 files, one compo file and second it's corresponding module css file, so I made that and Happily using it,,, 2. About organization of import, I made custom script with high customization and will publish after more testing and implementing everything )
This is a great piece. Often, I get confused about what framework to jump on next.
Thank you. You are right. Learning database and API and security is more important than new frameworks. I hope others use this brilliant experience and doesn't waste time. Regards
My approach to this is to play "King of the hill". For a given problem, I have a tool. Unless what I proof-of-concept knocks it out, it stays in belt. That's why I moved from jQuery to angular.js to react in 2015 and still use it. Moved from custom webpack config to vite for spa and nextjs for full stack. Still use redux in spa, no mobex or saga. Vitest from jest. RTL from enzyme.
Although I try a lot of things, not many of them impressed me in the last 15 years my frontend career. Very few managed to replace my go to tools to become the next one. So, hype? Try it, learn from it, sometimes they teach you unique patterns to augment your toolset. If it's same grind, keep an eye on it for it's promises, otherwise forget it.
Currently I'm eyeing web-components to augment react, but it's still a challenge. I shall probably revisit after another couple of years...
Working in an enterprise, a tip: a company usually follows my strategy at a large scale. 10 years ago everyone in my company was using angularjs. Enter react, every single one adopted it. Although we are on different versions now, we are all on react. Unless vue, svelte or another shiny thing manage to outclass react, we probably won't switch. Does that mean we don't try other frameworks? No, we still do. There are some sporadic teams that use Angular, Jekyll, home grown frameworks, but mostly because either it's convenient, not maintained, or just want to try.
I'm sticking with react for now. It's not worth rewriting thousands of LOCs in vue or svelte just because it builds faster or runs faster or outputs smaller. If you know what you are doing, you won't see difference in any of these.
This happened a long time ago. It is measurable and quantifiable.
You are missing my point. But that's okay 😌
Hmm, I don't think so. You're clearly stating a premise that has already fulfilled, yet you claim to continue using React. You are therefore not upholding your own "King of the hill" approach: React has been dethroned long ago. You're not being consistent.
Now tell me: If this is not the point of your comment, which is it?
This is my point:
In other words, they are not that impressive just because of their performance numbers. There's is little to no impact in developer experience. There's even smaller impact in decision to switch from one to another.
Let's try this to get the point across to you:
jQuery -> angularjs = B
angularjs -> Angular = A+
angularjs -> React = A+
React, Angular -> Vue, Svelte, Solid = C
You are not gaining much that's worth the cost of conversion. In a few years, maybe. Not now.
If you are starting a new company and ask everyone to use svelte, yes, it's good to go. But try convincing 5000+ developers to switch their codebase to svelte without showing them the difference. That's my point.
Well, you may be getting your information from the incorrect sources. Have you seen the difference in performance? React is surpassed a lot. From where are you getting those grades? The difference is night and day.
Code reduction is super significant, too: 30%. Developer experience? Stack Overflow survey says Svelte is the best.
So with all this evidence, you gave the change a grade of C. This is why I don't get your point. I do understand your logic. Your logic is good. Your data input is completely lying to you, though. With the correct data, that C should have been A+++.
... while the old frameworks (or (software) products), if they can, adopt their contenders' most crucial innovations, so there are even less reasons to change.
Yes i had experience the same thing and wasted my time. Then realized that every framework will come and go but the main foundation html, css, js, ts will be the game changing even after a decade. So i need to invest my time learning these languages
Didn't jQuery just get a facelift too? That includes a compiler, or atleast I know npm has packages for react , next etc... the difference being that next.js for example is all about the virtual Dom and not actually manipulating the actual Dom. Which is why lately I've been considering jQ to do this instead of fighting the useEffect(). Thank you for the article, I'm going to have to see if I can make jQ be as fast as nextjs. I still use php servers and wp backend for CMS so why not? I can't tell you how often I'm thinking, "jQ would have cleared that up much easier." Than fighting the react next only using static practices because I don't have clients needing dynamic content...
My opinion only.
Much of this is not worth debating. Each framework has its flaws and advantages.
Use what fits you or your company’s policy.
If you’re in the position of choosing which framework or no framework is to be used, gather a consensus of the team.
Maybe consider what is more important of the result of that decision; the developer experience or user experience.
Move forward.
I agree on all accounts.
Now day frameworks are all doing the same, you do not switch for performance or a different syntax.
But you need to ask yourself, what kind of features will make you switch framework, now that you know a few?
I am exploring the areas of design to code at the framework level, 3rd party security at the framework level and full stack components at the framework level. Those are features that are not present with other frameworks.
But before I go to convince you to switch, I am mostly interested in what do you expect from a future framework, one that worths the pains of a switch?
The issues I'm having with these JS frameworks are:
I get paid way, way, way more working with svelte than any other js framework because I can deliver 10x as much as any other developer specialising in another framework. And no shortage of work!
I completely agree with this perspective. Constantly jumping between new frameworks can be more of a distraction than a benefit. Instead of chasing the latest trend, focusing on mastering core JavaScript concepts and building solid, maintainable applications should be the priority. danchoi.com At the end of the day, the best framework is the one that fits your project needs, not what's trending.
Give web assembly access to the dom, then we can ditch JavaScript and it’s constantly breaking framework all together!!
I have faced issues with Javascript frameworks in security tests (like VAPT) and decided to go back to plain Javascript. This is not because of any issue with framework, but the frequent new versions. My product's various versions run at different cloud environments for specific clients. Clients run security test on their instance at their time and interval. Security test suggest upgrade of Javascript framework if it's latest version. For me it's applying upgrade to different versions of product just to match latest version of Javascript framework.
design software that works, scales, and is easy to maintain—regardless of framework ❤️
And yet AI can create everything you can imagine