Choosing a Frontend framework in 2024, a practical tale

Introduction

I find that one of the hardest parts of starting a new project that requires a user interface is having to choose between the endless options that exist in the front-end ecosystem - React, Vue, Angular, Svelte, HTMX - to only name a few.

I bumped into this recently when attempting to choose the technology for a new upcoming work project. So, I thought I'd document my thought process in hopes of sharing my findings.

I hope that this article will be of value to devs in a similar position, and also to those who have little FE experience and want to understand the current challenges in the ecosystem, some solutions that exist and what each brings to the table.

    

What's in this article

I will compare 5 notable FE frameworks/libraries that are either popular, on-the-rise, or both:

• ReactJS, and the React-based frameworks NextJS and Remix
• SolidJS
• HTMX

I will give a short description of each, as well as a few pros/cons as I see them for my own situation, and finally, I will share my decision.

I am  taking into account that in the near future more people will join me in maintaining this project as it grows in scale, so I'm looking for a solution that will seem easy to kickstart but also to maintain and grow.

    

About myself

I'm Nitzan, and I've been a (mostly Web) developer for the past 7 years. I come from a hands-on cyber background but found that my passion is in the intersection between technology and the user experience, hence my passion for frontend. Over those 7 years I worked on multiple cybersecurity products, generally focusing on threat detection and asset visibility, and will continue my journey with a new startup in the very near future 🙌

    

TL;DR plz!

Skip to the final section at the bottom :)

    

Dictionary

If you come from a FE background you can probably skim through this section, but I think it's necessary for understanding the bigger picture in the comparison later.

• SPA = Single page application; A website that re-renders its content in response to navigation actions (e.g. clicking a link) without making a request to the server to fetch new HTML
• CSR = Client side rendering; A web development approach where the rendering of a webpage occurs primarily in the browser using JavaScript. This approach is closely associated with SPAs.
• SSR = Server side rendering. The initial content page of the website is generated on the server, so that browser can download a page with HTML content already in place. Updates to the content are still handled in the browser.
• SEO = Search engine optimization; It's the practice of optimizing websites to improve their visibility and ranking in search engine results pages. When SEO is important, SSR approach is preferred over SPA.

    

• DOM = Document Object Model; A programming interface for web documents. It represents the browser page as a tree of objects, where each object corresponds to a part of the page. Via the DOM, programs can change the document structure, style, and content (objects/elements within).
• VDOM = Virtual DOM; A concept implemented in libraries like React. It's a lightweight copy of the actual DOM. The VDOM allows for efficient updating of the web page, as it involves only re-rendering components in the VDOM when their state changes, therefore optimizing rendering (and potentially performance), and providing a smooth(er) user experience.

    

    

• UI component = a self-contained and reusable piece of code that represents a part of the user interface (e.g a button or a form)
• JSX = Syntax extension to JavaScript, combining markup (HTML) with the power of javascript. This syntax is commonly used in the React ecosystem, and UI components in React are usually written with JSX syntax.
• State Management = the process of managing the dynamic data, or "state", that controls the behavior and appearance of an application and its UI components. This state can include user inputs, server responses, and other variables that determine what the UI displays at any given moment.

    

    

Lets compare!

React

    

React is a JavaScript library used for building user interfaces, primarily SPAs (at least historically). It allows developers to create reusable UI components, manage the state of these components, and efficiently update and render just the right components when data changes (using the VDOM approach).

Upsides:

