How you ever wondered how the frontend frameworks you use work internally? Are you curious about how they decide when to re-render a component, and how they do to only update the parts of the DOM that change? Isn’t it interesting how a single HTML page can change its content without reloading? That the URL in the browser’s address bar changes without requesting the new page to a server? The inner workings of frontend frameworks are fascinating, and there is no better way to learn about them than by building one yourself, from scratch. But why would you want to learn how frontend frameworks work? Isn’t it enough to just know how to use them?–you might ask.

Good cooks know their tools; they can use knives skillfully. Great chefs go beyond that: they know the different types of knives, when to use each one, and how to keep their blade sharp. Carpenters know how to use a saw to cut wood, but great carpenters also understand how the saw works and can fix it in case it breaks. Electrical engineers not only understand that electricity is the flow of electrons through a conductor, but also have a deep understanding of the instruments they use to measure and manipulate it; for example, they could build a multimeter themselves. If their multimeter breaks, they can disassemble it, figure out what’s wrong, and repair it.

As a developer, you have a frontend framework in your toolbox, but do you know how it works? Or, is it magic to you? If it broke—if you found a bug in it—would you be able to find its source and fix it? When a single-page application changes the route in the browser’s URL bar and renders a new page without requesting it from the server, do you understand how that happens?

Why build your own frontend framework?

The use of frontend frameworks is on the rise; it’s uncommon to write pure-vanilla JavaScript applications nowadays, and rightly so. Modern frontend frameworks boost productivity and make building complex interactive applications a breeze. Frontend frameworks have become so popular that there are jokes about the unwieldy amount of them at our disposal. (In the time it took you to read this paragraph so far, a new frontend framework was created.) Some of the most popular frontend frameworks even have their own fan groups, with people arguing about why theirs is the best. Let’s not forget that frontend frameworks are tools, a means to an end, and that the end is to build applications that solve real problems.

All of the most popular frameworks at the time of this writing are exceptionally good: Vue, Svelte, Angular, React… you name it. Which brings us to the main question you might be asking yourself: If there are so many great frontend frameworks, why build your own? That’s a great question because if there is something the JavaScript community doesn’t need, it’s another frontend framework. First, building your own framework is rewarding and so much fun: building a complex piece of software yourself, from scratch, is a great feeling. It sparks joy. But apart from the undeniable joy of it, there are some more pragmatic reasons why you’d want to build a frontend framework yourself.

What do you need to know to use this book?

To make the most out of this book, I’ll assume that you’ve got a decent understanding of JavaScript, Node JS and the Document API in the browser.

What will you learn in this book?

Throughout the book, you’ll learn the most important concepts behind what makes frontend frameworks such useful tools, but not through lots of theory, but by writing all the code yourself. You’ll learn:

1. Using the Document API to create HTML documents programmatically
2. What the virtual DOM is and how it helps defining the view of an application
3. Updating the HTML view using the smallest set of operations, using to the reconciliation algorithm
4. How Single Page Application (SPA) routers work by changing the view without reloading the page
5. How a Webpack loader that transforms HTML templates into JavaScript render functions work
6. Rendering a web application in the server, and rehydrating (making it interactive) in the browser. This is how Server Side Rendered (SSR) applications work.

You’ll start by writing an application using just JavaScript, without a framework. From that exercise, you’ll identify what are the pain points of writing applications without the help of a framework. It’s crucial that you understand the need for them in the first place; after all, we take them for granted these days. You’ll then create your own simple framework to address what you’ll discover is the main problem with vanilla JavaScript applications: the mix of DOM manipulation and business logic code.

After just two chapters (chapters three and four) you’ll have a working framework, a very simple one, but a framework that you can use in small applications nevertheless. From there onwards, you’ll keep adding improvements to it, such as a Single Page Application (SPA) router that changes the page without reloading it, or a Webpack loader to transform HTML templates into render functions.

By the end of the book, you’ll have written a pretty decent framework of your own. Not only can you use this framework for your own projects (something that’s extraordinarily satisfactory), but you’ll share it with the rest of the world via NPM. You heard me well! You will be publishing it the same way the big frameworks get released. Sure, the framework won’t be even close to competing with the big frameworks out there, but you’ll have a good understanding of how they work that you can use to keep improving yours. But more important than creating a framework that can compete is the amount of fun, gratification and learning that you’ll get from working on this project. Figure 1 shows the example framework that you will build throughout the book.

Figure 1 Architecture of the framework we’ll build

I’m looking forward to you getting the same feeling of accomplishment as I did when you see your own frontend framework—written from the ground up—power web applications. There’s something magical about building your own tools and seeing them working.

If you want to learn more about the book, check it out here.