Yes Fast Food Frameworks Cost Too Much
Last Updated -
Last week Chrome's Paul Lewis released an article called 'The Cost of Frameworks' that stirred up the web development community.
These sorts of articles stir up many online responses, from Twitter replies to articles like the one you are reading. Friday morning I came across one by Dave Rupert, which referred to one written by Ember's Tom Dale. Dave is closer to my response while Tom's is understandably the opposite.
First let me say Paul is right on point. This article not only echoes statements, blog posts, presentations and even books I have written over the past 5 years or so, but does so with a real test. In fact I am glad he used the ToDoMVC project because I had toyed with doing the exact same test over the past year. My problem is having enough time to execute the tests.
Here is the #1 reason you should not use a Fast Food Framework in your web application, they suck on mobile. I found this out 5 years ago when I had to build my first serious mobile first web application. jQuery took about 60 seconds to load over Sprint 3G. Not to mention how long it took to evaluate on phones. Evaluate is the time it takes the browser to run a script. You can think about that as the application boot time.
Bandwidth and your phone may be pretty good these days, but the majority of people are not on an iPhone 6 over 100MB broadband. They are on what I call a Crapdroid and spotty 4/3G GPRS (cellular) connectivity. Even in the ideal scenario that iPhone 6 is no where near as powerful as the average developer machine.
You see when I built that mobile first web application reality hit me quickly because I tested it on my phone, over Sprint 3G. It sucked, it was painful and embarrassing to show to people.
Fun Fact, in 2010 a survey found 12% of users expect web sites to load faster on their phone than their desktop.
Sadly to this day the web experience has not improved. Much of this can be directly attributed to developers using Fast Food Frameworks and avoiding web development best practices. I feel this all the time, even on the highest profile web properties, I am looking at you ESPN.
There are absolutely 2 things end users want, easy navigation and speed. After that you are lost in the long tail and there is a wide gap from those two requirements and the rest. Basically nothing really matters after ergonomics and speed.
The good news is developers and designers can control these two factors. Since this is an article about performance I will stick with that.
Here are some guidelines you should follow:
14kb is your friend
This is the smallest HTTP data packet and means you can have an almost instant loading experience. You can pack a lot of action in 14kb without trying too hard. The initial payload should contain all the markup for your initial views as well as the core CSS.
Round Trips are the Enemy
This is why I realized Single Page Applications were the right way to build modern applications 5 years ago. There is no back and forth to the server, payloads are lighter and transitions are instant. You can hide AJAX latencies with animations and other slights of hand. Plus you should always have a good client-side data caching strategy.
Again understanding HTTP slow start is important here. Large fast food frameworks take much longer to load because they are big. Most of my web apps are the size of the smaller fast food frameworks are less, all inclusive.
The more JavaScript the Longer it Takes to Evaluate
The more there is to read the longer it takes, right? Think about mobile processors, they have a fraction of the power and speed of the average desktop processor. Tim Kadlec did a nice post on this topic just over a year ago.
Cellular Bandwidth is Expensive
I love Tim Kadlec's What Does My Site Costs. Always run your site through his application to see the tangible impact you have on your customer's wallet. Yeah Tim gets more than one reference because he is just that awesome.
Paul makes some great points that I have been preaching for years, but receiving a lot of resistance. At least resistance from back-end developers. Front-end developers love my approach because they understand the browser.
Fast Food Frameworks are Problematic in Many Areas
High Learning Curves
I will argue with anyone learning the browser API and basic JavaScript best practices is much easier.
Re-learning when the framework
When the fast food team decides to change the architecture, what do you do then?
Debugging the Framework
Don't you have having to hack around bugs? Yeah me too, but when it is my bug I don't hack I just fix it.
Time to Bootstrap
How long does it take to load the fast food framework? See my previous point pointing to Tim's study.
Bandwidth
Again not cheap. Check out Tim's What does my site cost tool.
CPU Usage
When was the last time you considered if you are draining your customer's battery life. Having to scramble for a power outlet or carrying a backup charger in my bag is not my idea of good user experience. Frameworks do things that trigger more battery consumption by making the CPU work harder.
Frame Rate
Most frameworks do JavaScript animations and not CSS. Take advantage of the native animations and the GPU.
Memory Usage
Memory leaks are bad and fast food frameworks leak all over the place.
I have not found a framework yet that does not create memory leaks. React you are the absolute worst. Please avoid this fast food framework at ALL COSTS.
A single page web application should be able to run all week on a customer's device without needing to be rebooted because it becomes sluggish or crashes the browser. Memory leaks are the root cost of this issue. Since a SPA sticks around these leaks just keep adding up until poof, the browser crashes and the user is left confused. Worse the customer thinks you are incompetent and moves on to your competition. I can usually make Facebook crash a mobile browser in 5 minutes.
The SPA Boot Cycle
As Paul gets into his test he tries to educate you on how your fast food framework loads. First is the HTTP request life cycle. This is where the browser asks the server for the file(s) and waits. The larger the asset the longer this step takes.
Steve Souders documented many years ago that 80% of our performance issues are in the client, not the server. This is because the server processes tend to happen fast. Then the browser needs to download the assets to rendering the page. Mobile is the predominate way a customer accesses the web today, which has moved the percentage to 95% client.
In a SPA you are downloading the application and booting it. This time should be a fast as possible, I mean like 500-1000ms fast.
Paul shares a graphic that tries to make the application boot process tangible. The browser requests the JavaScript, then parses (evaluates) the script. The browser then executes the application, which should trigger an AJAX request for the data. The data arrives and the application must use it in some way to render the data and the markup.
Large Code Bases Require A Fast Food Framework
Tom Dale makes the following statement in his post:
"Many developers have worked on a project where the complexity of the codebase swelled to be so great that every new feature felt like a slog."
He goes on to make the fantasy statement that fast food frameworks make these large code bases easier to manage. That is demonstrably false. My over 2 decades of professional experience tell me that code bases get large due to lazy developers. Instead of taking the time to understand problems they tend to search stackoverflow, take the first answer to a problem and copy paste blindly.
Not only does JavaScript get messy so does the markup and CSS. This is a systemic problem that no fast food framework can solve.
You fix this problem by hiring competent developers, architects and having good governance in place. You also need to have continual performance metrics being measured. You cannot fix what you do not measure. This is why setting performance budgets is one of the first things you should do when starting a project.
Analyzing Paul's Test
Paul's test setup is done correctly, using the browser's timing APIs and comparing different fast food frameworks with the vanilla JS ToDo MVC. I like the ToDo MVC project because it gives you a chance to see the same application done using different architectures and fast food frameworks. So it should be an even playing field.
The data Paul collected is pretty damning to the fast food framework world. I would like to note Paul did not include the time to download the framework, which would have certainly added even more latency to the user experience. I would have included this as part of the overall data.
Perceived Fast Food Framework Benefits
If you think fast food frameworks are fun to work with that is fine, have fun, just don't punish your customers.
If you think you can build an MVP faster with a fast food framework you are wrong. I would say you just do not have proper scaffolding in place. In fact I am way more productive without a fast food framework.
If you think frameworks work around platform bugs I think you are mistaken as well. First the bugs between browsers are not that common anymore, at least not like when jQuery gained popularity. Plus all frameworks have bugs, which of course you need to hack around.
Trust me you can get paid knowing how to build good front-ends. I do. Real customers will pay for good experiences and you make the best user experiences when you understand the platform (browser) and not a framework.
In the middle of Paul's article he talks about developer ergonomics versus user needs. Let's set the record straight, fast food frameworks are about selling perceived developer convenience, not user experience. And if you have not picked up so far fast food frameworks are not about user experience. They are targeting developers and their need to write copious amounts of code.
Conclusion
I hated to dump jQuery back in 2010, but it was the best thing I have done in a long time. It taught me I don't need a large library to accomplish great things. Don't get me wrong I love jQuery and what it did for us. But the reasons why jQuery was created are no longer problems and the browsers have increased their API features with common standards. This makes our life much easier.
The real benefit was my web applications now worked well on mobile devices. This made my customers very happy and that is the primary goal of software development.
Fast food frameworks are the new jQuery. However they are much more dangerous because they abstract the developer too far from the platform. They are too opinionated and idiomatic. Becoming proficient in today's fast food framework does not serve you well next year when it changes syntax and architecture or another fast food chain takes its place.
Don't believe me, last year Angular was the cool franchise, this year it is React. I am already getting a feeling Angular 2.0, which has nothing to do with Angular 1.x is going to be popular next year. Then there is Ember, which has a loyal cult following. And what happened to Backbone? Oh and Aurellia, vuejs and the list goes on.
I just call mine love2spa. It is a collection of libraries and good architecture. I keep the libraries on my GitHub.
A vanilla approach based on modular libraries and good architecture is the best bet. Problems can be removed quickly, replaced with better solutions. Your development team can follow best practices and governance through good architecture. Plus they are much better equipped to solve problems because they understand the code base and the platform much better.
Thinking you cannot create complex or large modern web applications without a fast food framework is another fairy tale. I build and have been building large, complex single page applications since 2010. The first one was a 400 view/page SPA and it forced me to create an architecture and set of best practices. I still follow those patterns and have refined them over the years. I build these applications by myself or with a very small team.
If you are a selfish developer get fat and use fast food frameworks. If you value your customers avoid fast food frameworks and make a good home cooked meal with real ingredients. Your applications will be healthier and provide the user experience your customers need and want. It will make your company stronger and have a competitive advantage.
We make things way too complicated. Fast food frameworks give us a false sense of security, convenience and simplicity. But they do just the opposite and they create a sub-par user experience. DaVinci once said simplicity is the sign of beauty...or something like that.