Late again. I suppose you should expect the last few posts to be published weekly or biweekly by now.

In the 2010s, we had initial JavaScript frameworks coming out that were intended for use at production scale.

The earliest ones were Backbone.js, Ember.js, and AngularJS. I haven’t actually used any of these frameworks, but with a little study we can find some key differences.

Declarative vs Imperative programming

If you watched the video at the top of my second post, then you’ve heard of these terms before. Essentially, imperative programming involves detailing the steps to a solution, whilst declarative programming offers the programmer an abstraction layer to declare exactly what it is they want the solution to be.

An example of this can be seen with the React library. Instead of using vanilla JavaScript to create DOM nodes and add or manipulate them, you simply use React to say what HTML code should be rendered.

// Imperative
const input = document.createElement('input');
input.value = 123; // default value
input.type = 'number';
document.getElementById('root').appendChild(input);

// Declarative
export default function Input({ defaultValue, type = 'number' }) {
  return (
    <input value={defaultValue} type={type} />
  );
}

Many JavaScript frameworks differ in this regard. For example, Backbone.js is written imperatively, whilst AngularJS was written declaratively.

Thus, we find one of the potential faults of JavaScript frameworks. Because many of them are written to provide the developer a declarative abstraction layer, you are required to learn how to program declaratively in the manner in which the framework wants you to. To generalize this, we could say that some programming frameworks and libraries want you to program in specific styles, which means you need to learn not just how the library works, but also how it wants you to make it work. Therefore, learning something like React can often feel like learning an entirely new programming language.

This falls in line with what we discussed in the second post as well. JavaScript was written as a multi-paradigm programming language, so when using libraries and frameworks you will run into many styles of programming.

So, there is a learning curve for these frameworks. I think (this is just my opinion) that this is why there are so many JavaScript frameworks out there today. In general, there are a lot of people out there in the world with all kinds of different ideas about how things should work. Because JavaScript allows for so many different designs, that means that people with all kinds of ideas can develop those out for themselves. Two or three might stick around for good, but that doesn’t stop people from creating their own version of them with some minor or major edits.

The big three

React, Vue.js, and Angular are the kings in the JavaScript framework world. I have worked with both React and Vue.js, so I will focus on those.

Both of these use a virtual DOM. The framework essentially has it’s own DOM, which you as the developer update and manipulate. The framework will then compare changes to the actual DOM, and update as necessary.

React

As we saw earlier, React provides itself as an abstraction layer to give the developer declarative-style programming. This can be a valuable tool because you can modularize your code to provide reusable components. Instead of declaring the same piece of code over and over again, React makes it easy to declare a component and just use that instead.

Vue.js

Vue.js also gives you tools to write JavaScript and HTML code declaratively. It provides several helpers that might be more hidden in React, so in that way it can sometimes have less of a learning curve.

Disadvantages

Frameworks and libraries can be helpful, but you must first ask yourself if you require one. If you are writing a simple webpage with basic information about a business, you probably don’t. If you are writing the next big e-commerce app, then it will likely be very helpful to you.

You need to understand that although bundler and build tools can compile and minify resources down to a fairly small number, people still need to download those upon visiting your page for the first time. Therefore, performance can be a factor.

Despite the idea of a framework being to make your code less complex, if you aren’t past the learning curve then writing bad code will likely make it more complex.

Lastly, your application is now dependent on whatever libraries you use. Therefore, getting the app to production could require even more special tooling like containerization. Also, whenever the library updates, you must either jump ship or follow along (hope they have an upgrade guide!).

You now know some more about JavaScript framework history and use. The most important takeaway should be that it’s up to you as a developer to know what your tools are and when to use them. It’s important to research things and decide what can give your users the best experience. Picking the most popular thing is not always the right solution.

Next week we will discuss JavaScript derivatives (largely focused on TypeScript).