Several years ago, Art+Logic settled on Vue.js as our preferred frontend Web framework. Now, in 2024, we feel it's time to revisit the frontend framework landscape to see how things have (or haven't) changed.
Up for consideration, aside from Vue, are two similar frameworks: the dominant React.js, and the minimalist up-and-comer Svelte.
React, the original declarative component framework, is now over 10 years old, and is the most popular frontend framework by quite a large margin. It describes itself modestly as "a JavaScript library for building user interfaces" and, like Vue, it uses a runtime Virtual DOM system to manage component updates. Components are defined in JSX, a syntax which mixes JavaScript and HTML.
Svelte distinguishes itself by providing a similar declarative component development experience to React and Vue, but without a Virtual DOM runtime; it instead outputs code to directly modify the DOM. This is intended to create extremely lean and performant pages while still providing the same capabilities as a Virtual DOM based framework. It describes itself somewhat less modestly as "cybernetically enhanced web apps" (formerly "the magical disappearing UI framework"), and is the youngest of the three under consideration.
Vue bills itself as "the progressive JavaScript framework", and was initially released a year after React. It too is based on a Virtual DOM runtime but, like Svelte (and unlike React), it typically uses a template system for rendering components rather than JSX. It aims to offer the same capabilities as frameworks like React, but in a smaller and incrementally-adoptable package.
We'll be comparing these frameworks in terms of:
- Complexity for developers
- Performance
- Ecosystem
- Features
- Small-scale viability
- Retrofit and migration viability
- Large-scale viability
- TypeScript Support
Before we start however, a quick nomenclature distinction needs to be made between "framework", meaning React/Svelte/Vue, and "meta-framework", meaning an expansive collection of tooling built around a given framework. Examples of meta-frameworks would be Next.js for React, Nuxt for Vue, and SvelteKit for Svelte. Each of them provide features like code-splitting, server-side rendering, link pre-fetching, a prescribed project structure, and many other things that are typically needed in larger projects. We won't be digging into these meta-frameworks in detail, mainly because there's a lot of ground to cover there and they offer largely the same types of functionality, but we won't be ignoring them either; that's because these frameworks themselves are quite narrow in scope, so it's common in practice to need to lean on the capabilities of a meta-framework in order to build complex Web applications.
With that out of the way, let's start by looking at ease of use for developers.
Complexity for Developers
Ultimately, frontend frameworks have a pretty narrow scope: they help developers to organize their components, and then put HTML and CSS on the page. Consequently, it's a shame if valuable developer brainpower gets diverted to managing the complexity of a frontend framework, at the expense of delivering more value or of minimizing technical debt.
Svelte, by design, is the standout winner in terms of remaining simple; it provides templated components and basic state management, defers anything fancier than that to a meta-framework like SvelteKit, and otherwise largely stays out of the developer's way. The documentation is concise, focused, and easy for a new developer to take in. That said, I find this simplicity to be a double-edged sword: by having such a narrow focus, it means that for nontrivial projects you'll almost certainly be using it in conjunction with SvelteKit or complementary libraries, at which point it's... not all that much simpler than the competition.
Vue is a step up in complexity compared to Svelte, adding multiple styles for writing components (Options API vs Composition API, templates vs JSX) and a number of bells and whistles that are only possible in a framework that uses a runtime and a Virtual DOM rendering system. The multitude of ways of doing things is arguably more of a historical problem than it is a lasting complexity, since the Composition API is the clear choice going forward. What's nice about Vue is that its features are progressive: you can learn the very basics and be able to write good, idiomatic Vue code, and then introduce larger concepts as you go along.
React suffers, I think, from being the first Virtual DOM component library on the scene. Its original reactivity model, for example, caused components to completely re-render much more often than necessary, and so the framework introduced Hooks in order to offer better control and, consequently, better performance. Hooks are difficult to get right, however (Example 1, Example 2), and Vue and Svelte offer the same or better reactive state management without the same level of manual management. It's a similar story across much of React's APIs: through being by far the most popular framework, it has grown to have a very wide range of capabilities, but this also greatly increases the scope of what developers need to learn in order to be productive React developers.
Performance
Performance is critical for Web apps, and frameworks achieve good performance in a number of ways, but primarily by minimizing the size of bundled scripts and by reducing the overhead of rendering components on the page.
Comparing the performance of these frameworks is nuanced, because of the way Svelte's design differs from React's and Vue's. The other two each include a runtime in the page which, among other things, updates the document using Virtual DOM diffing: the runtime compares the DOM to the Virtual DOM to identify which changes have been made, and then surgically applies those changes to the DOM. Svelte on the other hand, for each place where a component could make changes to the DOM, introduces a snippet of script which applies precisely that one change, much like you might do by hand if you weren't using a component framework. This avoids the potentially-costly step of diffing the DOM in order to identify changes.
As far as bundle size goes, this means that there is a break-even point between Svelte and React/Vue. A Svelte project will initially have a near-zero bundle size because there is no framework runtime to include, but on a per-component basis, it adds more script than a Virtual DOM based framework, so for larger projects, Svelte's bundle size advantages will diminish or even reverse (Analysis 1, Analysis 2).
Even if a large Svelte project ships more bytes of script, however, it avoids the overhead of Virtual DOM diffing, which is an advantage, and there are several tricks that can be utilized in order to compensate for having to download more script (like code-splitting or link preloading). So overall, it's very hard to say with certainty whether a given project would see a meaningful performance difference between these three frameworks.
There are a couple of ways to get a rough idea, however, the first being to look at benchmarks:
Despite Svelte's claimed performance benefits, it doesn't perform meaningfully better than Vue, whereas React lags a little behind.
A more realistic comparison is the aptly-named Real World demo application, in which Svelte performs great, Vue performs almost as well, and React again lags a little behind.
The big thing to remember with these comparisons however is that these are meticulously-crafted submissions meant to get the best possible score; real-world performance will depend much more on how easy the framework makes it for time-starved developers to write performant code (see the "Complexity for Developers" section above). With its manually-managed hooks, React makes this considerably harder than the others, and consequently it has a reputation for making it easy for developers to inadvertently create performance problems.
Overall, for mid- to large-sized Web apps, I don't think there is a strong performance reason to favour one framework over the others. Svelte may be little faster and React a little slower, but all three frameworks can be extremely fast and responsive.
Ecosystem
No nontrivial modern Web application is created without leveraging many additional libraries to manage tasks like client-side routing, state management, authentication, or UI components, and many of these libraries integrate closely with the framework. Consequently it's a liability to use a framework which has a small ecosystem of third-party libraries to lean on, and a boon to use a framework with a rich ecosystem any many well-supported options.
There's also the issue of talent, in that it is much easier to find developers with experience with a popular tool than a less popular one. The importance of this depends on how easy it is for an experienced developer to learn (see "Complexity for Developers" above).
React has by far the biggest ecosystem of any frontend framework. In a recent Stack Overflow Developer Survey, it dwarfs Vue and Svelte in usage among professional developers:
For a tech lead looking to make a practical choice of framework, this really makes React the default choice if all else is equal, in my mind. If any of these frameworks could meet your project's needs, then why wouldn't you select the one that makes it easiest to fill out a team of experienced developers, and the easiest to find whatever third-party libraries your team needs in order to be productive? The further you stray from the well-travelled path, the more challenging it becomes, and so the advantages of a less-popular choice need to be quite substantial.
To their credit, though, none of these frameworks have an ecosystem that feels lacking, even Svelte. Each has one or more popular meta-frameworks (Next.js for React, Nuxt for Vue, SvelteKit for Svelte) which provide the advanced and server-integrated features that modern Web apps increasingly demand, and a wide range of well-supported libraries.
Features
While each framework's corresponding meta-frameworks compete on all sorts of advanced features, honestly... for typical projects, there are few meaningful differences between the capabilities of these frameworks. Without going into great detail about every feature they offer and how they compare, the bottom line is that React, Svelte and Vue are all capable of building feature-rich and complex Web applications, and they all offer great TypeScript support, editor plugins, and tooling.
There are two notable exceptions worth mentioning. The first, and it's a small one, is that Svelte lacks "render function" capabilities, i.e. the ability to skip the template system and write a custom function whose output is the HTML content of a component. This limitation is fundamental to Svelte's runtime-less design. Having personally a great deal of experience working within template systems, I would say that in practice this is typically only a limitation for plug-in libraries seeking to be especially generic and flexible; I can't recall ever needing a render function in order to meet a project goal. The limitation is present however, and likely affects the capabilities of third-party packages.
The second and more important difference is that React has native Android/iOS capabilities via React Native that are unmatched by NativeScript-based tools for Svelte and for Vue, in terms of production-readiness. If it's valuable for your project to be able to build a native mobile app using a Web developer skillset rather than native Android or iOS development skills, then React is the framework which can deliver that.
Small-scale Viability
At Art+Logic we work on projects ranging from very small to reasonably large, so there is a lot of value in working with a frontend framework that is suitable for the full gamut of project sizes. This should arguably be a consideration for most teams, because most small projects could find themselves needing to scale up, and most large projects end up having small complementary projects like internal tools.
One of Vue's capabilities that makes it uniquely suited for small projects is that it can be used via a CDN <script> tag without any build system whatsoever. This means you can inject Vue onto a static page to introduce dynamic functionality to just a portion of it, or easily inject Vue into a project built using a different framework altogether. React and Svelte on the other hand are decidedly geared towards building a project within the bounds of their tooling ecosystems, limiting their small-scale flexibility.
For a green-field project however, Svelte's wafer-thin bundle sizes make it a great choice for small-scale or low-complexity projects. React, having the heftiest runtime of the bunch, is perhaps less advisable for a small project, but still is perfectly serviceable.
Retrofit and Migration Viability
With the frustratingly-fast pace of evolution in frontend Web development tooling over the last couple decades, many teams are left with older projects whose choice of framework has become a hindrance to continued development. A full re-write is a risky proposition, so it's powerful to have the ability to implement a gradual extension or migration in a modern framework.
Vue again is uniquely positioned in this regard: being the self-described "progressive framework", it is much more practical than the others to integrate into an existing project built with another framework. In React or Svelte, I would likely not attempt to anything more granular than a page-by-page conversion, but with Vue, it's easy to embed Vue within an existing codebase and build system. I once had occasion to implement a Backbone.js component which renders a Vue component, which in turns renders a Backbone.js component; you'll have to trust me that there was a good reason for doing so!
Large-scale Viability
All three of these frameworks have powerful build systems and meta-frameworks which enable all sorts of advanced performance-related features (such as prefetching links, server-side rendering, code-splitting, etc). As such, they're all able to scale up and competently handle large, complex projects.
I would personally have some hesitation with using Svelte on a large project however, this being for ecosystem reasons rather than technical ones. A large project is more likely to be difficult to migrate toward alternative technologies in the future, and more likely to require a wide variety of third-party libraries, both of which arguably make conservative technology choices more appropriate. In this case, that would mean choosing a framework with a larger talent pool and third-party ecosystem (i.e. React, or to a lesser extent Vue).
TypeScript Support
There's not much to be said here since all three frameworks have great TypeScript support, but it's worth highlighting that fact, since TypeScript is an excellent language choice for developing a robust codebase. It would be difficult to recommend a framework in 2024 which does not provide TypeScript as a first-class option.
Summary and Conclusion
To grossly oversimply the above considerations into a comparison chart:
| React | Svelte | Vue | |
|---|---|---|---|
| Complexity for developers | 🔴 | 🟢 | 🟡 |
| Performance | 🟡 | 🟢 | 🟢 |
| Ecosystem | 🟢 | 🔴 | 🟡 |
| Features | 🟢 | 🟢 | 🟢 |
| Small-scale viability | 🟡 | 🟢 | 🟢 |
| Retrofit and migration viability | 🟡 | 🟡 | 🟢 |
| Large-scale viability | 🟢 | 🟡 | 🟢 |
| TypeScript Support | 🟢 | 🟢 | 🟢 |
In general, React, Svelte and Vue are all excellent and production-ready frameworks, and a strong case can be made for any one of them. React offers a drastically larger ecosystem and talent pool in addition to native mobile capabilities, though it suffers from a higher complexity for developers and somewhat less reliable performance. Svelte offers cutting-edge performance, but its ecosystem is less mature. Vue sits somewhere in the middle, and offers the greatest versatility for a wide variety of project scenarios.
At Art+Logic, where "coding the 'impossible'" can take any number of forms, versatility continues to be one of the most valuable things we look for in a framework, and Vue continues to provide the most versatility while still ticking all the other boxes we expect it to. As such, it continues to be our preferred choice for frontend Web development.