In this article, we'll discuss what is a front-end framework and when it makes sense to use it. We'll quickly go over the main benefits that they give for web developers.
Or maybe, the state of the web platform is such that you don’t really need any framework at all?
What is a front-end framework?
It’s a package of code written by someone else that helps you deal with things like data binding and fetching, routing, general code structure, all these things that the modern application uses.
Front-end frameworks are really powerful tools for fast prototyping and web development in general. They make your code more organized and manageable, take care of all of the things that a good application needs on the client-side.
When do you need a front-end framework?
To determine if you need a framework or not, ask yourself a question: ”Can this be built without a framework first?”. If the task is quite simple and you don’t need data fetching and binding, or complex routing, then using a framework might be not necessary.
Some developers even go as far as open up a blank HTML file and build everything from scratch. For a personal site or a portfolio that may be a great idea, since you don’t have any particular requirements and the final result will be very fast.
But there are very real benefits in using a front-end framework.
What are the benefits of using a front-end framework?
One of the biggest benefits that you get out of a framework is the link between your data and the presentation. Without it, when you update the variable in your code, it’s not automatically updating in the HTML. If the variable updates you need to manually re-update the DOM and frameworks do this procedure very easy using the two-way binding.
Some people who primarily learned and work with frameworks sometimes are being confused about something not updating on the screen when they update their data.
You can build things that will do that updating procedure for you without a framework but then you suddenly realize that you’ve built up your own little framework.
Another thing about using a front-end framework is the seamless routing and page transitions. Generally, when you click on the page, the browser has to go out and fetch a whole new page, do a full page refresh and show it to the user. But sometimes there were very few changes on the page and the browser has to do a lot of unnecessary work to grab that new thing when half of your page might not be updating anyway.
Front-end frameworks can take care of your routing and page loading so that now you don’t need to do a full page refresh every single time. This is really cool and allows for things like animated transitions between pages. It makes your website behave more like an app.
Yet another reason you might need a front-end framework is that you need to have an opinionated way to handle complexity. Some people don’t like this, but if you work in a large team, having a strictly defined structure of your app is a good choice, because otherwise, you’ll just make a spaghetti mess out of all of the code that you write.
You’re just doing things faster when you’re able to reach for the framework. You reach for all these battle-tested libraries, they’ve been checked for security, they’re in use on a thousand of different websites, they’ve been checked for performance, edge case bugs, so you don’t have to find those bugs over and over again because they’re already been found and fixed.
When not to use a front-end framework
- If you have a very simple task - As I mentioned before, you don’t really need to use a framework if you have a very simple website that doesn’t require a lot of functionality. Things like your personal blog, portfolio or a simple landing page. When a website has a couple of pages, a modal, maybe some simple slideshow and a form, it’s entirely possible to code everything from scratch. There’s no need to load the whole framework if you’re only going to be using 5% of it in production.
- Using a standalone CMS - You don’t need to use a front-end framework if you’re using a CMS like Drupal or Wordpress, because they already have their own way of doing front-end stuff.
- Updating a huge old project - If you have a project that uses some kind of legacy technologies, unless you have a very decent budget you probably shouldn’t try to do a major rewrite with a new framework. It’s not going to be so easy to do this unless it’s what your employer actually wants to do.
There are so many frameworks out there, which one to choose?
It certainly a personal preference thing. There are plenty of them out there and they all cover different scopes.
For example, React is very lean and straightforward, doesn’t have routing and is focused more on rendering, and you bring your own libraries if you need them. Something like Angular of Backbone is a little more opinionated.
Of course, there will totally be people who don’t like too opinionated frameworks, but sometimes this is good, especially when collaborating with other people. It takes away the amount of thinking you have to do in structuring things.
All of these frameworks are not the same. You really can’t compare them. They’re all different in what they can do.
Frameworks provide a reliable well-thought-out structure for your application. As your application grows in size and complexity, the framework is going to provide you lots of things that you just don’t have unless you’re writing all those things by yourself.
This really helps to solidify your codebase and makes stuff easier for you in the long run.