I worked with angular and react on high traffic projects. One thing I realized is, that performance matters. I am not talking about seconds, but milliseconds.

For Mobify, every 100ms decrease in homepage load speed worked out to a 1.11% increase in session-based conversion, yielding an average annual revenue increase of nearly $380,000. Additionally, a 100ms decrease in checkout page load speed amounted to a 1.55% increase in session-based conversion, which in turn yielded an average annual revenue increase of nearly $530,000.

So if 100ms more load speed means, you lose half a million dollars, you better think about how to improve performance.

Of course this does not apply to all businesses. You cannot go for performance at all cost. If your product should be stable for several years and you do not have the resources to rewrite your software, because of breaking changes or the brutal life cycle of frontend frameworks, maintainability is much more important.

If you have complex software, which is really hard to re-write and you steadily built up a big community, scalability is probably more important.

This is why we are going to analyze competing frameworks, micro frameworks and new approaches to frontend development in this article.

At the end of this article you will know about all the important factors, which should go into your decision, when deciding for a technology or framework. I will also go into detail which technologies are suited best for which use cases.

Steps on our journey

• What makes web applications maintainable, scaleable and fast?
• When and when not to use single page application?
• Best solutions for static pages
• Best solutions for modular pages with dynamic elements
• Best solutions for single page applications
• Big players for single page application frameworks
• Micro-Frameworks for better performance and readability
• Cutting edge technology for best possible performance
• Conclusion: What technology should I use?

What makes web applications maintainable, scaleable and fast?

There are some general things, to take care of when writing frontend applications, which are not related to a certain technology or framework. I have created a broad overview and go into a little bit more detail afterwards. Feel free to skip this part if you just want to learn more about the technology specific factors.

Maintainability

Clean code — For bigger scale projects, I recommend reading the book clean code. Other than that there are a few important things to take care of:

• components and classes should fit on one screen if possible — this makes it much easier to understand what’s going on and helps you to maintain the single responsibility principle
• avoid boilerplate and duplicate code — if many classes, components or templates, share a lot of the same content, you should abstract it away in a separate file, so each file only contains what is important
• avoid generic variable names and classes — code should be reusable, that’s fine, but if you build too generic classes, your program will become unreadable and introduces areas of high risk for bugs, which no one wants to touch at some point

Documentation — Do not overdo it with comments in your code. Most of the time clear variable names should make it obvious, what you are trying to achieve. But one thing I always notice when I start working on a new project is: There is almost never a documentation about the structure and patterns used in the application. Searching for files and understanding patterns in an existing project is some heavy lifting, which takes a lot of time. Even worse, with no clear documentation or guideline, developers will mix in new patterns and violate current ones and introduce new levels of architecture, which are probably not even needed.

• have a style guide which defines how to build new features and how to extend the application for common cases (naming conventions and structure)— this speeds up the introduction time for new developers a lot
• comments in code should explain why you do something and not what — the code itself should be self-explanatory

Scalability

Modularity — While maintainability is more about readability, scalability is more about architecture.

• build modules — if your application has an editor and a file-system, these should be two different modules, which are imported into your main app and their functions are afterwards mapped to another class
• this way you can replace (e.g. completely re-write or use third party library) one of them and you will only have to adjust the mapper class in your main repository

Flexibility — Scalable systems can adapt to changing needs. Therefore single modules or even a certain technology has to be fungible. So a technology, which is less opinionated is better for a scalable project. A full-stack framework, such as meteor, can be good for rapid prototyping, but since you cannot easily change the underlying database or architecture of the server side, it is not that good when it comes to scalability.

• use specific technologies for specific tasks
• if you choose between frameworks, choose the less opinionated

Performance

Apart from that, the most important factors for frontend are bundle size, number of requests and rendering speed.

• be picky with npm modules — use bundlephobia to check the cost of a npm package before using it
• sometimes packages come at high cost and you may only use a small percentage of its functionality — there are often smaller packages available or you should consider writing a module yourself
• only import what’s needed — lodash for example offers the possibility of partial imports such as lodash/has
• be aware of how rendering works — many of the frameworks do a good job in determining whether or not to re-render, however libraries such as react have lifecycle methods like shouldComponentUpdate for a reason and your application probably re-renders way too often
• use pre-fetch , lazy loading , avoid polling and unnecessary requests

