I've read far too many articles this week about why developers should avoid using JavaScript frameworks in lieu of plain old vanilla JavaScript. A few reasons being:
- Vanilla JS can be faster
- It's better for understanding the language
- Less restrictive
- Reduced dependencies
- Less complicated to use
And I, for the most part, agree with most of those statements. A framework (any framework) doesn't come without a cost. For one, you have to learn how that framework works, and typically, that is no easy task.
If you already know JavaScript however, then you can get started right away without having to pick up new terms, concepts and/or syntax.
But hold on...
At least...that's the initial thought that many share online. Truth be told, that was my thinking as well not that long ago. I enjoyed writing everything from the ground up, because it gave me full control of the code and it avoided any messy dependency issues. But in the process, I pretty much ended up having to build my own framework. And that came with its own issues, such as maintenance and lack of documentation.
I often times forget just how my framework actually works.
More recently though, as I have become more and more comfortable with Node.js and the React framework, my mind has begun to change. Because there is a considerable amount of work that a framework can handle for you that would take you 2-3 times as much code to implement yourself.
So to answer the question up front, I think you should almost always use a framework that you are comfortable with, such as React, Angular or Vue.js.
The only time where it wouldn't make much sense is when you are working on a much too simple web application that doesn't require an excessive amount of front-end data binding.
And if you want more detail as to why you should use one, then keep reading as I break it down further.
HTML & JavaScript binding
One of the biggest benefits of using a JavaScript framework (and probably why they were created), is in the fact that most have some method to bind JavaScript data to the HTML, without you having to type any extra code to do so.
For example, if you wanted to update a label on a web page to a given global variable, traditionally you would have to write code like the following:
<div id='score'>0</div>
<script>
let score = 20;
document.getElementById('score').innerHTML = score;
</script>
Essentially, you have to provide an ID to the desired element, and then you need some kind of data binding code that searches for the element in the DOM and then updates its UI. And if the variable changes for whatever reason, you will need to be notified in order to manually update the UI once again.
Most webpages rely on dozens to hundreds of page elements typically. And therein lies the problem. Because updating a pages UI is going to involve having to query the DOM over and over again typically with the same repetitive document.getElementById method or className equivalent and being able to track all of the data for changes.
And if not done correctly, that process can be resource heavy, code heavy and really just not very fun to write.
Most frameworks though typically bind data inline, having it look something like the following:
const data = 'Hi there';
return <h1>{data}</h1>
That's definitely much cleaner and overall easier to read than the previous vanilla version above. Note that there is some code running underneath the framework though in order to maintain the UI's state, it's just the framework is responsible for that code, and not the developer.
Depending on the framework that you use, you will either get one-way data binding, in which the UI reacts to the variable state changes, or you will get two way binding, in which UI changes (like in a form) will also update the given state variable internally.
That can also be a factor in determining just which framework you roll out with.
DOM updates
Typically, in JavaScript, if a variable changes its value (score = score + 5), nothing else happens. If you had an element on the page that needed to be updated to this new value, then you would have to manually track changes on that variable and then accordingly locate the DOM element to update its innerHTML property.
Because frameworks like React focus heavily on state management, they pretty much handle that tracking for you and update the UI only when those properties change. And for the most part, they are really good at it, meaning that they can track changes with very little resource use.
If performance matters to you in your projects, then using a framework can greatly benefit your page speed.
In React, that is handled through the useState() hook, which is essentially a function that returns a state variable and a method that will be used to update that variable.
let [firstName, setFirstName] = useState('');
Assuming that firstName was being bound onto the page:
return (
<h2>{firstName}</h2>
);
Then any change to the firstName state variable will automatically update the UI. There is no need to locate the element anymore.
And that's huge, because it reduces the amount of repetitive (and usually slow) code that is required to make those updates in real time.
Depending on the framework that you are using, you might also get the benefit of having 2-way binding (mentioned above), in which data entered into a form element, will automatically update the state variables as well.
Binding data the old fashioned way isn't overly complex, but it does require more code to do so. Frameworks take away that added workload and let you focus more on the business logic.
Community
If you take a look at the React Github repository, pretty much at any point in time, you will see that there is constant activity, in terms of maintenance and bug fixes. This is something that you are not going to get from your very own custom vanilla framework.
Probably the biggest benefit that you are going to get from using a framework instead of plain old vanilla JavaScript is in the continuously growing resources that the open-source community contributes on a daily basis.
React, Angular and Vue.js are all free to use and are open-sourced. That means new features, frequent updates and (usually) robust documentation and support from people all over the world.
But really what community means, is less boilerplate code being written by you. Instead of having to rebuild the wheel each and every time that you need to add functionality, you more than likely can search for a ready to use module.
Using libraries, frameworks and modules doesn't necessarily mean that you are writing less code or making your work easier. It just means that code that is frequently used has already been written and tested for you by somebody else. You still have to do most of the heavy lifting in your work.
But...
But it is still isn't a requirement to use a framework. Anything that you see online you can pretty much build yourself with your own custom code.
And if that's the route that you choose to take, either to have full ownership of your code or to challenge yourself, then that's a good reason to go the old fashion vanilla route.