“The Sound of Music” may preach, “Let’s start at the very beginning, a very good place to start.” But almost every developer knows it is a foolish plan. The right place to start is with a firm foundation built by a great team of open source developers. Clone their hard work and then add just enough code to make it your own. There’s no need to repeat what everyone has done before.
It’s an easy plan—once you choose. Unfortunately, choosing that foundation can be almost as hard as starting at the very beginning. The world of web frameworks is a very active area of development and there may be dozens of good open source projects that would be great starts for your project.
To make matters worse, the different teams who created these different projects set off on a different path because they had serious philosophical differences with the other options. They looked at the other frameworks and decided that they could do better. In other words, they did it for a reason and you may or may not agree with their decision.
The list of good places to start below intentionally leaves off the market leaders React, Angular, and Vue just to make things a bit simpler. That doesn’t mean the big three are bad. They still might be the right thing for you. It’s just that they’re talked about constantly and those discussions leave out some pretty good other options.
There are plenty of good reasons to pick the most popular. Many people in your shoes looked around and many of them chose React, Angular, or Vue for a good reason. But that was then. In the meantime some smart people have created newer frameworks that are faster, simpler, stronger, or any of a big set of superlatives.
In most of the cases below, the teams created something intriguing and powerful by reimagining the nature of the framework. That’s a fancy way of saying they ended up deleting a feature thus making the framework more efficient and thus reducing the amount of memory it needs, speeding the startup time, or generally making it more nimble. Or in a few cases, they added new ideas that may become standard in the future.
If you’ve got the time to invest, here’s a list of some of the other interesting choices. They’re not necessarily right for some people and they’re certainly not the best choice for all, but they might be a better choice for you. Your job, if you choose to accept it, is to create a solid description of your web application, write down a relatively firm description of the different use cases, and then evaluate these tools with this in mind.
Perhaps you like a particular approach to designing code. Perhaps your app doesn’t need some of the features in the fatter, more popular frameworks. There are dozens of reasons for investing in one of these other paths. You might just find that one of them works wonders for your application.
Petit DOM
If you love the idea of a virtual DOM, but you don’t want all of the constraints that come with adopting the mindset of the folks at React, Vue, or your other big name framework, then the Petit DOM is the way to go. You get a tiny amount of code that will let you manipulate a virtual collection of tags and then migrate them to the real DOM. Everything else about the structure of the components and the rendering is up to you. If your components are simple, or if you’re going to create some super-complex rendering hierarchy that will be yours alone, this could be your foundation because all it provides is a tool for virtualizing the DOM.
Surplus
The virtual DOM may not be for everyone. It takes up space, so if your manipulations aren’t too complex, you might as well pipe your instructions right through to the official DOM. The Surplus library does just that. It takes everyone’s favorite markup JSX and compiles it into some code that will manipulate the real DOM. As they say in the ad business, it cuts out the middleman. No diffing. No secret extra layer. Just pure manipulation of the real DOM. If your code is simple and direct enough to do just a few things to the DOM, why bother with the virtual distraction?
RE:DOM
Another option for those who don’t want to invest any memory in a virtual Dom is a tiny library (2KB) called RE:DOM. RE:DOM contains some basic routines that let you create all of your tags and components with a few simple JavaScript calls. The syntax is much closer to CSS, so you can specify fairly elaborate tags with IDs and classes with just a few keystrokes. Your “less than” (<) and “greater than” (>) keys will thank you.
Mithril
Not all of the alternatives are tiny and minimalist. Mithril might be called a “midsized” framework in this context, although it weighs in at only around 8KB. All of this code builds a virtual DOM with an efficient updating mechanism like the others, but it also comes with a standardized set of tools for dealing with many of the standard challenges like routing and XMLHttpRequest calls. The project designers want Mithril projects to be relatively standardized, and they feel that adding this code to the main library increases standardization. If that’s not enough, they also push some standard formatting and idiomatic structures.
Bobril
If you like the virtual DOM and stateful components of React and you like to program in TypeScript, then Bobril or its Angular-friendly cousin ngBobril may be just the ticket. The framework is consistently much faster than either React or Angular in some of the benchmarks, perhaps because of the faster diff algorithms and the lack of support for isomorphic JavaScript. There are also shorthand functions for CSS manipulation and a complete state management layer, BobX, if you need it.
Marko
If you’ve been spending any time bidding on Pez dispensers or other collectables, you’ve experienced the power of Marko, a slim, fast framework that eBay is sharing through an open source license. The nicest part may be a very lightweight templating syntax that cleverly removes most of the excess fat from HTML so that the structure is defined by indentation and not much else. And the rendering engine is very speedy, capable of driving elaborate constellations of dancing DIVs that update faster than 60fps.
Svelte
Your standard web framework comes with a compiler and a downloaded library that handles at runtime what the compiler produces. The two-step process allows for very elaborate code at the price of waiting for the runtime library to be downloaded and parsed every time the page is opened. The Svelte compiler gets rid of this complexity by spitting out close to pure JavaScript that’s almost ready to run on its own, albeit only in some of the newer browsers (e.g. Chrome, Firefox, Opera, and IE10). It’s a clever architectural gambit that produces very lightweight websites that take up little memory.
Inferno
Inferno is another framework created to do much of what React does, but with a smaller download and a faster run time. It achieves much of this by throwing away the elaborate synthetic event mechanism and concentrating only on the most essential ones like onClick. Many other parts of the API are similar if not the same, making it relatively simple to move your code over if it doesn’t need the event optimization layer.
Preact
One of the smallest of the React descendants is Preact, an homage that offers most of the most valuable features like a virtual DOM and sophisticated components but strips away the synthetic event handlers and some of the props inheritance. While Inferno tries to implement only the most important events like onClick, Preact doesn’t bother trying to do anything with the events, leaving you to rely upon the browser’s native addEventListener. Leaving out features that don’t add much (in their opinion) is how they make their download even smaller. This is a bit of a tradeoff because the benchmarks show that Preact is a bit slower than Inferno. Of course, your application may be different and your mileage may vary. If you really need pure compatibility with React, there’s even a library (preact-compat) that fixes most issues during build.
Hapi
Many frameworks arrive in one single chunk. Hapi is more a collection of plug-ins, a constellation of dozens of bits of code that you can mix into your stack as you see fit. Authentication, authorization, and logging are chores that can be solved with any number of options. If you are building a microservices architecture full of APIs, the standardized Swagger plug-in will automatically generate the Swagger documentation from your basic code.
Koa
Sometimes you need a fairly complex collection of routines that juggle incoming requests and translate them into multiple changes, some of them elaborate. Koa is designed to make organizing all of this work a bit simpler. Its secret is that it turns the callback functions that normally dominate JavaScript into a set of asynchronous functions that fire when the time is right. The nested spaghetti callback stacks are turned into something a bit cleaner.
Nest
Another option for taming the complexity of the server comes from the Nest team, who offer an architecture filled with controllers, pipes, and providers with some guards, interceptors, and exception filters tossed in to keep order. The framework is modern and ready to handle GraphQL and microservice requests right from the get-go.
Drupal, WordPress, and Rails
Frameworks that are built in JavaScript and that run on top of Node.js fill the psychological center of the web development world these days. But it can be a mistake to ignore the previous generation built on PHP, a foundation that’s faster than ever now that it also has a just-in-time compiler like JavaScript. And Ruby and its Rails framework continue to serve as the cornerstones of rock-solid websites.
The last generation is battle-scarred and well-tested by more than a decade of continuous development and work. There are sophisticated designers who can turn out themes and skins for the apps. There’s a good chance someone has already built the modules with the functionality you need. So before you explore a clever Node.js framework, consider whether one of the oldies can already do much if not all of what you need.
Vanilla JS
You might see it as a mean dig or perhaps a satire on the level of “The Emperor’s New Clothes,” but it’s hard to argue with its success. Vanilla JS is a website that brags that its framework is used on more websites than “jQuery, Prototype JS, MooTools, YUI, and Google Web Toolkit—combined.” This may or may not be true given the proliferation of jQuery, but let’s laugh at the burn. The site also comes with a cute little selector that lets you bundle together a custom archive of different components like Math, DOM, closures, or regular expressions. No matter what you choose, the result is a mind-boggling zero bytes long. Try and beat that one!
The point of the joke is that sometimes it makes sense just to use a few of the standard elements in JavaScript and skip the extras. Libraries and frameworks like jQuery or React began, in part, because of the maddening differences between the browsers. Many of these differences have disappeared thanks to standardization.
Of course the Vanilla JS proponents don’t confront the fact that shorthand functions like $() are not just convenient, they also save space in our own code. But if you’re only going to be using the document.getElementById occasionally, it might not matter. If you’re just going to be adding a few functions to your webpage and those functions will do a few basic things, plain vanilla JavaScript may be the fastest framework for you.