Frontend frameworks like React, Angular, and Vue are popular technologies many sites use to enhance their site performance or decouple their backend code from their frontend. But utilizing a frontend framework is not a free lunch, and there are significant visible and hidden costs that must be paid in order to leverage them effectively. In this post, we’ll take a look at some of the implications going with a frontend framework carries with it to help you decide if it makes sense for your project.
20-Percent Improvement for 5X the Effort
“20% improvement for 5 times the effort” is a common saying that is helpful in understanding the cost-benefit of frontend frameworks. While which framework you choose, and the implementation you leverage, can impact the multiplier (as low as 2 times, or as high as 8times), there is little debate that using a frontend framework means increasing the effort required over what a traditional Server Side Render (SSR) of a website would involve.
I overheard a case where a company was seeking to build out a Minimal Viable Product(MVP) of their product and the development shop they chose had built it with React. But after eight months, they still weren’t done. They then hired another company to develop their MVP using Ruby on Rails, and after one month, they had completed development.
While Ruby on Rails places a focus on developer productivity, which has allowed many startups to get up and running very quickly, any fullstack web development framework is going to outpace the effort required from a frontend framework.
However, building an MVP and trying to squeeze every last drop out of your site are two very different stages of growth. When you have millions of users to support, that 20-percent improvement can be worth the extra effort, but most sites never come close to this.
A Frontend Framework Can be Difficult To Execute Well
It can be very challenging to replicate an existing site’s behavior and functionality when rebuilding using a frontend framework. Features that you got for free from SSR, such as browser back button behavior, SEO, in-browser find, and even working links and buttons, can present significant hurdles for frontend development to get right and keep working. The linkedin post shared here is just one of many examples. It’s not that getting these things to work right is impossible – just harder, and more costly to develop and QA.
Frontend frameworks place greater reliance on the skill and knowledge of the developers implementing them to deliver a quality result. This is a source of pride for some devs, and a source of great frustration for others. In contrast, backend frameworks like Rails solve the “boring” problems for developers, so they can focus on addressing the unique needs of their product.
Development Costs: Workforce
One of the biggest benefits of utilizing a frontend framework is that it allows you to decouple backend development from frontend development, which means more teams can work on the same product without impacting each other. However, this perk for larger organizations is often a tax for smaller ones. The extra workforce required to properly deliver on both backend functionality and frontend development may be restricted or simply unavailable, which reduces the quality of development for both.
Having one developer or team that works on both also carries risks. For a few applications, the backend requirements are so simple that a developer is able to focus most of their efforts on the frontend development. Although, many products require a lot of logic to take place in the backend, which forces corners to be cut, work to be rushed, and quality to be reduced.
Development Costs: Updates
Frontend frameworks allow for certain kinds of agility to take place, usually at the cost of other functionality. To implement a design change might require an hour or two of work to apply to a fullstack server framework, but could take days or weeks to apply to a frontend framework. Additionally, as browsers update and the ecosystem around JavaScript (JS) and its best practices evolve, the “right way” to do things is an ever-moving target that frontend developers must keep up-to-date. It also may require significant reworkings of the underlying implementation.
Complex Development Ecosystem
Developing with a frontend framework requires significant tooling and library usage to execute effectively. This includes overcoming language deficiencies within JavaScript through packages, debugging code issues, polyfilling differences in the browser’s understanding of JS, and compressing code down. The graph below (from modulecounts.com) displays the explosive trajectory package counts within the JS ecosystem have taken over the years. No other code ecosystem has anywhere close to the number of packages in JS.
With so many options available, developers must select from dozens or hundreds of packages to import into their project for a specific purpose, often with unknown code quality, functionality supported development, or dependencies. One famous example of this is when the author of the leftpad library (used to add characters to the beginning of a string of text) removed his package from NPM and subsequently broke the development of thousands of websites across the globe.
All of this leads to complexity as frontend developers must scramble to keep up-to-date over the course of just a few months. Eventually, there will be more stability, but the rate of change shows no signs of slowing anytime soon.
Slower Loading
Frontend frameworks must download the code to run, which creates an inescapable issue with loading time. Utilizing Server Side Rendering does allow you to give users some content while they wait (instead of a blank screen with a loading spinner), though it is usually placeholder in nature, requiring them to still wait before the site becomes usable/useful. This slower loading is an unavoidable overhead and, if not managed properly, could cause users to bounce from the site before it has fully loaded.
Projects Can Have Difficulty Updating
Many projects delay upgrades to infrastructure or server frameworks due to budgeting, available workforce, or required effort. This impacts their security, maintainability, performance, and development velocity. Some projects delay upgrades for years, forcing developers to work with older versions of software that are less understood or harder to keep going as dependencies become unavailable. This is often the case with projects that don’t rely on frontend frameworks. For ones that do, these updates can be even more difficult to plan around, implement, or ignore.
Regarding React
While Angular and Vue are complete frameworks for developing frontends and provide their own documentation for doing so, React is unique in that it is more of a “library” than a framework. At a technical level, you can use just React and nothing else to achieve some results, but to fully build out a React-based website, you must decide on, and build up, your own collection of libraries and tooling. For each of these supporting libraries, there may be dozens of options to choose from, and it may be unclear which is “best” or “current”. Additionally, knowledge of how these all tie together is either contextual to the codebase, or scattered across the documentation of various libraries.
Vue and Angular largely enable an approach known as Just In Time (JIT) Learning, where you are able to go from knowing nothing to implementing some solution in a relatively short period of time, such as in the span of a few days. While this is also true for utilizing the react library itself, understanding React development, its coding concepts and supporting libraries, requires significant study and research that takes several months to grasp.
Closing Thoughts on Costs of Frontend Framework
Utilizing a frontend framework within your website or application can represent an improvement for users or development velocity, but 95% of projects would simply be better served by focusing on their backend development. With a sprinkling of JS on server-rendered HTML, much of the same functionality and experience that frontend frameworks enable can be had for a fraction of the work. With proper caching, pages can be snappy to load, and with scalable architecture, a large number of users can be served concurrently.
If you’re trying to decouple your frontend development from your backend, and have the financial and people resources to do so, going all in may be the appropriate next step for your project. But for most, only a subset of the site (like a live trading platform or charting library) would benefit from a frontend framework, while the rest remain rendered from the server. When you’re building something with lots of bells and whistles and interactivity, trying to build it without a frontend framework may be the more complicated or costly approach.
The goal here has not been to dissuade you from choosing a frontend framework entirely, only to be aware of the potential (sometimes significant) costs involved to help color your cost/benefit analysis and understand when to best reach for frontend frameworks and when to avoid them.
Learn More about Frontend Frameworks with Help from CQL
If you’re interested in building out your MVP, or would like to know if implementing a frontend framework is right for you, then contact CQL’s team of experts. We’re happy to help provide accurate, well-researched solutions for your business whether you’re just getting started or looking to improve your existing project. Our Ruby on Rails experts can help you quickly build out a scalable, maintainable platform; and our frontend experts can help you implement the latest JS best practices in the industry. Coupled with our team of talented designers, we can deliver usable solutions that work great and look great too!