Before you think about all the mentioned optimizations you have to decide for an overall architecture (static, dynamic, SPA) and a technology stack. That’s why we explore the possible solutions and candidates for your tech stack now.

When and when not to use single page application?

Web applications become more and more complex and a lot of the business logic is shifted to the browser. jquery still has its place when it comes to accessibly and some quick and dirty DOM-manipulation. When using common cdn providers such as cloudflare the library is basically already cached for most users and you can built pretty neat stuff. This works for small and medium sized projects. But applications like spotify, facebook or netflix have teams of hundreds of developers. Different urls share many of the same components and since the app is cross-platform, you want to aim for something that feels and looks like a native application. If your application has a certain complexity, you want to build a single page application, to reuse components and only load required data via json upon any user action. Since tasks such as routing, state management and building reusable components are problems every single page application has to face, you will look for a framework to save you from all the headache the developers before these frameworks had to suffer.

Single page applications help you to create the feeling of a native application. However, you load all the business logic on the first page load. We will analyse later, that page loading time is a really critical factor to how much money you make. Therefore if your revenue depends on your initial side load, going for an SPA might not be a good idea. Of course you can have a fast loading landing page to catch attention and then redirect to a slower SPA once the user is committed to your product. The only important factor here: Does the initial page load directly impact your revenue? In most cases it boils down to the following: Does your customer visit your page only once, because he/she wants a certain product (e.g. targeted instagram campaigns) or a problem solved (e.g. law issue) and afterwards will most likely not return to your page for a long time or does he already know about the benefits of your product and will tolerate the initial loading time, because he plans using this product for the long term.

If you really want to aim for that native feeling, there are no decisions to be made, but more often than not, this is not even benefitial for your business. Here is a good video of academind comparing static, dynamic and single page applications.

Best solutions for static pages

If you generate static content, you can simply use a CMS such as wordpress, typo3 or drupal. Sites will be pre-rendered, cached and are easily optimized for SEO. If you want some little tweaks and features you can use jQuery.

Maintainability — don’t just use jquery and build one huge app.js or split it up into features all defined on global scope. Make heavy use of jquery plugins. Every feature you write should be defined in its own IIFE and should extend jquery as a plugin

Scalibilty — with the approach mentioned above you have a very modular system, with fungible components. You can easily replace parts of your application with third party libraries and plugins.

Performance — use for loops instead of each, use IDs instead of classes, cache selectors, bundle DOM manipulations (avoid DOM-manipulation in loops). If you use jquery from a cdn, it is cached in many cases and does not even add to loading time. Here is a good list of things to take care of:

Best solutions for modular pages with dynamic elements

If you want your pages to be modular, have re-usable components, things such as calendars, live editors or media players you might want to make use of frameworks such as vue or react, which are well suited for component based applications. You do not really need complex state management or routing and you still want to pre-render your pages. In this case gatsby and gridsome are optimal solutions.

You can build component based applications, which are compiled to highly optimized static pages, which can be hosted directly from your repository for free on providers such as netlify.

These tools make the development process a real joy. The documentation exactly tells you how to structure your application and vue and react are really good for component based applications. Gatsby and gridsome have hot reloading and are basically zero-configuration setups. If you do not have any special needs or use-cases, you can use these frameworks and do not have to take care about performance.

Best solutions for single page applications

If you want to go for the native like look and feel and want to build an application with live data, complex state and many re-renders you will have to go for a single page application.

Big players for single page application frameworks

The moment you decide to look for a framework you will most likely run into react, angular and vue, the oligopoly of frontend development.

You may also like: Angular vs React vs Vue: Which one will be popular in 2020.

If you are looking for a job as frontend developer these 3 frameworks are your save heaven. All 3 frameworks try to achieve basically the same thing and offer you the possibility to build single file components, handle application state and render content based on state. React and vue use virtual DOM while angular uses Zones.js to check for changes in the DOM. Angular and vue come with CLI tools and deeply integrated application state management solutions developed by the core team. React has react-create-app for CLI and you can use redux or mobx for state management, but these are developed by a third party. Moreover redux adds loads of boilerplate and if you want to use mobx with react-create-app you basically have to eject. React and angular are still dominating this game.

As you can see popularity of angular and react is steadily growing. If you wonder what angularjs is: Google noticed big performance issues with angularjs and decided to completely rewrite the framework. The new version is now referred to as angular and angularjs is basically deprecated. While vue still is considered to be one of the smaller frameworks, its popularity is growing exponentially.

