From the course: Learning App Building with Vanilla JavaScript

Identify when to replace frameworks and libraries - JavaScript Tutorial

From the course: Learning App Building with Vanilla JavaScript

Start my 1-month free trial

Identify when to replace frameworks and libraries

- [Instructor] There are a few factors to consider before deciding whether to replace libraries or frameworks in your existing code with Vanilla JavaScript. First, it's useful to examine how extensively your app relies on the library or framework. For instance, if only a couple lines of your code make use of a library's convenience function, it may be relatively straightforward to rewrite the code and you may experience a significant decrease in the download size of your app. On the other hand, if your app makes liberal use of a library throughout, you'll have to look at other factors before making a decision. It's also important to understand the complexity of your use case for the library or framework. For a large site that's built from the ground up on a framework, or relies heavily on a library, rebuilding in Vanilla JavaScript could be a significant task. In this case, it's important to project the benefits you expect from the project, for instance, improved load times, and compare them with the developer hours that will be required to understand if the required investment is worth it. You also need to look at the larger context of your app. If your site uses, say, five frameworks and libraries, and you're removing just one small one, the performance improvement may be insignificant. At the same time, you may find that replacing a lightly used library with JavaScript may be a useful first step, or pilot, to learn about the costs in time and workflow disruption, if you're considering taking out more heavily used libraries or frameworks down the line. Finally, before making a decision, it can be useful to survey any alternatives to a rewrite. For instance, some libraries offer modular versions that allow you to build and deploy a custom version that uses only the features you need. You may find that an alternative like this provides enough savings, at least in the short term, to put off rewriting. The app in this course uses the jQuery library, which has been around for a number of years. At the time it was first released, it simplified some coding tasks, like selecting elements and performing Ajax requests, that were much more complicated in Vanilla JavaScript. However, today, the JavaScript language supports simplified syntax for these and other tasks. For this reason, it makes sense to remove the library from our code base, which should let us realize an improvement in load times and memory usage. Our app also makes limited use of the React framework. Because the app uses only a couple small React components, it's pretty straightforward to replace them with code written in Vanilla JavaScript, which allows us to eliminate the overhead of the React framework files, as well. The code for our app includes a number of JavaScript files. Now, I've included babel.js only because I'm running React and using JSX syntax. When this code is deployed, that would be pre-compiled and babel.js would no longer be a dependency. So, that's something we're using for development, but wouldn't be necessary for production. But the next three JavaScript files are all part of the app in production. The react and react-dom files are for the React framework and the jquery file is for jQuery support. So, users have to download these and they require browser resources. Our goal is to remove those files from our app.

Contents