Should you really be using a JavaScript Framework?
JavaScript frameworks! Love them or hate them, there’s no denying their influence on the web development field, everywhere you turn there’s a new JavaScript framework coming out. When you’re looking for jobs the requirement for experience with React, Vue, Angular, Ember, or even Svelte is almost inescapable. Then, just when you think you’ve seen it all, meta-frameworks start showing up too, Next.js for React, Nuxt.js for Vue, Svelte-Kit or Sapper for Svelte, all with the promise of fancy things like server-side rendering and your back-end API integrated with your front-end code.
That being said, you can’t argue that these frameworks aren’t cool. It’s nice to be able to write JavaScript inline with your HTML, because it seems so intuitive to be able to declare a functional behavior of say a form right where that form is located in your code. Then when you want to be able to use that form another time in your code, just separate it into its own component, and plop that in wherever you want. Or if you only want to render that form if the user has completed the previous steps, use the conditional rendering available.
When talking about JavaScript frameworks there tend to be the optimists and the pessimists. The optimists look at React and see it for its large feature set, intuitive syntax and component-based paradigm. The pessimists however, might look at React and only see the bloat, the slow virtual DOM and SPA structure making search engine optimization and deployment that much more complicated. While both schools of thought have convincing points, I think it’s important to take a step back and ask an important question.
Why do frameworks exist in the first place?
Frameworks, API’s and libraries are integral to development and are tasked with an important job: make development easier. Us developers do a lot of things, we design, code, debug, test, deploy and maintain all in the noble pursuit of creating a solution to a problem. So anything that makes that whole process easier for us is welcomed with mostly open arms. That’s what JavaScript frameworks do, they give us access to a wide range of tools that make the process of developing a web application or page easier.
Take jQuery for example, a legend in JavaScript history used on over 70 million websites, and it’s just a JavaScript library with some useful functions. This small tool made development just a bit easier and didn’t use significant resources in the process. There’s nothing inherently wrong with the idea of JavaScript frameworks, they try to do the same things as jQuery and succeed in many cases. However, it is important to know the problems that come with them, as with most things that make your life easier, sacrifices have to be made somewhere.
Considerations with Frameworks
*I want to stress that I will mostly be using React as an example here as that’s what I’m mostly familiar with. If I’m wrong/misleading or unfair about something, or you feel an edit/amendment should be made, just let me know.
The Virtual DOM
First off, with the exception of compilers like Svelte, most of these frameworks use a virtual DOM. This is how it sounds, it’s an abstraction of the real DOM copied into client side memory, where the framework can check for updates to the component tree, and then if the component’s state or props change, the virtual DOM tells the real DOM to repaint that piece of UI. That way the browser doesn’t re-render everything whenever something happens and lead to a janky experience.
The problem with this is that it’s not reactive. Whenever a piece of state or props change, the virtual DOM has to go through every component in the component tree and check whether or not its state or props change. A much smarter approach would be to keep track of what components that have state and props that are connected, that way when something changes, we just go change the stuff that is affected. This is called reactivity, which React, unfortunately named as it is, does not have.
This isn’t very noticeable in smaller web pages like a personal portfolio for example, but can become clunky in a big application. Just take a look at some websites that use a virtual DOM framework and notice the latency when clicking a button. Although frameworks have released nifty ways to increase the efficiency of the virtual DOM, with things like React’s memoized components, they’re simply not as fast as reactivity. Props to Svelte for actually using reactivity, and destroying other frameworks in latency tests.
Bloat
If I run create-react-app right now, which is the most common way to set up a react development environment, it downloads 150 megabytes of JavaScript to my device in the form of node_modules. That is insane. Those aren’t just development dependencies either. My personal portfolio which as of right is built in React, sends 150kb of JavaScript for the browser to render. That’s because in order for React to work, it has to send over instructions on how to build the virtual DOM and all of your components. This can drastically decrease performance and cause a real drag on the client-side.
Heavy frameworks improve performance by caching important data on the client’s browser, so that it’s only slow to load the first time, or whenever the user clears their browser’s cache. The only problem with that is that caching only solves the slow JavaScript download. The server doesn’t have to send the big file anymore, it’s already on your device. However, your browser still has to execute that JavaScript in order to build the app, so the solution only goes halfway. This brings us to the next problem.
Client-Side Rendering
Your browser doesn’t just send over a big pile of JavaScript, it also sends a really small HTML file, as is necessary for a browser to understand what to even do with the JavaScript it now has. The HTML file is there so that when the script runs, it can target the body of the HTML as the root of the application. That’s why if you go to a React based website (my portfolio for example), you’ll see a div called root, another one called App, and finally the components will start showing up.
This defies convention because usually this assembly into an HTML file doesn’t need to happen at all in the case of static sites, or is very minimal. That way, all the browser has to worry about is rendering the HTML file, the styles, and maybe having JavaScript to work with afterwards for functionality and DOM manipulation. But frameworks build out of the JavaScript file and therefore increase the workload on the client.
The other problem with this is search engine optimization. Search engines crawl websites in order to understand the content of them. They do this by going to a URL, and crawling the HTML file. If your JavaScript doesn’t finish executing before the crawler is done reading your HTML file, then it’s not gonna see any content, and with that any reason to list your site as a result of a search query.
This problem is addressed by server-side building of JavaScript files, a neat trick made possible by those meta-frameworks I mentioned earlier. Basically, instead of sending the piles of JavaScript to the client to render, the server executes the JavaScript itself, creating the HTML file, and sends that. This however has its downsides as well because whenever your site needs to re-render, it has to go to the server to pick up another HTML file. This is fine if you have a fairly static site, but if you want to build an application and performance matters, this is probably a deal breaker.
To be fair however, if you’re building web applications, you probably want client-side rendering anyway. It makes little sense to have any dynamic rendering be done by the server as it’s all reliant on a connection between the two computers and the speed of that connection determines the responsiveness. If you’re dealing with a big application that’s heavily dynamic, client side rendering is great for performance on both your server and the client’s browser.
Single Page Applications
Single Page Applications, commonly known as SPAs, are the outcome of building a website with React, Angular, Vue, etc. The basic idea is that instead of going to the server and asking it for the HTML file that corresponds to the endpoint you’re searching for, when you go to a link, the framework renders the piece of UI that is consistent with that link. It’s fairly complicated so here’s a link to a good article explaining them further.
SPAs are great because they allow for a persistent state. Say you have a variable that gets dynamically assigned based on some user input, and you want to use that on another page. Well, conventionally this isn’t possible because as soon as you go to another URL, the page refreshes and you lose that variable’s value. However, since an SPA doesn’t refresh when the URL changes, you can keep that variable’s value for use whenever you want, and make it seem like the page is changing based on the URL.
Unfortunately, there do arise some problems with this. SEO becomes a problem again because of the way search engines crawl websites. In order to map out a website’s pages, a crawler expects to have the page refresh with new content when it travels to new URLs. This problem is addressed in many ways but still should remain a consideration.
Another issue is security, as moving so much functionality from the server to the client side gives end-users access to the JavaScript itself. A clever and committed hacker could comb through the source code of your application and find vulnerabilities if you’re not careful.
So, what?
Well, these are important considerations to make because although frameworks come with a lot of really cool functionality, there are also tradeoffs to be aware of. Frameworks are also always developing and some, like Svelte for example, have solved a lot of these issues already and work in new and intuitive ways.
So when do I use a Framework?
Say you’re looking for a book. You walk into a book store and they say they have it, but it’s only available for sale in a package with 4 other books, which is priced at $50. You can also buy it individually online for $15 dollars. Which one makes sense? Well see it depends. If you really only need that book and you never plan on reading any of the others in the package, then the obvious choice is the online option, you’ll pay a little more per book than the package option, but you’re saving money in the long run. However, if you take interest in the other books and can see yourself reading them, it might make sense to buy those other books as well, at a cheaper price individually. I’m sure you see where I’m going with this.
If you’re going to use all or even most of the abilities of say Angular, then sure, why not use it? There’s no point in reinventing the wheel by trying to reproduce the functionality built by a bunch of really smart people at Google when it’s all bundled up in their framework and free to use. But if you just need form validation done, then maybe just make it yourself, it’ll take a little longer but you see the benefit.
If you’re building a big application for example, then you’re gonna need a lot of that stuff done. Form validation, animations, persistent state, client-side rendering, and dynamic rendering are all going to be very important, in which case a framework is probably your best option.
If you’re building a strictly informational site however, that doesn’t use many of those features and especially isn’t very dynamic, then perhaps exercise your skills with HTML, CSS, and Vanilla JavaScript. I’ve found it really nice to use the lean powers of that trio after working in a big React code base myself.
Is there a happy medium?
Well, kinda. I’ve mentioned Svelte a few times in this post, and it’s a pretty interesting and refreshing take on things. First off, it’s reactive. Instead of using a clunky virtual DOM, it only re-renders the things that you need to be re-rendered based on state/props change, and doesn’t bother checking everything else because it doesn’t have to.
It’s also less framework more compiler. It harnesses the power of vanilla JavaScript by compiling your .svelte files into clean, lightweight JavaScript that is really only representative of your components and code, there’s no virtual DOM required. You don’t have to worry about clunk, you just build your files before having your server send them out to clients. The only dependencies that you need are developer dependencies, which means you’re not shipping any extra code to the client either.
This is as close as it gets to a happy medium, at least in my opinion, and I’d recommend Svelte to those looking for a framework that’s intuitive, fast, and feature-full. That being said, because Svelte is new and has less of a user base than the more popular frameworks like React, Angular and Vue, it can be hard to find answers to your questions especially if you’re a beginner. In that case I’d recommend working with one of the bigger frameworks first, and then once you’ve built some projects with that, make something in Svelte. They also have a discord where you can ask questions about bugs or getting started, and they’re pretty active from my experience.
Takeaway
The important thing to remember is that there are going to be tradeoffs to whatever tool you’re using to make your life easier. Frameworks changed web development, in a lot of ways for the better, and some might say in a lot of ways for the worse. Frameworks have led to insane innovation on the web and there’s no sign of that slowing down. No reason not to be part of that as long as you’re smart about it.
Happy Coding Everyone!
