Last Updated - Thu Dec 13 2018

Fast Food JavaScript Frameworks Today large god frameworks are all the rage, but are they healthy? Just like eating fast food out of convenience, using a fat, fast food framework means our applications are obese and out of shape. Developers can produce much healthier applications once they realize they can cook at home, against the browser's native APIs. This means lower costs, higher user satisfaction rates and healthier applications.

The Centers for Disease Controls estimates over a third of the US population is obeese, conservative by my observations (I include myself in the statistic). The CDC goes on to point out the health effects and added costs due to our excess baggage.

-Obesity-related conditions include heart disease, stroke, type 2 diabetes and certain types of cancer, some of the leading causes of preventable death.-The estimated annual medical cost of obesity in the U.S. was $147 billion in 2008 U.S. dollars; the medical costs for people who are obese were $1,429 higher than those of normal weight.

The CDC goes on to point out obesity affects specific ethnic and age groups more. The ethnic groups correlate more to lower income, less educated demo-graphics and more seasoned citizens.

Today's web development has a similar profile. Sites are fat, and have the disease of poor experience. This excess weight creates unwanted overheads and development delays. We can also point to certain platform demographics as problematic: Wordpress, Enterprise Applications and those using god frameworks.

How did we get to this point?

We eat fast food because we feel rushed. The food is pretty tasty because we have forgotten what fresh food taste like. Eating out is not as healthy as eating at home. This combined with a sedentary lifestyle has led to a very obese modern population. Web sites are suffering a similar fate.

Developers and architects choose fast food frameworks for similar reasons. Most developers forget what it is like to talk to native APIs and think it is took difficult to write a lean application. Many do not take the time to learn new things and therefor feel overwhelmed when it comes to creating modern web user experiences.

I took the time to find links to nutrition charts for many popular US fast food restaurants. Nothing I order would fall in my healthy guidelines.

Value meals come with fries and a Coke. Calories, fat, sugar and very little good things we need. My guess is the typical personal fast food order contains between 12-1600 calories. We have heard this message for several decades now, yet we still visit fast food places almost everyday. Doing some research the typical adult needs between 2000-3500 calories a day, depending on age, weight and activity level.

So why am I talking about fat Americans and healthy diet in a Blog post on JavaScript frameworks?

There are many correlations to today's web, it is fat and out of shape. It makes site development more expensive and harder to maintain. My experiences and interactions over the past few years make me confident to say the majority that call themselves web developers lack web development knowledge. Instead of learning the platform (HTML5, JavaScript and CSS) they seek out fast food solutions or god frameworks.

The most recent stats show the size of the average web page to be about 2MB. Too low based on my observations. My estimates are closer to 5B. HTTPAchive's weight break down looks like:

59kb HTML
304kb JavaScript
62kb CSS
1.3MB images

Last year Angular, Ember and Backbone seemed to have everyone's attention in the JavaScript space. Bootstrap had CSS locked down. This year is seems like React is getting all the attention. In years past we heard names like jQuery, Prototype, MooTools, etc. They have all come and gone and left scar tissue as their legacy. What has not change, but only improved is VanillaJS, the native APIs.

god Framework Weights

jQuery 2.1.3 - 83kb
jQuery 1.11.2 - 94kb
Angular 1.314 - 123kb
Ember 1.10 - 373kb
Backbone - 20kb + 17kb (underscore)
React 1.1.2 - 130kb (core, just the templating functionality)
React + Addons - 270kb
Bootstrap - 220kb

Of course each of the frameworks offers and ecosystem of extensions that most applications leverage, adding even more weight to the application's foundation. This is the web developer's extra value meal, super sized.

Odds are applications rarely use 90% of what a framework offers. They are full of code fat and syntactic sugar. Web pages are fat and slow and we constantly read the web cannot compete with native applications. This perception is due to sluggish, janky applications we build. When I build a web application one of my goals is to build an experience superior to a native counterpart. I find it rather simple and intuitive because I use the native APIs, which means I need not rely on a large god framework.

HTTPArchive archives the site of the average web page by surveying 100s of thousands each month. It compiles data and creates a breakdown of what composes the typical web page today. We just cracked the 2MB mark, an embarrassing accomplishment. The average web page I encounter using tools like WebPageTest or just my browser's network tools weighs well over 5MB.

This weight is broken into 2 distinct categories, file size and number of http requests. We have known for years smaller files load faster. We also know faster web sites use fewer http requests to load. That initial loading experience is crucial because people do not like to wait. In fact if you are not fully loaded by 3 seconds you have lost over half of your potential customers.

I make an extra effort to get my applications loaded within 1 second over broadband. Over a cellular connection I shoot for under 5 seconds. This means a small HTML payload, a single, small CSS file and similarly small JavaScript file. From there it is up to the number of images needed to drive the user experience. Even those I run through optimization tools to make them as small as possible. Subsequent loads are instant or as fast as instant can be if the user must wait on the browser to start (boot if you will).

Because god frameworks are large and fat I cannot accomplish these goals. Most take between 700-1500ms to load, and some times I clock them closer to 3 seconds. Plus they must all be evaluated by the browser, further delaying load time. For most popular web sites this is only compounded by poorly written third party advertising and analytics scripts. I rarely find these scripts ever load and execute within a desired performance budget.

