5 Reasons to always use a frontend framework
Some frontend frameworks fit exactly your use-case, others don’t. There are however so many frameworks out there. There should always be a frontend framework that fits your use-case.
Too many developers — even experienced ones — tend to avoid frameworks. One of the common reasons is that they believe it restricts them in the long run and that they will end up saving time later on if they make the investment of doing everything custom. However, this is most of the time a wrong assumption and it can seriously harm any business that aims to reach its goals using software developers.
When you work at a company, then its very likely that your main goal is not technical (eg: The goal is not the code). In this case its mostly a bad choice if you decide not to leverage a framework to save both time and complexity.
Here are 5 reasons for using a frontend framework.
Framework vs Library
Before we continue I want to explain what a framework is and how this is different from a library. My motivation for this is that the choice of framework and whether or not you are using one has much more impact on the future stages of your project then a library.
The main difference between a framework and a library is what is referred to as “Inversion Control”. A framework defines the flow of your app often meaning how the app is structured and how code should be implemented.
Libraries on the other hand do the opposite. You control the flow, meaning you can structure the flow of the app to whatever you like.
On the frontend however, the difference between a framework and library are in many situations unclear. How does Vue for example relate to Nuxt? Vue presents itself as a “progressive framework for building user interfaces”. It simply depends on how you look at it. Vue does enforce a certain structure on code level, it does provide a flow in your code. For example how props are moving downstream and events move upstream.
Nuxt and Vue — though highly depending on each-other — simply focus on different areas. Vue provides UI layer benefits and Nuxt provides an opinionated way of structuring apps with additional tooling. In practice, different frameworks can simply work together to provide a full suite of tools. Just look at how Apollo, Express, Bootstrap etc fit really well together.
Reason 1 — Frameworks follow best practices
The number one reason why frameworks exist is because they form an abstraction over repetitive and complex tasks that cover most use-cases. Frameworks like Nuxt (based on Vue) and Next (based on React) abstract away the often complex and critical functionalities that are needed to make it work for most scenarios. Webpack is such a tool. It is hard to master, but when done right, it is a very powerful tool. Nuxt and Next developers realize this and are using Webpack under the hood. Both teams are constantly collaborating with the Webpack team to make sure that Webpack is implemented exactly how it should be done. They are following best practices so that you and your team don’t have to do it!
Ask yourself: Am I saving time and complexity by customly creating all of this code myself? If that answer is “No” or even “Yes a little bit,” then don’t… Just don’t do it. It will hurt you in the long run, because you will need to maintain everything and you might even need to figure out things that others already nail.
SSR or ServerSide Rendering is another excellent example. Making SSR work in combination with modern requirements like async data fetching can be challenging and requires a certain way of setting up your code. It is for this reason that frameworks like Nuxt and Next both work with a similar mechanism of having a folder with pages and special methods that allow for pre-fetching of the data.
There are lots of other features that frameworks provide under the hood like: pre-rendering into a static app, building, data fetching, caching, lazy loading, routing, SSR, stylesheets, CI/CD, state management, etc.
Reason 2 — There is less need to share code
Sharing code can be tough. I mean… REALLY tough. Creating shareable code requires creating a clear facade and a way of sharing. A facade in short is a way to expose functions, methods or entire libraries to other devs in a way that works for them without exposing all the complex things that happen under the hood. In order for you to understand exactly how other developers will use your code, you will need to put it out there. Its only when feedback is acquired that you will understand how the facade should look like. It rarely happens (read never) that your code and its facade is built perfectly from the start and therefore it requires iterations to improve it.
In a typical business setup, when you work in a team with a business goal, you have a choice. Either you focus on reaching that goal and tailor that code to your needs or you spend more time on that same piece of code just so that other teams with other goals can use it. If that second option applies to you, then you’re sneakily not working towards your team’s goals…
Just to be clear, i’m not against creating shareable code. I just think that when someone else already created something that is shareable, then why should you? Will your version be better or simply more custom? If it becomes more custom, is it then still that shareable?
Lets say your code is shareable. That doesn’t cover the hardest part. The hardest part is actually sharing it. Here ‘s a small summary of what you will need to cover:
Packaging
Likely this will be a Npm repository. This means building one or more separate Npm packages. Which means installing and understanding tools to develop packages locally. Tools like Lerna, Webpack and Yalc.
A framework already comes with an entire ecosystem of libraries and tools that can be plugged in. This will prevent you from having to re-invent the wheel by creating your own libraries and tooling.
Versioning
Shareable code requires proper versioning with standards like Semantic Versioning (semver) in order to be shared among other teams and other packages. The last thing you want is to wait with a deployment, simply because one team is unable to fix a breaking change on your API in exactly that same sprint as yours.
Communication
Every new release needs to be communicated clearly. If not done, teams will fall behind without them even knowing it. This might introduce different behaviors or even security risks.
You ‘will’ spend a huge amount of time in coordinating the release cycle of your code, just like the actual project that you work on!
Knowledge
Sharing packages correctly requires knowledge of how Npm modules work and where they can be used. Are you using Webpack to pre-bundle all of your code? Do you expose the source as well for people that have their own Webpack configuration? Many questions to answer here.
Reason 3 — Developers are most likely not usability experts
Usability is a very wide area. It doesn’t only cover the design aspect of the actual UI that you’re building. It also covers how your application works from front to back.
I’ve briefly mentioned lazy loading. It allows a developer to load certain parts of the app until the browser has enough resources available to load them. For example, the components that are visible without scrolling (above the fold) could be loaded first and the components below the fold could be lazy loaded. This allows the user to use the app without it actually being fully loaded. This is important for the TTFI (Time To First Interaction) and it gives a huge perceived performance boost!
Both Nuxt and Next have built-in features to lazy load components like for example routes to different pages.
Other examples are styling frameworks like Reactstrap, Bootstrap Vue, Vuetify and Material UI. The way these frameworks present themselves is a bit degrading to their actual purpose. They present themselves as CSS component libraries that incorporate a certain design system. For example: Vuetify is the Vue implementation of Google’s Material Design and Bootstrap Vue uses the designs of Bootstrap.
What few people know however, is that these frameworks do some highly important extra things under the hood to make apps usable for people with a handicap! They for example add aria attributes and structure HTML in a certain way. These things are normally very time consuming and are often either forgotten or underestimated. Also most companies stop improving usability once the SEO goals are reached.
Reason 4 — Most developers hate writing documentation
Ever had to hand over your work to someone else? Did you try to explain your code? Was the person understanding it? Ever tried to document it? Writing good documentation is hard and very time consuming. Like the software itself it requires iterations to improve it.
Documentation might also feel as something that should not be needed if the code is written clearly. However, code is about statements, factual, as in: This is how it works, but the intention of the code should also be documented, because most of them are deliberate business rules! Most regressions occur, because developers think they fix something which was a deliberate choice to put in. You could cater for those business motivations in code comments or tests, but its often just better to write a guide and API specs to avoid bloating the code base.
If you feel that documentation is not needed and often not worth your time, than please have a look at the Vue Guide. Do you really think that this is not helping you understand how to use Vue? Do you still believe its better to just dive into the code and unit tests to understand its purpose?
The writing itself is also a whole other ball game. Guides require a good article structure with a proper introduction, context and examples of usage. Different articles should be structured into a proper navigation structure and API docs should be clear and concise. Luckily for the later, this documentation can be generated from code and in-code comments using for example JSDoc, but for the first, you will have to do it yourself.
The Vue community has a lot of contributors that are solely working on its guides!
Reason 5 — There’s probably someone better at this
This for me took some time to both fully accept and to even start appreciating it. I’ve been trying to contribute code since I was around 14 years old. My main problem was that people constantly beat me with better options. I was re-inventing what others already did way better. This was because I simply lacked to understand the problem that I was trying to solve.
I’ve learned this the hard way. Some projects simply grindend to a halt, because I thought me and my team were better of writing our own implementation instead of using a framework.
Eventually I’ve learned that there are things I understand very well, but that there are also many things I don’t understand that well. I am passionately working on web software for ~20 years now and I see people with way less experience feeling that these are things that they will be able to pick up on short notice whenever is needed.
Let me be clear. This is not possible on short notice, because you can’t learn things that you are not yet aware of. Every developer will start of being unconsciously incompetent. This however, is a different topic which I do want to cover some day, but for now I will refer to this article instead: https://scottjeffrey.com/four-stages-of-learning/
Another fact is that most popular frameworks have a huge amount of contributors and people that report and fix problems. Just take a look at contributors section of Nuxt to get an impression of the time and effort it takes for tools to fully mature. Here’s some stats of uts repository on Github:
- The core team consists of 9 contributors dedicated only to Nuxt.
- There are 222 other contributors so far.
- There are currently 159 open issues.
- There are > 1900 forks of the repository, meaning > 1900 potential fixes, additions and even major updates.
- Nuxt was released in 2016. 3 years later its still in active continuous development. Every bit of code that you write will also require continuous improvements and maintenance over time!
Conclusion
Though there are reasons not to go for a framework, it is wise to be conscious about the fact that you are sneakily building your own if you don’t. Remember that the most valuable resources we developers have are time and our brain. We use time to gain knowledge and to discuss and build the things we need to build. For our clients.
The last thing you want is to spend that precious brain of yours on figuring out things that others already did for you, for free! Its much better to use it to solve the actual problems that your company faces. It is in this area that you as a developer can help your company!
Sure enough, if you like building your own tools then don’t feel discouraged. I’m simply stating that if your goal is something else then building an awesome new tool, you should be using a framework. Evan You, the inventor of Vue started building Vue, while he was working at Google. He liked AngularJS (old Angular), but felt it could be done simpler. He then started his own project based on what he thought were the best parts of AngularJS at that time.
Evan You has and still spends a huge amount of his own time on the Vue ecosystem, because he felt it had potential value for others. He is now a full-time open source developer that acquires his income from sponsors. In other words, he made the decision to stop working at Google and MDG to continue the development of Vue.
If you are not willing or not allowed to spend time on other goals, then using an existing framework is your only reasonable option.
My name is Chris Visser. I work for Passionate People — A collective of highly motivated and knowledgeable Javascript developers based in Amsterdam — The Netherlands.
