Front-end frameworks: Solutions or bloated problems?
Front-end frameworks have gone through significant transformations and they still remain relevant in a developer’s life. But are the new framework trends more of a hassle than a convenience?
Modern front-end frameworks require you to download a development environment, complete with dependencies and compile your code before even trying to view it on your browser. Is this a good thing? Is the problem that we are building more complex sites, or is it that the frameworks are complex in their own right, introducing an unnecessary level of complexity?
Web development today has evolved a lot since the ’90s; we are able to create entire experiences that are very near what any native application can do, and the development process has also changed. Gone are the days when being a front-end web developer was a matter of opening Notepad, typing a few lines of code, checking it on the browser, and uploading it to an FTP folder.
The front-end web development of the past
Modern browsers can manipulate the DOM as a standard, so the need for such a library has diminished greatly in recent years. jQuery isn’t needed anymore, but we can still find a number of extremely useful plugins that depend on it. In other words, web frameworks may not be necessary, but they are still useful enough to be popular and widely used. This is a trait common to most of the popular web frameworks out there, from React, Angular, Vue, and Ember to style and formatting models like Bootstrap.
Why people use frameworks
So what are some of the benefits and unique properties of using a web development framework?
Time is money. When you are developing a project and the client doesn’t care which framework you use—indeed, probably isn’t even aware of what you use—they only care about getting results, and the faster the better. Established frameworks let you create an instant sense of progress from the beginning, which the client craves from day 1. Additionally, the faster you develop, the more money you make, since the time freed up by the framework can be redirected to taking on more projects.
It’s all about the community. When choosing a framework, this is a very important point—who is going to help you when you get stuck on an issue? You and I both know that it’s going to happen at some point. You’ll reach a spot where you need to do something that the framework wasn’t intended to do, or that the framework was never designed to give you access to, so having a community supporting you is essential. Development—especially freelance—can be hard, as you are immersed in a virtual world, and if you’re the sole front-end web developer in a team, it means you’re the only one with the experience and expertise to find a solution. But if the front-end framework you use has solid support, there is going to be someone on the other side of the world who has faced the same problem and might be able to help you.
Standards are beautiful. Have you ever noticed that, when you look into an old piece of your own code, you can navigate through it pretty easily? Or at least, more easily than a piece of code written by someone else? You think in a certain way, and you have your own way of naming things and organizing the code. That’s a standard. We all follow them, even if they’re only for ourselves. We tend to eat similar things for breakfast, wake up at a certain hour, and place our keys in the same place every day. And indeed, if we changed up our routines every day, life would be a lot harder just from the overhead of figuring out how to do stuff. Ever lost your keys because you put them in a different place than normal? Standards make life easier. When working as part of a team or a community of developers, they become absolutely indispensable.
Frameworks provide a standard from the moment you install them, guiding you to think and to code in a specific way. You don’t need to spend time creating a standard with your team; you can just follow how things are done in the framework. This makes it easier to work together. It’s easier to look for a function when you know that the function must be in a certain file because it is built for adding a route in an SPA, and in your framework, all routes are placed in a file with that name. People with different skill levels can work together if you have this level of standardization because while the advanced coders know why things are done that way, even junior developers can follow the standard itself.
When frameworks fail
A few years ago, saying something like “I don’t use frameworks—I don’t see any real benefit from them” would bring people with torches and pitchforks to your door. But today, more and more people are asking themselves, “Why should I use a framework at all? Do I really need them? Is it that hard to code without them?”
“One size fits all” is a lie. Could you imagine writing a single piece of software that can do everything you’ve accomplished in your career? That’s one of the main problems with web development frameworks. Your project has very specific needs, which we tend to solve by adding libraries, plugins, or add-ons to extend the framework’s scope. No framework offers 100% of what you need, and no framework is 100% composed of things that you’re going to find useful.
Having too much code that you don’t use can result in load time lag for your site, which becomes more important with each additional user. Another issue is that the “one size fits all” mindset results in inefficient code. Take, for example,
$(‘sku-product').html('SKU 909090');, which is jQuery code that, in the end, we all know is going to be translated into something like
document.getElementById('sku-product').innerHTML = 'SKU 909090';.
That kind of difference on a single line might seem unimportant, but changing the content of a specific element of the page is precisely the virtue of React. Now, React goes through the process of creating a representation of the DOM and analyzing the differences in what you try to render. Wouldn’t it be easier to just target the content that you want to change from the beginning?
That tangle of weeds you’re walking through is growing thorns. Have you ever been in the situation where you’re using your framework and trying to add a library to it, just to realize that the library version you need doesn’t work well with the framework version that you’re using? Sometimes it takes more effort to make two pieces of code work together than it does to just write the code yourself. And since the frameworks and libraries that you use are often built on other frameworks and libraries that can have hidden incompatibilities that you can’t even anticipate, the problem can grow exponentially more complex, reaching a point where they’re impossible to manage if you want the project to keep growing.
Keeping up with the Joneses is a thing. Ever worked on a project in AngularJS only to find out that you need something that didn’t appear until Angular 4 was released? Did you even know that Angular 5 has been released? This is another huge issue; even if you’re sticking to a single front-end framework, when a new major release happens, things can change so much that the code you worked so hard to make won’t even run on the new version. This could result in anything from annoying little changes that need to be made on a lot of files to a complete rewrite of your code.
Keeping up with the latest builds of a framework is challenging, but on the same note, other frameworks suffer when updates stop completely and they can’t keep up with the rest of technology. In 2010, both AngularJS and Backbone were released for the first time. Today, Angular is on its fifth major version, and Backbone is completely out of the spotlight. Seven years seems like a long time. If you build websites, they’ve probably changed completely in aesthetic and function. If you’re building an app, betting on the wrong framework might put the company in a tough—and expensive—situation later, when things need to be rewritten.
When all you’ve got is a hammer, everything looks like a nail. If you’ve used web development frameworks frequently, this has probably happened to you, where a single codebase defines the shape of the code you use in the future, even if it’s only peripherally related. Let’s say you’re going to build a platform like YouTube and you want to use Framework X. There might be a point where, even if it sounds ridiculous in this day and age, you decide to use Flash for the videos because that’s what comes built-in with the framework.
Frameworks have opinions, and they are strong; React, for example, forces you to use JSX in a specific way. You can see code being used in that way everywhere. Is there an alternative? Yes. But who uses it? This isn’t always a bad thing, but if you need to perform complex animations, you might only need a framework for animating and not the entirety of React. I’ve seen people do crazy things like add jQuery to a page just to append a node to an element, something that could be accomplished in vanilla JS with
This post was originally published on Toptal LLC.