While the intent of syntactic sugar is to make code easier for humans to understand when a framework 'invents' a syntax a developer and business must buy into that framework with a long term commitment. JavaScript frameworks have a documented history of coming and going. If you went back and looked at the popular 2008 frameworks you would see a list of names long forgotten. Only jQuery survives and it is on the decline today. Last year Angular was king of the hill, only pushing itself off by announcing 2.0. This year predictions are all cheering React.

Developers learn how to work with these frameworks instead of the native APIs. After interviewing and talking to many developers last year I am fairly certain most enterprise developers cannot select and element without jQuery. Most enterprise developers have never heard of localStorage or realize browsers have supported native Geolocation for over 6 years. Instead a developer or a company commits to the framework du jour thinking they have job security or that their applications will be cheaper to build and maintain. My friend Chander calls this Resume Driven Development (RDD).

Instead they wind up with fat messes they must rip out a year or two later. If you think I am lying you should see how many requests past my way to help rip Angular out, and I am not even trying to offer this service, yet.

The promise of convenience and a known quantity at an assumed cheap price lures many senior architects and development managers to chose one of these fast food frameworks. To be fair the typical enterprise decision maker has no clue how to build a front-end client. The attitude I have been fighting since that mobile first application 5 years ago is the front-end is simple and should just plop together. This is not true.

Enterprises drive up to the fast food framework window and order a super-sized value meal for their front-end, thinking they are saving time and money. Developers feel they are choosing a sense of job security. Both are being fooled because neither is eating a healthy web development diet. The enterprise gets a fat, out of shape application that will need to have laparoscopic surgery a year or two later if not succumb to the binary equivalent of diabetes.

What Can Enterprises Do?

I pick on enterprise because this is the class that seems most affected by these god frameworks, but this applies to any web development project. We all want code we can maintain and develop. But end users rule, which mean we need speed and performance. Instead of learning today's framework learn the native APIs and how to create a module and structure your application. Frameworks provide an opinionated approach to an application architecture, an attempt to solve everyone's problems. Your problems are not everyone else's. You do need to use the native APIs at some point and I encourage enterprises and web developers to start cooking home made meals instead of eating fast food code. These are some simple steps to help get you there.

Set A Performance Budget

Set a performance budget and make it part of your build workflow to hold you accountable. Tim Kadlec defined a performance budget as:

A performance budget is just what it sounds like: you set a “budget” on your page and do not allow the page to exceed that. This may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or size of the page.

For example I work to achieve a 1000ms load time for all my applications. This is because the mind starts to wonder at 1 second, or the user starts loosing focus and their mind wonders to something else or develops anxiety. If you think they are more forgiving for mobile devices you would be wrong, many expect it to load faster on their phone than the desktop. I achieve this by managing my asset sizes and number of requests.

Setting a performance budget is similar to my personal goal to lose over 60 pounds in 6 months. The starting point was seeing how much I weighed, too much and more than I believed. When I show clients their site's waterfalls and times they are often in shock. Most site owners think they are loading quickly, but the reality is they are loading in 8, 10, 20 seconds or more. Most sites I profile have 100s of HTTP requests and are well over 5MB complete. To compare to my applications, a typical application total is less than 200kb, but can vary by the number of images being used.

Since January 7th I have weighed myself every morning using similar conditions. I have tracked my weight and began correlating it to activity and meals. My weight loss has become more pronounced. Setting a budget is the first step, measuring changes is the next. You will not be able to trim your web site's fat overnight, it will take time.

The first step is bundling and minifying all JavaScript and CSS into 2 HTTP requests. From there start eating leaner by trimming unused script and CSS. Track the changes and keep that downward trend going till you reach your goal. I have days where I gain weight, but mostly I loose. You should have a similar experience with your web development efforts.

Learn the Native APIs

Removing frameworks and libraries is scary if you have never cooked for yourself. Take some time and learn how to use native APIs. Learn how to select elements without jQuery, then how to manipulate the DOM natively. I love the site You Might Not Need jQuery because it demonstrates how simple it is to perform common jQuery functions, including AJAX, natively. Today you no longer need to worry about legacy browsers or differences in browsers. By this time next year the IE 8 problem should be forgotten, leaving only a modern browser landscape.

By cooking for yourself you own your code and can solve problems better. You will save time and money in the initial development as well as long term maintenance. Less code means less effort and means higher user satisfaction rates. Over time you still have less code and better developers.

Summary

We Have Made the Web In Our Own Image, Obeese!

We have made the web in our own image, obese. I am not the first person to say it, but it rings true. The web is morbidly obese and needs to go on a diet. Developers do not know how to cook for themselves. Fast Food god frameworks are taking advantage of enterprise decision makers to provide high fat, high calorie applications platforms. Developers and enterprises are both missing out on a healthy nightly dinner with the family and how to cook for themselves. Reducing application size makes them more agile, fast and easier to maintain. The cost to build a Vanilla JS or Micro JS style application is the same and often less than one built using a popular framework. The browser APIs rarely change, they only get better. Frameworks are here today, gone tomorrow and leave behind a trail of fat scar tissue and unhealthy applications that die or need major work to keep alive. Learn to cook at home and avoid fast food joints. Once you learn to use the native APIs you will never want to use a fat god framework again.

Large JavaScript Frameworks 🐌 Are Like Fast Food 🍔🍟🍕 Restaurants - Full of Fat, Syntactic Sugar 🍭 and lack of Nutrients