And this is for good reason. They have a good comparison to other frameworks on their homepage. But let me give you my version of why I think vue is a good choice.

You may also like: Vuejs is Good ! But Is It Better Than Angular or React?.

Vue is much less opinionated (scalability)

Angular forces you to use typescript. While many people love it, it introduces another level of complexity to your application. Other then flow, you cannot rewrite existing code step by step — your whole application has to be written in typescript. They tell you, you can use angular without typescript, but 100% of the documentation and resources are in typescript, so this is bullshit. With vue you can use vanilla js or typescript, if you think it is worth it.

React forces you to use JSX. They tell you, you can use it without JSX, but same situation as with angular. 100% of the documentation and resources is based on JSX. I know many people love JSX, but I am questioning it. Developers over the past worked hard to completely separate logic and markup, now we mix them again. When looking at it, it seems logical at first, because of the component based architecture of applications. But why not simply create one folder for each component and have separate html, javascript and css files instead of mixing everything in one file? Not only we depend on special syntax highlighting in our IDE, but these single files become too big to understand what’s going on. People in the community come up with super “revolutionary” ideas such as smart and dump components. Now dump components are basically templates and smart components contain our business logic. Isn’t this what we had before? Now we need MyComponentSmart.jsx and MyComponentDump.jsx instead of a javascript and a html file. And we cannot use any pre-compiler such as pug. Good job man! With vue, you can use JSX, but you are not forced to do so. You can use good old html, add vue directives and even use pre-compilers.

Vue is developed by a dedicated team (maintainability)

People jump on Angular and React, because they are developed by google and facebook. These are too big to fail, so using their products is a safe bet, right?

Well, google is not really using angular for any important product. They already abandoned version 1 and they could do the same with version 2 if they notice some other framework has better solutions and more traction (remember that chart with vue going crazy?). Moreover they have other promising projects, such as flutter. Flutter will support web too. It looks quite promising.

Facebook cannot die? Rachel Botsman, one of the worlds leading trust-researchers thinks different.

I don’t want to go into a fight whether facebook will survive or not, but why take the risk? Even if development would be taken over by the community, would the ecosystem still grow? Since react has no integrated solutions for CLI, application state management and routing, these would have to be maintained as well.

Vue is developed by a dedicated team, which learned from the mistakes of angular and react. They have deeply integrated solutions for state management and routing (both optional). They are not a little side project of google or a replaceable technology of a company with a more than uncertain future. They work together with alibaba and apache to build weex, a platform for building performant, high traffic mobile applications using vue. Growth of vue questions, resources and usage is exponentially at the moment. These facts combined with all the mentioned benefits makes it an easy decision if you have to choose a technology for your next production app.

Vue is smaller (performance)

Size matters. Don’t let anyone tell you otherwise. Smaller is better.

When to use React/Angular/Vue?

Now this probably seems like a no-brainer. Vue all the way. I just mentioned all the benefits. But the real world is not just black and white. All these frameworks have a big community. But there they all have their special use-cases.

React has the biggest and most thriving community. This means you have many developers on the market ready to help you build your product. Moreover react-native has become quite popular, so it is a good choice for building cross platform applications. “React is only the view” means state management, routing and other things have to be handled by the community, but also means, you are free to create your own stack. Want redux, mobx or some other state library? No problem. React is good at what it does and has the biggest community right now. So if you want to ship fast, like the flexibility or want to build performant (native) multi platform mobile application (IOS/Android), react is the framework for you.

Angular enforces a certain application structure and the usage of typescript. This can especially be good in really big applications, since typescript catches errors at compile time and enforcing certain patterns means, new developers have an easier time to understand what’s going on. Moreover you can build mobile applications with ionic, which are rendered in a web-view. If you want to build multi platform mobile application (IOS/Android) and performance is not an issue (rendering hundreds of elements per second) angular is probably the better choice. Ionic supports PWA and let’s you escape the app stores. No app discovery problems anymore. Just buy google ads and you can calculate customer acquisition cost, based on your investment.

