5 criterion to pick your front-end framework
Where we take an objective look at all options ranging from jQuery to Remix in order to figure which should you use for your next front-end project.
One thing for which yours truly is particularly glad is to have been able to partake to the development of the Web for two thirds of its history and to see all the twists and turns it has taken over the year. Now that the big platforms dominate it, that Chromium has a quasi-monopoly — except for Safari, which is a lesser version of the same thing — and that the hoops to jump are just so numerous, one can only imagine that getting into web development must be a disheartening thing.
Let us however keep an eye on the North. Imagine you were to create a major project right now, which involves a website, what route should you wish to take?
The old school would go towards jQuery
The minimalists would pick htmx
And the mainstream would pick a meta-framework such as Remix, Nuxt or SvelteKit1
Those three voices will often be vocally contradicting each other on social media, adding confusion into the mix. Of course there are no silver bullets, only bullets that will hit the target more difficultly than others. My bullet is the meta-framework, and that’s not out of kool-aid nor fear.
For the first years of my career it was impossible for me to use meta-frameworks, for they were not invented yet. This was a painful experience. If you end up creating a real-time interactive game in which the whole DOM is dynamic, trust me jQuery is definitely not the tool for the job.
On the other hand if you are not creating something so deeply interactive, chances are that jQuery — a library whose main purpose is to even out the differences between Internet Explorer 6 and Firefox 2 — isn’t going to be of great help. Especially if you are feeling more like a backend person, a tool like htmx will allow basic interactions which require very little front-end work and might just be enough for you.
But if you work for projects of a more unpredictable nature then maybe those solutions are not optimal. It’s with the mind set on a large, enterprise-grade© project that we’ll go in quest of the perfect framework to build your startup.
Performance
A common consideration against meta-frameworks will be the performance. Surely, all those features must come at the cost of very expensive and bloated JavaScript runtimes? Let’s put that to the test. I’ll make a hello world page using major frameworks and measure the transfered payload size (gzipped for the most part):
HTMX — 16 kio
SvelteKit — 25 kio
jQuery — 30 kio
Remix — 90 kio
Nuxt 3 — 131 kio
This tells us that meta-framework do not have to be heavy and clunky. They can, like Remix and Nuxt 3, but SvelteKit is lighter than jQuery in that regard.
What about the execution speed, memory use? This benchmark is fairly popular and while it doesn’t include HTMX nor jQuery, it does have vanilla JS, which should be the closest to what you can achieve. You’ll have to explore the numbers yourself but in a nutshell even React that is often lagging behind stays pretty close to the baseline. The same goes for memory use.
In any case, those benchmarks are toys. The better question is: how fast is your website going to be at scale?
The clear winner is going to be HTMX, because all the rendering logic happens on the server, which isn’t so much bound by script size. On the other hand, all the other options will have to write numerous lines of code. If you write your project using jQuery, you will be ending up either with one big JS file, either with a collection of different files but either way, the organization will be yours. Now if you want to minify all this, you will not escape the need for a set of build tools. When scaling up, it is difficult to escape having a build stage.
And while meta-frameworks also have a build stage, this process is entirely integrated. You don’t have to do anything: your code gets transpiled, minified and processed in all the necessary ways completely automatically. With the added bonus that the build tools are aware of the dependency tree. As a result, every page can automatically be bundled in its own file, so that you never need to load code that you don’t need immediately.
From the performance standpoint, you thus have two choices:
Either you think that HTMX will never be a limit in what you are trying to achieve, in which case it is the easiest option
Or you need to have some wiggle room in terms of feature — 100% of my professional projects — and then a meta framework will be a far superior option for a relatively small price to pay
Let’s declare the winner of this round: SvelteKit!
Maintainability
While a strong argument of the web development community was the separation of concerns between HTML and CSS, you need to understand that at this time people were writing CSS directly in the style tag, making poor use of semantic and limiting greatly reusability. It is however essential to consider HTML, CSS and JS as a whole.
This is why the concept of component is everywhere. It’s the same as the widgets from UI frameworks. The advantage of a component is that, like explained above, it has a clear dependency tree, it contains all the code that is required for its proper execution and if you want to refactor or delete it you do not need to look for its bits and pieces all over your code base, worrying about side effects.
The first and most important question to deal with is the CSS, whose C stands for “Cascading”. It’s another way to say “if you are not careful, one change here will cascade into disfiguring your whole product”. You could deal with the styling of your component by writing the style into the style tag directly, or even generate all the possible styles into classnames and write the style into the class tag directly. But that is exactly what the Elders warned us about.
A more interesting approach is to define the CSS in JS, which allows you two things: first the CSS gets bundled with your JS — and your HTML de facto — and second it gets a scope wich will not overal with the one of other components. It’s just a shame to be doing this manually and to deprive yourself from tools like SCSS, which make writing CSS much easier. That’s what Single File Components (SFCs) allow and they are available in both Vue and Svelte but weirdly not in React.
Once you have scoped and bundled together your CSS, JS and HTML generation then it becomes hard to write spaghetti code. Knowing that on top of that the build system will track all your dependencies, as said earlier, this allows for an extremely atomic compilation and optimization process.
On the other hand, when using jQuery or HTMX, you will be left to your own devices. Not necessarily a bad thing but the organization becomes up to you. As soon as two developers start working on the same code base, we know that t he organization can quickly go through the window.
Henceforth, we got here two winners for scalability and team work, which are SvelteKit and Nuxt 3.
Future-proofness
If you create a startup which depends heavily on a given framework in order to work, you want to make sure that after you have invested five years of developer time you don’t end up having to rewrite everything from scratch. Those tools need to give a good perspective to developers. For example, you can still run on a Windows machine an unmodified DOS program that was written in the 80s. Without being so extreme, if you cannot see at least 10 years forward with a tool then you have a problem.
First of all, let’s look at jQuery. Almost 20 years later the API is still basically exactly the same, version upgrades being mostly about simplifying the code because browsers are converging now. If that’s the route you intend to take the rest assured that jQuery will not go anywhere.
Then HTMX. Honestly it’s hard to say anything at this point. Small project, the maintainer probably can’t promise anything. Chances are it will only add features through time but due to its nature I can’t imagine how they could introduce major breaking changes. The main risk is more that the project dies, but even then it probably wouldn’t be too hard to maintain it yourself it it came to that.
On the React side, I don’t practice it often enough to go in-depth into it but in any case the ecosystem is so vast that you could probably write another article dedicated to chosing the right React stack. In that regard, it seems like breaking changes do occur in every part of the ecosystem but overall it’s never going to be something fundamental that asks you to through your entire codebase in the trash.
Which is fairly different from what you could say about the Vue ecosystem. Vue 3 has been a major breaking release and introduced a whole new set of completely different APIs (the “Composition API”) and while it is not inherently bad it changes completely the way to think about your code. In theory you don’t have to use it but every single library of the ecosystem only supports this anymore, so you don’t actually have a choice.
Including the Vue-3-compatible version of your favorite libraries/tools (if ported), which will force you to rewrite everything that depends on it. The main one being Nuxt 3, which came out with exactly zero overlap in API or conventions. There is nothing that works the same anymore and the thin compatiblity layers that exist usually are fickle, fragile and generally useless. This feels like a serious backstab barely 6 years after version 1 — yes I have products that would cost 6 figures to upgrade and I’m pissed about it.
Now remains to evaluate Svelte’s position. While I can’t find any official statement on where Svelte will be in 10 years, some good indicators are there. Firstly, the documentation is written in a way more practical way than others, showing that they care more about the use cases than the technicality of the framework. Secondly, so far upgrades have been relatively smooth. And finally Svelte 5 is cooking and the ugprade process also seems clear. Now since the ecosystem is much smaller, it’s hard to tell what is really going to be the impact, but let’s keep our eyes open.
Overall, the only tool that has demonstrated a serious commitment towards backward compatibility is jQuery, which will have to be winner of this round!
Cognitive load
You have probably one day heard of GTD and decided to try it for yourself. One of the advice coming out of it is: if it takes less than 5 minutes, do it immediately. So tell me, how many days did you end up spending 100% on 5 minutes tasks? Did it feel satisfying? And did you accomplish anything meaningful?
Of course it’s a rethorical question and you can’t really answer so you’ll have to imagine that you said “it’s satisfying but not meaningful at all”. Which is what happens as well with many tools that we use and that we might judge on the satisfaction to use them while actually we lose our time doing boilerplate.
Imagine that you are writing an interactive component which depending on the user actions and inputs will have to update its own DOM. Doing it in jQuery can be extremely satisfying because you create all the elements yourself, find smart ways to hook events, imagine optimizations to do it faster, etc. Very fun if it’s your jam. But on the other hand if you do the same thing with Svelte, the compiler does all this automatically and better than you ever would. Managing the DOM is just not a task with Svelte.
So while it’s satisfying you just spent your time on something that should not even grab your attention. What about our contenders?
jQuery — As mentioned above, it’s all manual from the manipulation of the DOM to bundling it to the client. Easy to marvel at the beauty of your code, hard to actually focus on what matters.
Remix/React — Many moving parts and optional APIs (hooks, signals, etc). No management of CSS. Fairly complex overall.
Nuxt/Vue — Version 3 of both definitely made things more complex, with two competing APIs (including a fairly verbose one) and lots of build-time magic.
HTMX — Very lightweight front-end but on the other hand you still need to worry about the back-end yourself, so it’s a lot of unknowns
Svelte(Kit) — Once you’ve sorted out the idioms, it is fairly straightforward and requires no magic of any kind
Hence, I’ll give the round to SvelteKit!
Community and talent pool
You could find the best framework of all times, if nobody can provide for you libraries that solve common problems (UI libraries, form validation, toasts, etc), learning resources or direct support then you are going to have a hard time.
On top of this, you need to be able to hire developers. A decent developer can learn any decent framework but they need to want to work with it and usually they’ll expect that it’s going to look good on their CV.
The same goes commercially speaking. Lots of customers are interested in knowing what tools you use and if you can’t justify that it’s durable and bullet-proof they might get cold feet when deciding to work with you.
So here is what to expect:
jQuery isn’t sexy anymore, nobody needs it on their CV, nobody wants to work with it except a few indiepreneurs that claim jQuery pays for their lambo. Customers who look into your tech stack will ask you if jQuery is a headless framework and it’ll be hard to say yes.
HTMX is straight away a no go. It’s too small to put on a CV and not trusted enough to fuel a sales pitch. Using it in a professional setup right now will require a serious offset on other parts of your stack.
React is a no-brainer. Everyone wants it on their CV, it’s backed by a major player and the community is one of the largest for a framework of that kind. Plus, most companies that publish SDKs or component libraries will prioritize React.
Vue is the new React, except less popular, less demanded and less clunky. Still a workable option.
Svelte is on the line. But it receives a lot of developer love (like HTMX you’ll tell me) and is now backed by Vercel which not as big as Facebook but definitely big enough to make this serious. Plus Svelte 5 is promised to resolve all pending Svelte issues, which should boost adoption.
Basically I have to give this round to React (hey at least one).
Conclusion
There are a million of other items to consider and of course many more frameworks than those. But in my experience those themes are the most important to consider when picking a technological stack.
So which framework should you use?
In the absolute, go with SvelteKit. Provided that the version 5 of Svelte doesn’t turn out to be a major betrayal of the community. It’s lightweight enough, scales well with teams, focuses developers on what matters and should not ask you to rewrite your whole application in 2 years — especially if you waited for version 5.2
Yes you will get more difficulties finding talents for it but on the other hand it has good press and you can learn the bulk of it in a few hours. There are of course a few rough edges but nothing insurmountable. Same for your sales pitch, you can always make diversion by using a hot headless CMS.
Another interesting option if you were building your own startup with a Craigslist-type UI would be to use HTMX. Besides the talent pool, the main thing about using HTMX is that developers need to have the final word on UX/UI, because otherwise you will be fighting against the framework all the time. But if you can keep it constrained, you’re probably going to have a very efficient experience.
Now regarding other meta-frameworks, we see that they all come with dealbreaking drawbacks — namely React being a huge spaghetti bowl and Vue being a traitor. Not that you can go particularly wrong with them, but it’s just not good choices in my opinion. If you are really afraid about what others might think you can always pick some assembly of React things, but be warned that it comes at a cost for your mental load and the one of your browser.
Finally if you are team jQuery, of course it’s a safe and proven choice which will continue to support you for the next 100 years I’m certain. Which is more than you could say about anything else on that list. It’s probably good if your app is small and you have few resources to invest in the front-end.
So while there are indeed no silver bullets, it’s important to outline that given the current state of the art you are much safer and much better off with a meta-framework, especially if it’s SvelteKit. Other options exist and can be valid for some use cases but as someone that oversees the production of many front-end applications I can only recommend to stick with a paradigm that covers all angles at minimum cost.
If you’re wondering why Angular is not part of this comparison while it definitely has the credibility to fit in there the answer is twofold. First of all, they invented backstabbing in the JS framework world. And since they backstabbed me, I didn’t get any experience with it so it would be very hard for me to talk about it. All I know is that it has no chances of winning according to the evaluation below.
If Svelte 5 also ends up in treason, then I’m not sure what advice to give. If treason is acceptable then Vue is a superior option due to its large popularity while avoiding many of React’s pitfalls.