Take websites. The virtual cost of a webpage is two-fold: the file size that needs to be downloaded and the code/markup that needs to be parsed. Easy to optimize, however, UX and Google demand that regardless of other variables, it all comes down to one other metric to rule them all “Time to Interactive” (TTI).
And, unfortunately, that doesn’t always help to keep your code as lean as possible.
In the past, websites were mostly HTML with a little bit of CSS; and they were bound by the internet speed and capabilities of computers at the time. One couldn’t make a large website, since most internet providers didn’t provide a speed above 64KB/s.
This trend gained further momentum when AngularJS and Ember came along. They made it possible to create Single Page Applications (SPAs) without any page reloads and brought a lot of tools to compartmentalize development on these so-called apps.
In recent years the frameworks ReactJS, Vue and Angular have come out to help developers make even more awesome applications that can “run everywhere!” Moreover, internet and device speed have increased in most areas, and so has the code base of these frameworks, unfortunately.
Case Study: CNN
For example, I did some research on a high traffic website created with ReactJS: cnn.com.
While studying, I came across a case study that measured the processing time of the homepage of CNN last year.
Find it here.
Looking at a more recent analysis we can conclude that it hasn’t improved much since.
Resulting in a faster website that is accessible to more people.
Therefore, a question you could ask yourself is: “Do I really need a front-end framework to make a website? Is something like ReactJS, a framework created to handle billions of page views every month, necessary for an app that will only be served to a handful of users?”