Vue has a really fast growing community. It is probably not that easy to find experienced developers, but developers experienced with react or angular should have a fairly easy time to learn the framework. Native applications, such as the ones react native creates, are already possible with native script. As mentioned before, vue is working together with alibaba and apache to build a platform for creating mobile applications for performance intensive, high-traffic, multi-platform applications. We are talking about partnerships with a company competing with amazon and one of the most established names in the open source community. At the same time the development does not depend on the success of one single company. Vue started as a side-project by a google employee and became self-funded over patreon. When the community grows and more people/companies depend on its development, more money will flow into the project. So if performance, reliability, readability and flexibility of your codebase is important, vue might be the right pick. Soon it will also be possible to build reliable, performant mobile apps with it (native script, weex). When it comes to community and mobile apps, vue still has its disadvantages, but considering its rapid growth, these will soon be negligible.

You may also like: Difference between React and Vue when Creating the Same Application.

Micro-Frameworks for better performance and readability

The mentioned frameworks are a good starting point for any project, but at some point you are going to realize that performance matters

As I mentioned earlier vue is only 21kb and this is one of the main reasons why I would choose it over react and angular. But there are other options for SPA frameworks.

So if performance has such an big impact on conversion rate, we should investigate these micro-frameworks and their benefits and trade-offs.

Preact — preact is basically a good alternative, if you already worked with react, but you want to lower the size of your bundle dramatically. With preact-compat (~5kb bundled with preact) you should be able to use the complete react api and simply replace react with preact (alias). However you might run into issues when you use many react based npm packages.

Markojs —markojs is developed by ebay. It is not only much smaller, than all the big frameworks, but also much more cleaner and readable (maintainability). Similar to react/preact it does not come with global state management and routing tho.

Riotjs — riotjs is very similar to markojs. small, clean syntax. They provide a good comparison to react on their homepage.

Mithril — mithril is even smaller than markojs, but comes with integrated solutions for routing and ajax requests. However it is not as readable as markojs.

Hyperapp — hyperapp comes with an optional router. Other than that I see many similaraties to mithril. But Hyperapp takes it to the extreme and tries to provide its library with minimal footprint (1kb).

Any of these mentioned libraries is probably a good choice, if you really want to go for better performance. Which to choose depends on whether you need routing or not, if you prefer readability over performance and if you depend on certain libraries and how good they work together with the chosen framework.

The main problem is they mostly have small communities and not many plugins/libraries/npm packages so you probably end up re-writing basic functionalities. But if performance matters for you, you should probably still consider doing it.

Cutting edge technology for best possible performance

Now many of these frameworks use a virtual DOM to compare the actual DOM with the virtual one and find the best possible render method. But this action is basically triggered hundreds of times and can become performance intensive too. It would be much more performant to have a predefined DOM manipulation for every action. We use pre-compilers for JSX, ES6, eslint and more already. So why don’t we pre-compile every action too. Then we wouldn’t even need a virtual DOM. Maybe we would not even need a library to be included in our app.js at all. All we need is a good compiler, which compiles our easily readable code into native javascript. Svelte does excatly that.

Svelte is readable (maintainability) and has no overhead (performance)

Svelte is pre-compiled. It is a framework without the framework. We can write easily readable, understandable code, similar to markojs or riotjs, which is compiled to highly performant vanilla-js, which does not rely on any library. Svelte does not need any virtual dom, because all DOM-manipulations are defined at compile time. So the virtual DOM is pure overhead

Svelte compiles to javascript and supports interoperability (scalability)

Consider interoperability. Want to npm install cool-calendar-widget and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if cool-calendar-widget was built in React and you’re using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.)

Svelte is relatively young project and probably will have many big changes in the near future. But it solves many of the issues we have with the current frameworks. Since react, angular and vue are mostly used for single page applications and together with routing and state management, I would not be surprised if they already work on similar pre-compilers, to overcome ever growing library size and more complex syntax.

Their documentation, examples and REPL are excellent and easy to pickup, you should give it a try and give it a star at github.

Conclusion: What technology should I use?

mostly static page?

• CMS + jquery and plugins

dynamic page?

• gatsby or gridsome

single page application?

• vue for maintainable, scalable and performant SPAs
• react if you consider writing a native app and want to benefit from its big community
• angular for maintainability and ionic (web apps/ PWA)
• micro-frameworks if you need better performance
• preact if your transfer from react
• markojs or riotjs if readability is more important
• mithril or hyperapp if performance is more important
• svelte if you want the best of performance and readability, but can live with breaking changes and still low community support

Thank for reading!

#javascript #angular #vue-js #reactjs #jquery