TL;DR
Which framework should you use? Well, that depends on what you're developing and your prioritie. But I made a quick comparison tool to help you find the perfect stack for your project. See: Stack Match.
Just want the numbers? I also built the same app using 10 different frameworks, and benchmarked them. See the framework-benchmarks repo for source and results.
Methodology
Why am I writing this? Well I see a lot of articles bigging up specific frameworks, or putting down other frameworks. But rarely does the author cut through the hype and provide an unbiased comparison between all* the options.
My aim here is to briefly outline each frameworks USP, when you should use them, covering their pros, cons and also mention my thoughts.
Talking about unbiased, I need build the same app in each framework to make this a fair test (which I have done!). But that's the first issue, as simple apps do not fully demonstrate a frameworks capabilities in real-world scenarios. As such, I've also included actual / live projects I've built with each. All of these are production ready, with a decent number of active users and/or downloads (actually, a combined 1 million anual users, and 50k github stars).
Since there's literally hundreds of frontend frameworks, so to keep this post reasonably, I'm only going to cover on the "top" 10 latest and greatest, and we're mainly focusing on developer experience (but performance benchmarks will also be included).
That's enough chat, let's get to it!
React
React is everywhere, powering over 1.3 million websites, and used by many (probably most) large companies. It's been around for over 12 years, backed by Meta, with very mature tooling and a large ecosystem. So it's no wonder it's become the default choice for many teams. It's very stable with excellant backwards compatibility (which is actually also one of it's pitfalls, as there's multiple ways of doing everything).
But it's not perfect. It adds a lot of boilerplate making it much more verbose to write than the likes of Svelte or Vue. The virtual DOM also adds quite a significant performance overhead (actually, just the reconciliation, but it's easy to use incorrectly), memoization is often manual, concurrent features are not yet very mature, and bundles tend to be large, even with a lot of tree shaking.
Pros
- Plenty of jobs
- Ubiquitous, huge ecosystem, good community support, corporate backing
- Flexibility, build anything from SPAs, emails to mobile apps (kinda)
Cons
- While quick to get started with, React can be slow to master properly, and there's many things to trip up beginners
- Less performant out of the box, and the virtual DOM adds an overhead
- Quite boilerplate heavy, especially when compared to Svelte or Solid
My Thoughts
If you're vibe coding, React has a huge advantage, since there's just so much code out there for the AIs to consume. Likewise, if you're looking for a job, you can't go wrong with learning React as it's been the dominant framework for most companies for quite a while now.
That said, I personally do not like React: it's slow, heavy, boring and sometimes a bit more complex than other frameworks.
I find it frustrating that I need to do so much manual work to improve performance of an app. It makes the code verbose and prone to mistakes. Even though developer tooling is very good, inspecting the compiled output can still be quite painful. I spend a lot more time with the docs open, as the React spec is quite large and broad.
What I built
Vue
Vue is a progressive framework, meaning it can be used for all app types, from just a drop-in script from enhancing HTML all the way up to a full SPA with SSR. Like Svelte, it uses SFCs (single file components) where each .vue file bundles template, logic and scoped CSS together. For reactivity, Vue uses ES2015 Proxies to track dependencies and update only what’s needed, without manually memoizing.
Pros
- Really easy, intuitive and quick to learn and use
- Nice Single-file components with scoped styles
- Easy, fine-grained reactivity and efficient dependency tracking
- Official tools for routing, state, and SSR (bundled separately)
Cons
- While Vue can scale very well, a lot of thought is needed when using it for a very large project
- There's some inconsistencies (such as the two competing Options vs Composition APIs)
- Some reactivity caveats (e.g. .value on refs, destructuring loses reactivity)
My Thoughts
Vue could be seen as the Goldilocks framework, sitting comfortably between React's flexibility and Angular's structure. Vue is fast enough, fun enough and battle-tested enough, but doesn't really excel amazingly in any of these areas.
The reactivity system using Proxies is genuinely impressive. Change a data property and everything dependent on it updates automatically. And, the ecosystem is much stronger than people realize.
I chose Vue for Dashy, because it both has everything I needed, but also is incredbily easy, so contributors could add their own widgets and features, with out a steep learning curve.
What I built
Svelte
Svelte has consistently ranked as one of the most loved frameworks, and for good reason. It's simple, fast, lightweight and really fun. Reactivity is built directly into the language, no hooks, proxies or useEffect weirdness; just assign to a variable and it reacts.
Unlike many other frameworks, it does not ship a runtime or use a virtual DOM. Instead, components get compiled into highly optimized vanilla JS at build-time. So, there's no runtime overhead, no framework code in your bundle and you get near-native performance in the browser. Oh, and the compiled output is surprisingly human readable.
Pros
- Smaller, faster bundles than React or Vue
- Really simple reactivity model
- Less boilerplate than any other framework
- Animations are built in
Cons
- Ecosystem is still smaller than React/Vue
- SvelteKit still maturing, and could be slightly less stable than Next/Nuxt
- For large teams or huge projects, the tooling is not as robust
My Thoughts
Building in Svelte makes me happy. I like that it's both modern, intuitive and fast, but also that it's SFCs are very aligned with the core web technologies: just HTML, CSS and JS.
Svelte has been my go-to for building things quickly and beautifully, while shipping a performant result. But I have found that if I don't pay attention to structure, a large project can quickly get messy.
I wouldn’t necessarily use it for a huge enterprise dashboard where you have 15 teams working on the same codebase, React or Angular still offer more predictability, stability and tooling in those scenarios.
What I built
Angular
You're probably thinking Angular is an old-school framework, only used in legacy apps and corporate environments. And yes, the latter is correct, but recent releases (yes, it's still very active) have some awesome features, that make it a very viable choice in 2025.
Unlike other frameworks, Angular ships with everything batteries-included: routing, forms, HTTP, testing, internationalization, animations, SSR, and more - all officially maintained and deeply integrated. No need to cobble together a stack.
But it can be verbose to write with.
Pros
- TypeScript from the start
- Very stable nowadays
- Everything needed for large apps is included
- AOT compilation of templates, making it faster than some
- Plenty of jobs in the corporate world
Cons
- Steeper learning curve (RxJS, DI, modules, zones)
- Verbose compared to frameworks like Svelte or Vue
- Smaller community than React/Vue in open-source or tutorials
- Less flexible — you build the Angular way
My Thoughts
Angular isn't cool, but it is consistent, powerful, and scalable. There isn't really anything missing, so you don't need to npm install a ton of third-party deps just to do common tasks.
I didn't find it complicated to get up to speed with, but there was a lot I needed to learn from the docs, especially with the template syntax, component definitions, directives, injections, etc. The only thing I struggled with, was initially getting hydration working for my SSR routes. Everything else was smooth sailing.
I'd consider Angular again for large apps, where stability, structure and long-term support matter, but not so much for smaller apps.
What I built
Lit
Lit is a super lightweight framework for building standards-based Web Components, built around modern browser APIs (like Custom Elements and Shadow DOM) and is great when you want framework-agnostic, reusable UI components.
Pros
- Uses native Web Components and common standards
- Performant, as no virtual DOM, and updates are minimal and direct
- Works with any framework (or none)
Cons
- Verbose syntax: @click, ?disabled, .value, etc.
- Class-based components feel outdated
- SSR is experimental and hard to set up
- Ecosystem and learning resources are niche
My Thoughts
I personally found that writing Lit components was a bit like stepping back into the old days of React. Components are class-based, and even the simplest of components are quite verbose, with a fair amount of boilerplate code.
The funny expression syntax (for attributes), caught me up a few times, forgetting to precede properties with a ., booleans with a ?, event listeners with an @ and all values with a $
Server-rendering is still experimental, and was such a pain to get working in a standalone Vite + Lit project.
Because it's web-components, and using the shadow DOM, each component is totally isolated. Which has it's pros and cons, but if you're not used to this, you might notice that things like your global CSS reset or styles do not work the way you'd expect.
What I built
Marko
Marko is a declarative language and high-performance web framework, built and maintained by eBay.
Pros
- Concise syntax, with short-hand options for markup, no need to import components/custom tags
- Quite easy SSR and isomorphic UI components
- Easy routing with Marko run
Cons
- Very niche and limited support - you definitely could not vibe code with Marko!
- Amazing when it works, but if you face an issue, you'll be delving into Marko's source and resolving it yourself
- Missing docs (e.g. Low level APIs is just empty)
My Thoughts
I actually really liked what Marko was going for, the templating made a lot of sense. But it slightly feels like using a framework from the future, but in the past, it's both futuristic and out-dated at the same time.
The main drawback, and it's a big one - was that there's very limited info online. The docs are sparce, you cannot just grep github to find examples, AI tools have no idea of Marko basics, there's limited community support and even intelisense is very limited. So, if you face issues, you'll be delving into Marko's source yourself. And it does have a few quirks, which are often undocumented (e.g. if you use class {} in a top-level view or layout, all interactivity will just break, without an error message).
So as much as I loved working with Marko, I don't feel I can recommend it for any serious project, just because the community is so small. I also don't think it's going to be actively maintained for much longer, as repo activity as been slowing down for the past few years, and ebay seems to be the only core maintainers.
What I built
jQuery
Did you think I'd forget about our old friend jQuery?! Nearly 20 years since it's first release, and jQuery is still present on over 70% of the top 100k websites (that's largely correlated with WordPress usage).
That number is now starting to decline, and with good reason - for simple apps, many of the features of jQuery can now be done nativity with modern JavaScript, and for more complex apps modern frameworks just do the job far better.
...but earlier this year, and for the first time since 2016, a new major version, jQuery 4 has been published.
Pros
- No build tools, dependency managers, transpilers etc
- It's very much battle-tested
- Useful for supporting (very) old browsers which don't have the newer JavaScript features
Cons
- Not much that jQuery can do, which can't be done with vanilla JS
That said, I couldn't quite bring myself to build a modern app using jQuery. Though I have used it (many years ago) for revision-quizzes, intern-magnet and user-monkey.
Alpine
Enables you to easily sprinkle reactivity into server-rendered HTML (no SPAs, no hydration, no SSR). It's ideal for simple UI enhancements without a full build setup.
What's clever is how Alpine stays out of your way. The HTML is still readable, the JavaScript is minimal, and everything degrades gracefully if Alpine doesn't load. It's progressive enhancement done right - the page works without JavaScript, but becomes interactive when it loads.
The syntax reads naturally: x-on:click="searchWeather()", x-text="temperature", x-bind:class="{'active': isExpanded}". It's declarative like Vue templates but lives right in the HTML. The reactive updates happen automatically when you modify the data.
Pros
- Zero setup — works with just a
<script>tag - Ideal for small enhancements in SSR or static sites
- Easy, declarative syntax inspired by Vue
- Progressive enhancement by default
Cons
- Not meant for large apps — lacks routing, state management, SSR, etc
- Limited tooling and structure for big teams
- Can get messy if you cram lots of logic into HTML attributes
My Thoughs
Alpine hits a really sweet spot for simple interactivity. When you don't want a full framework and just need modals, dropdowns, toggles, or light client-side behaviour then Alpine is perfect.
What I built
Solid
Solid looks a lot like React at first glance, but under the hood it's completely different, and much faster. Instead of a virtual DOM, Solid uses fine-grained reactivity (similar to Svelte and Vue's internals) to update only what actually changed. The result is tiny bundles, almost no runtime overhead, and great performance.
You still write JSX, still define components, still use hooks - but everything is reactive by default. Signals (createSignal) replace useState, computations run automatically when their dependencies change, and nothing re-renders unnecessarily. It feels familiar, but without the awkward parts of React.
Pros
- Extremely fast: no virtual DOM, fine-grained reactivity, tiny bundle
- Feels familiar, if you're from a React background
- Very scalable, for large, highly interactive interfaces
Cons
- Much smaller ecosystem and community
- SSR is strong, but full-stack frameworks like SolidStart are still maturing
- JSX.
My Thoughts
Solid feels like "what React could have been" if it were designed today. You get the React ergonomics without the re-rendering dance, memoization hacks, or performance footguns. It genuinely feels snappy to build with. But because it's still relatively niche, you won’t find as many libraries, tutorials, or job listings.
What I built
Astro
Astro is less of a framework, and more of a content-first site builder.
Astro statically builds your site, and uses barley no JavaScript by default. Interactivity comes from "islands", which are tiny isolated components, writen with any framework of your choice (like React, Svelte, Vue, Solid, etc), and are used to sprinkle in interactivity which get hydrated on client-side, only when needed.
Pros
- Best option for SEO (SSG,SSR), plus all the benefits of interactivity only when you need it.
- First-class MD/MDX support
Cons
- It's good for content-heavy sites, but definetly not a good choice for SPA/interactive apps
My Thoughts
For a blog, docs, a marketing site, or a “mostly static with a few interactive bits” project, it’s honestly hard to beat. I love Astro, it's DX and flexibility, but it does have very specific use-case.
What I built
Van.js
Van is a tiny (like seriously tiny - under 1kb) Grab 'n Go reactive UI framework with no virtual DOM, no build tools, no dependencies and no heavy abstractions. It works with entirely with plain DOM nodes, using simple reactive primitives (van.state, van.derive) to update the UI when data changes. It feels closer to "reactive vanilla JS" than a traditional framework.
The API is intentionally minimal. You create components as functions that return DOM elements, bind state directly in your markup-like calls, and that’s… pretty much it. No JSX, no compiler, no bundler, no fancy lifecycle hooks. Just JavaScript and DOM APIs with a sprinkling of reactivity.
Pros
- Extremely small and fast, perfect for tiny widgets or embedded components
- No build step; works in a
<script>tag - Very simple reactivity model
- Easy to learn if you’re comfortable with vanilla JS
Cons
- Definetly not suitable for larger applications
- No component abstraction beyond functions, no templating system, no event system
- Awesome for simple reactivity, but gets unwieldy fast for anything larger
What I built
Qwik
Qwik is kinda wild. It completely rethinks how web apps work by doing something called "resumability" - your page loads instantly with zero JavaScript, then individual components wake up only when you interact with them. It's like having a webpage that's asleep until you poke it.
Pros
- Super low TTFB, with <1KB JS on initial load
- Scales really well for large apps with complex routes or dynamic content
- Familiar developer ergonomics, with JSX + Vite + signals + file-based routing
Cons
- SSR is required, it cannot work purley client side
- Steeper learning curve, and some concepts (like resumability and serialization) may seem alien to devs at first
- Debugging can be complex, because logic is split across server boundaries
My Thoughts
If you're working on a very large or complex app, which also needs to be highly performant, then Qwik is a natural option. Sure it has a smaller community, steeper learning curve, and is more complex than other options, but when every byte matters then this is just the price to pay.
What I built
Hol' Up - It's not a fair test if you built different apps!
That's a very fair point, but don't worry - I got you!
In order to more impartially compare these frameworks, I've also built an identical mini-app in each of them, and benchmarked each to compare performance.
You can check this out here: https://github.com/Lissy93/framework-benchmarks.
There's a shared test suite to confirm that each app meets identical requirements, each app uses all the same shared assets and styles, and then I have a set of performance benchmarking scripts which run all the actual performance tests. These results then get processed and put into the results branch, along with some charts and summaries which are in the main readme and on the framework-benchmarks homepage.
Conclusion
So there we go, 12 frameworks, 12 apps (and 12 years of pain). If you're trying to choose a framework for your next project, check out Stack Match the framework comparison tool.
And if you like this kind of content, consider dropping me a follow 🩷
I'm @Lissy93 on GitHub, and @lissy93 here on DEV. I build a lot of developer tools, security and privacy apps and self-hostable stuff for Linux, which you can check out on my site https://010000010110110001101001011000110110100101100001.com (yeah, really memorable domain name!)
Anyway, thanks for reading, happy coding, and happy new year!!
Oh, and almost forgot - which framework is truly the best? Well that would have to obviously be [character limit reached]
Top comments (28)
Great insights, Alicia! Your framework comparisons are incredibly helpful for developers navigating their options.
Awesome overview! The "Stack Match" tool and the framework benchmarks repo are also impressive ...
"Which framework is truly the best?" - I think speaking for yourself that would definitely be Svelte?
And yeah, React is what we use because in many cases we "have to" ;-)
I do love me a nice bit of Svelte 😉
What an experience, thanks for sharing !
how do you learn that many things ? cool as hell
This is awesome! I’ll be referring to this post every time I want to start building something
Oh wow I am super inspired. I wish you the best!
thats amazing
Commenting on my own post here, because I am anticipating people saying "Wait a sec mate, you've not included ____"
Unfortunately it wasn't really feasible to cover everything, and things which are either declining in usage, augment other frameworks, or take a completely different approach have been left off for brevity. Here's a summary, and my reasoning for this:
Older Frameworks
I do have to give a shoutout to these frameworks, which played their part in laying the groundwork for what we have now: Riot, Radi, Stimulus, Imba, AMP, Mithdrill, Hyperapp, Rax, dva, Omi, Neo.mjs, Crank.js, Polymer, Inferno, Ember, Hyperapp, Cycle.js, Stencil and Relay
This isn't to say that these project are dead, but more so that the features and notions have been further developed by the frameworks listed above.
Many of these I either used, or played around with (back in the day), and I see concepts that they've invented being refined and bought back by the modern frameworks we use and love today.
By it's very nature, frontend development changes rapidly, and as such so does the tooling that we use.
If you're concerned by the thought that something you learn today, may not be relevant tomorrow, here's my thoughts:
Meta Frameworks
I've not mentioned meta-frameworks (except Astro), which provide an additional layer of abstraction, giving you certain essential features like file-based + API routes, SSR, + SSG. If you're interested, let me know below as I'm happy explain more, and share my experiences of using these.
But in short, if you're building a larger app then using a meta-framework can save you time, give you an improved developer experience, simplified setup for larger projects and out-of-the-box performance optimizations and integrated best practices.
Though the extra overhead usually isn't worth it for mini apps and small SPA projects (IMO).
Some popular examples you may have come across include: Astro, SvelteKit (for Svelte), Nuxt (for Vue), SolidStart (for Solid), Next.js, Remix, Gatsby (for React) Analog (for Angular), Qwik City (for Qwik).
Non-JavaScript Frameworks
Using a frontend JS-based framework is not the only way to build web apps in 2026!
I didn't have time to go into these here, but if you're interested let me know and I'll write another post.
But in short, here are the main alternatives:
Wow great stuff!
And epic domain...
Bring more such articles!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.