• It has an incredibly large developer community, leverages widely-used JSX syntax, and its idiomatic nature to JS/TS can be a lesser learning curve for people coming from the JS ecosystem.
• It has proved itself to be a very stable option for many years now and a favorite among web devs, and therefore its not surprising that the job market favors it (and, while this isn't strictly a "technical" reason, it is still important when focusing on long-term maintainability)

Downsides:

• React is a UI library at its core (not a framework), therefore it requires, by definition, the usage of additional tools to reach its full potential. While this "unopinionated" approach makes React more flexible on paper, it can make its DX for large scale applications worse compared to meta-frameworks like NextJS, that provide more out-of-the-box features and therefore requires less code to be written.
• As of writing this, there's a lot of criticism of React and where its heading. Apparently, React themselves recommend using a meta-framework and not just "plain React" in their "getting started" page, which is... interesting. I particularly resonated with this article, and also enjoyed this funny video, which I think explains the current turmoil in the React ecosystem (and FE ecosystem in general) pretty well.

    

    

Solid

    

Solid is a JS library for creating user interfaces. Instead of using a Virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions. While React is well known for its declarative architecture, SolidJS takes a different approach to state management and reactivity.

Upsides:

• Its bare-metal, minimal abstractions approach allows for direct access to the DOM, making it easy to use native JavaScript libraries.
• It is more performant and efficient than React - when there is a change in data, it updates only the necessary components (meaning in cases of deeply nested components, it would perform better than React's VDOM).

Downsides:

• Both because SolidJS is relatively new (created in 2018) and because of its relatively-small community adaptation, there's limited documentation and less available tools and plugins. These reasons, especially compared to React's mature ecosystem and community support, makes SolidJS less appealing, especially when building large scale, complex applications.
• While SolidJS provides efficient SSR capabilities, it does not not offer a built-in, comprehensive solution for hybrid rendering similar to Next.js, which seamlessly combines Server-Side Rendering (SSR), Static Site Generation (SSG), and client-side rendering within the same application framework.

    

HTMX

    

HTMX is a library that allows you to access modern browser features directly from HTML/markup, without having to utilize JavaScript. It encapsulates AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML using attributes, so you can build modern user interfaces with the simplicity and power of hypertext. With HTMX, elements can now issue an HTTP request, any event can trigger API requests (not just clicks/form submission), and any element can be the target for update by the request (not just the entire window).

Upsides:

• Has the potential to simplify the tech stack dramatically - no more different BE and FE frameworks and duplicated utility functions, straight-forward deployment.
• Developer velocity can be greater by eliminating the need to juggle between FE and BE for small changes - no more need to understand the entire code architecture to follow a feature end-to-end (just use "go to definition"!).

Downsides:

• HTMX, while on-the-rise, remains a smaller community compared to React. Its adoption by the job market and web developers, particularly for large-scale applications, is still limited today next to older frameworks such as React.
• HTMX still doesn't fully replace existing market technologies, especially in developing interactive, complex applications. It has limitations such as client-side interactivity, lack of reusable components and type safety. These factors are essential for scalability and maintainability of applications as they expand.

    

NextJS

    

NextJS is a framework built on top of React that enables functionality such as SSR and SSG, which are not readily available in vanilla React. It implements a set of conventions for structuring React applications as well as commonly needed features like automatic code splitting, optimized prefetching, and route preloading out of the box, offering a streamlined setup for building fast and scalable web applications.

Upsides:

• It's a stable, well-established framework with a mature ecosystem, has a large community and has been going stronger and stronger for years. Even though its a meta-framework, NextJS still feels in-line with how React themselves are evolving the library, being the first mature implementation of React Server Components, and as I said above, the first option that's recommended in React's "getting started" page.
• The conventions and out-of-the-box features implemented by Next make it a very robust choice, especially fitting for larger-scale applications.

Downsides:

• Next has a relatively big learning curve - both needing to learn about the React ecosystem as well as Next's own robust ecosystem. Even developers that have used Next previously (most likely with the Page Router) could still have a big learning curve getting used to the App Router paradigm, which has been deemed stable in Next's v13.4 release in May 2023 (just less than a year ago).
• It's owned by Vercel, meaning it also leans towards Vercel as a hosting platform and raises concerns for vendor lock-in. While it is possible to deploy without Vercel, I tend to prefer solutions that allow for easy deployment in whichever way ends up being chosen.

    

Remix

    

Remix is yet another meta-framework built on top of React, which similarly to NextJS, also implements many common features and use-cases out-of-the-box such as enhanced data loading and caching mechanisms, optimized network requests, built-in state management for forms and more.

Upsides:

• Remix places a strong emphasis on leveraging web fundamentals, aiming for accessible and performant web applications, and features a very straight-forward, declarative syntax for data fetching and data mutations, with the concepts of "loaders" and "actions". This relatively low learning curve (especially for devs with React knowledge) makes it a very interesting candidate.

• Remix seem to fair better than NextJS in performance and build-related aspects (serving static and dynamic content fast even on slow networks, stable build times, etc), and the framework itself focuses on flexibility as to not sacrifice performance or require application architecture changes when your data scales.

Downsides:

• As of February 2024, Remix has yet to implement React Server Components (which seems to be the future of React), and has a smaller community relative to other React meta-frameworks, specifically Next, making Next the more obvious and "safe" choice for a new large-scale application focusing on maintainability.
• Its been acquired by Shopify, which draws skepticism that stem from concerns about the future independence and direction of Remix under Shopify's ownership (especially because of its open-source nature)

    

Some more thoughts on Next vs Remix

As I wrote above, Next indeed seemed like the more obvious choice at first glance, but I thought it would be right to try out both before choosing one over another.

After experimenting with both, I can say that writing in Remix was a very smooth and pleasant ride, while getting used to the new App Router paradigm in Next was not too enjoyable for me. It seemed, with Remix, I could spend 2 minutes on reading documentation and get the application up and running, while with Next I had to spend a lot more time reading about the in-and-outs of the App Router and React Server Components just to get a basic example working.

So, after trying it out myself and doing a lot of reading (especially this great article), and to my own surprise, I actually felt more comfortable choosing Remix over Next, and I look forward to seeing how they decide to implement React Server Components in the future.

    

Final Thoughts

I'll be picking Remix for a few main reasons:

• It's built upon the well-known React ecosystem and implements great abstractions for routing, data fetching and mutations, and I find it has a very small learning curve for devs with previous React knowledge (which is common as its favored by the job market).
• I like how flexible the framework is (regarding deployment and otherwise), and I particularly love their philosophy and the emphasis they put on web fundamentals.
• Remix fits great to our planned architecture - since the main business logic will be written in a non-JS language, we will use Remix in a "BFF" (Backend for Frontend) architecture, which is also a strategy recommended by Remix themselves.

That said, I'm extremely intrigued by HTMX because of their innovative approach, but I think that at its current state and community adaptation it's too much of a risky choice. I will definitely try out HTMX for my next personal project though!