
The Cost of JavaScript Frameworks - elorant
https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/
======
aardvark1
I've working at large F100 financial services companies as an engineer and
technical manager for 10 years. I've seen front ends built using a myriad of
techniques and frameworks.

Leaving bytes and bundle weight aside, in 2020 JS frameworks like React are
far and away the best approach for front-end engineering from a large
organizational standpoint.

1)Not difficult to hire for. JS frameworks are currently in the sweet spot
where they're both widely popular and "cool". Consequently it's not hard to
find good candidates. That wasn't the case 5 years ago where React/Angular
developers were still uncommon.

2) The HUGE and helpful community of developers. There are so many excellent
resources for learning and solving problems with JS frameworks. JS developers
are eager to show off on medium and similar sites. I've never seen such a
large and enthusiastic community. This will inevitably subside as JS fall out
of favor but I hope it doesn't for a long time.

2)Rapid UI development. The JS ecosystem make it easy to build UIs quickly
that don't completely suck and look good for the ever-important demos to
senior leadership.

3)Opinionated frameworks naturally enforce best practices and ensure
relatively consistent architecture. This makes it easy to move engineers from
one team to another and make grokking new codebases a lot easier. New
engineers are productive quickly and begin creating value for the company.
This was not the case with the inevitable jquery monstrosities that resulted
after a critical mass of code or # of engineers.

4)Fewer bugs. JS ecosystem makes it very easy to write unit and integration
tests.

Companies with IT budgets that are 9+ figures will happily pay for extra bytes
across the wire in exchange for those benefits

~~~
ng12
Absolutely agreed. I have never in my life had a stakeholder get on my case
because our site was 3mb when it could have been 1mb. I have had many
stakeholders get on my case because we couldn't turn around features fast
enough, or the site was buggy, or our UX was worse than our competitors. Those
are the things that the people who pay me and my team care about and if I
could 10x our bundle size for a 1.5x improvement in development speed I would
do it in a heartbeat.

~~~
tiborsaas
Dev experience and productivity is key, but don't forget that 10x bundle size
has effects you can't simply dismiss. It does cause a UX problem since a
slower pageload is part of the UX.

SEO. Google also takes into account page / paint times.

These are the things your stakeholders probably don't know about but you
should.

~~~
dirtnugget
As a Frontend Engineer I can assure you there are ways to counter that issues
but they're not exactly popular: Server Side Rendering. It adds another step t
the build process in which HTML is prerendered, so you get the speed of
loading plain HTML. It then loads the actual JS in the background. It's a PITA
to implement

~~~
tiborsaas
With tools like Next.js or Gatsby it's not that bad. We use Next at work on a
large scale and it works for us. But do you know what language gives you
instant SSR? PHP :) It's funny how we had to invest so much effort to
replicate with another language supports out of the box. I've built a blog in
a few hours with Craft CMS, perfect tool for the job this case, I didn't even
have to touch PHP files, just the templates.

------
horsawlarway
Ok, so I generally agree with the content of the article.

I want to pick on the up front assumption though. He lists 4 costs that are
paid -

\---

The cost of downloading the file on the network

The cost of parsing and compiling the uncompressed file once downloaded

The cost of executing the JavaScript

The memory cost

\---

What isn't mentioned is WHO'S paying those costs. And I think that generally
matters when you're trying to convince companies with a profit motive that
they're doing the wrong thing.

My issue is that of his 4 costs, 3 are all paid by the consumer of the
product. The ONLY cost paid by the company is the extra network traffic to
download the JS bundle. Even that can be optimized to a VERY small number if
you're using good caching and have a cdn in place. The individual consumer
might still wait for that network payload, but the company's objective cost is
still going down.

So in general, what's the compelling argument that I should care about the
rest of the article? None of it is bad advice. It just seems that the only
real benefits I might get are two user features

\- Faster sites

\- Better battery usage

Users like those things, but they don't put them anywhere close to the top of
the priority list for most products.

So I'm really walking away from this seeing a savings still. As a developer, I
don't really love that opinion (I want to make good products that are fast and
and small), but as a company stake-holder with a lot of possibly things to
prioritize... This sounds like bad advice.

~~~
nottorp
So basically we're getting shit slow apps as users because they're cheap to
make.

As a user I thank you.

~~~
claytongulick
Would it be better to not have the app at all? Time to market and dev costs
are key considerations for startups. Many don't have the option or funding to
do things perfectly.

~~~
nottorp
90% of the cases... yes, it would be better.

~~~
horsawlarway
Last I checked no one is making you use something you don't want to.

If you think you're better off without a product, don't use it and let the
market work itself out.

Frankly, I mostly even agree with you. I rarely install more than 5 or so apps
on my phone these days, and I visit a pretty paltry number of sites
consistently, but that doesn't mean someone, somewhere, isn't getting value
from those products.

One man's trash is another man's treasure.

~~~
Can_Not
> Last I checked no one is making you use something you don't want to.

I just checked, my boss is making me use slack, and nobody is writing a non-
electron competitor to slack...

------
arpowers
In practice, performance is rarely the bottleneck.

On the job, most developere care about shipping on time and spending less time
rewriting things as they learn via experience.

Anyone who avoids frameworks is going to be in for a world of hurt when they
have to explain to their boss "I know the project is 3 months late but I saved
100kb in bundle size"

~~~
lhorie
Counter point: I've seen projects that were blowing their budgets/deadlines
due to:

\- people not being familiar w/ the chosen framework and being unable to
figure out how to accomplish some of the deliverables

\- wrong framework for the job

\- analysis paralysis figuring out which frameworks to use

\- using the framework wrong and then drowning in code debt

The point of the article, I think, is that there's a tangible difference in
performance between _similar_ frameworks, but which isn't often considered
when choosing frameworks.

You'll often see developers say that they prioritize developer experience over
things like runtime characteristics of a framework and there's a lot of
handwaving about "maintainability". This despite there being extremely complex
apps out in the wild written in obscure frameworks (e.g. lichess uses
mithril.js and the code looks just fine).

There's clearly a disconnect somewhere when, for example, facebook announces a
homepage redesign using the latest and greatest tools and immediately people
start complaining about its performance.

I would not buy a slightly wobbly table from a carpenter that wants to use a
more ergonomic hammer, over a not wobbly table from a carpenter that uses a
cheap hammer. Similarly, I think what the article illustrates is that a
developer should also act like a craftsman and critically think about the
effectiveness of their tools in terms of end results, rather than blindly
accepting tool marketing/status quo and disregarding the quality of the end
product.

~~~
mikelockz
I like your table analogy. I would think that a more ergonomic hammer would
also have tangible benefits like the ability to work longer and faster,
creating more tables per day and lowering the overall costs of production
resulting in cheaper tables.

Would customers be willing to buy a cheaper table that's wobbly vs a more
expensive table that's not?

~~~
lhorie
I'm not comparing a wooden stick with a high end hammer. I would think a
competent carpenter would have a decent enough hammer, but not necessarily the
shiny cool x-titanium-3000(tm), because any difference, if they exist at all,
would be well into diminishing returns territory.

At the end of the day, the wobbliness of the table is a result of whether the
carpenter cares about table wobbliness more than which hammer they use.
However, it may say something about the level of craftmanship and competence
of the carpenter if they got suckered into buying a well advertised
x-titanium-3000(tm) to compensate for an unwillingness to put in the effort to
master core carpentry skills.

Another similar analogy is an audiophile buying gold plated HDMI cables for
better sound quality, oblivious that the reality is that the signal going
through said cable is using a digital protocol with error correction.

------
tengbretson
This is interesting data, but unless there's a way to normalize this against
the feature set of the sites in question, then there's way too much selection
bias to use this to draw any meaningful conclusions.

~~~
BerislavLopac
There is: [http://todomvc.com/](http://todomvc.com/)

~~~
guntars
Looking at the framework-less ES6 implementation makes me hope I never have to
maintain code like this.

[https://github.com/tastejs/todomvc/blob/gh-
pages/examples/va...](https://github.com/tastejs/todomvc/blob/gh-
pages/examples/vanilla-es6/src/view.js)

~~~
karatestomp
... what's so bad about it?

~~~
guntars
It's a minefield of potential bugs:

    
    
        this.$todoList = qs('.todo-list');
    

This bit will only work if there's only one `.todo-list` on the page and it'll
break if you try to use more than one component.

    
    
        const listItem = target.parentElement.parentElement;
    

This will break the second you change the template and have to add a wrapper
for any reason.

    
    
        input.value = target.innerText;
    

Using the DOM to store your data is just wrong. Browsers can and will change
then contents of your nodes if they feel like it. They can strip whitespace,
for example. This would be a problem if you're trying to use some kind of
change detection.

    
    
        this.$todoList.innerHTML = this.template.itemList(items);
    

Better hope that whoever wrote itemList knows to escape the data properly.
Have you noticed how XSS used to be a much more common issue until the advent
of view frameworks? Experience has taught us that at least for security you
simply cannot depend on the developers to always do the right thing,
especially since their experience level might be all over the place.

    
    
        const elem = qs(`[data-id="${id}"]`);
        
        if (elem) {
            this.$todoList.removeChild(elem);
        }
    

Global selector again, it also depends on the elem being the child of
$todoList which is not guaranteed if there's any change to the template.

    
    
        listItem.className = completed ? 'completed' : '';
    

This will clear any other classes that the element might have on it. You might
add some styling to it and then wonder why it breaks after you click a button.

    
    
        target.dataset.iscanceled = true;
    

Storing data on elements is also risky, since there's a lot of other code that
updates innerHTML wholesale so your element might not be there anymore.

This is just one file. The point I'm trying to make is that this direct DOM
manipulation makes for brittle code and only works for very simple cases. Once
you have even a small amount of behavior, any sane developer will want to
abstract it out a bit and you'll end up with a framework anyway. Better to
choose a low overhead one from the beginning.

------
austincheney
The article sticks to performance expenses upon the end user where it has the
data.

I am more curious how much frameworks cost at development time. Framework
advocates always claim their pet framework makes development so much faster
and cheaper but there is no data on that. That begs a few questions:

Do frameworks reduce hours of labor to build an application? If so how much?

Do frameworks lower the maintenance expense of a given application? If so how
much? That number should include any sunset or revisions due to changes in the
framework not associated to changes in the business requirements.

Do frameworks reduce the team size or business support staff to ship an
application? If so how much?

Do frameworks lower developer hiring expenses and wages? If so how much?

~~~
marcosdumay
There are almost no good studies on any question of software engineering. We
all go our entire days based on feelings and anecdotes, it's not just about
Javascript frameworks.

It would be good to change this, yet, software engineering is a very hard
field to study.

~~~
austincheney
Too hard to know is not a business justification. Imagine if you floated that
argument as a lawyer, doctor, engineer, or even a truck driver. Your license
would be revoked.

~~~
marcosdumay
Hum... Are you candidating yourself?

~~~
austincheney
After having worked in other professions where ethics are such an early
foundational principle it is rather interesting to see people so hopelessly
lost and foreign to the concept.

~~~
marcosdumay
So, if I'm reading it right, no you are not candidating yourself, and you
think not candidating oneself is an ethical failure?

By the way, that argument that something being difficult is not a business
justification is flawed on every level.

------
lukifer
If vanilla HTML/CSS/JS is "Assembly", and heavy frameworks like React/Angular
are "Java", what's the web app equivalent of C (light abstraction and close to
the metal)? Svelte?

~~~
g_delgado14
Well with wasm, this analogy doesn't really make much sense.

~~~
thephyber
wasm doesn’t have the ability to access the DOM, which is the majority of the
purpose of JS in the browser.

------
keb_
I have a Moto G5 Plus from 2017. It does almost everything I need, and
performs perfectly fine doing those things: making phone calls, checking my
calendar, moving files, and sending text messages. While performance in these
areas have mainly remained static, one area where my phone has gotten
progressively _worse_ over time is web browsing. Sites that I used to visit
often are now bloated, resource intensive webapps that overheat my phone and
crash Firefox Focus.

I know it's unrealistic to impose strict dependency criteria, framework
choices, and bundle-size limits on the job. But if you're the one in charge,
even if it's in your hobby project, please consider your consumers who may not
have the latest in greatest hardware. I find it absurd that a phone from not 3
years ago struggles to run most popular sites.

------
seph-reed
I created a framework a year ago and have been battle testing it since. It
uses no virtual dom, but still has state management.

I just wanted to say that, because I've been holding it in so long.

~~~
seph-reed
Seriously. I'm kind of excited about it. I definitely discovered something
amazing here... I can do more than React, Vue, and Angular combined with a
very tiny "framework". It doesn't have a virtual dom, so it's not really a
framework, it just makes it quicker and easier to make auto-updating HTML
Elements. You could mix it with anything else that uses HTML Elements no
problem. Also, it leverages native code for everything, doing as little as
possible in JS.

The real trick was something I call Source Derivation (SDx). I'm certain it
will be a language level feature 10 years from now.

I'd like to release it soon, but I'm afraid of doing it alone. It's depressing
to put a project out there, then have to be alone as nobody cares.

~~~
hewrin10
Technically, the project is alone and nobody cares right now (obviously due to
it being anonymous). So the only way is up!

~~~
seph-reed
Lol. Thanks.

I released some solo albums a long time ago and learned the hard way that
sometimes it's better to just keep your passion projects to yourself.

------
commandlinefan
At least with jQuery, I could at least understand what you were getting for
all that performance cost. I haven't had a chance to work with React or Vue,
but I did spend a lot of time working with Angular and I was always left
scratching my head as to what benefit it was supposed to provide beyond making
my pages take longer to develop, download and run.

~~~
zachrose
Ironically, the standard and nicer API that was jQuery’s value proposition has
mostly already arrived in browsers.

~~~
horsawlarway
Yup, I can no longer recommend jquery at all unless you happen to need to
support IE10 and below (and please, honestly, for the love of god, don't
bother).

~~~
marcosdumay
Nah. Nowadays JQuery is a simple and small library with high-level
abstractions and convenient synonyms for the standard in browser
functionality.

Unless you need IE support. If so you need a different version that is quite
large.

~~~
horsawlarway
Eh... I still wouldn't recommend adding it to new projects. Why add a new
framework that's mostly just a synonym for the standard browser functionality?

I'm certainly not going to suggest you stop using it if you've already pulled
it in (like you said, it's pretty tiny these days), but most times I just
don't think it's worth it. More so if you're not already familiar with it.

------
Scarbutt
Turbonlinks is a decent compromise for many sites.

~~~
hfourm
Honestly I found turbolinks to be an abomination, even the newer version.

It's "ok", but doesn't play nicely with any 3rd party anything.

------
mrighele
I would like the same test done without ads (let's say behind a PiHole). In my
experience that makes much more of a difference than the framework used

------
irrational
Am I reading this right? Of the frameworks studied, Vue consistently has the
best numbers by far?

~~~
rk06
There are lies, damned lies and statistics.

The data is comparing frameworks along percentile, which is misleading, __when
you realise that performance is a function of total payload,__ not relative
percentage.

If the data of various frameworks was compared against total userland code &
Toal size (user +framework), then we could have some meaningful data.

As it stands, I can say with confidence, that most of the larger and bigger
apps use Angular, or react combination because they are most popular.

Considering that angular itself is heavier than React, angular apps will be
heavier than React ones.

While smaller apps (or pages) will use Vue, because:

1\. Vue is the only one of top 3 which can scale down to a script tag. So, for
large classes of Web Apps, Vue is the only option.

2\. Vue (&vuex) is smaller in size. And does not require boilerplate like
react and redux. So I would expect Vue apps to be generally smaller than
alternatives.

 __Given these situations, I would be surprised if Vue apps (on both average,
and relative percentile) do not perform better than Angular & React __

------
greatgib
Very interesting report of something that everyone is experiencing without
being able to quantify it.

A big issue with big sites operators and compagnies is that everyone is
looking at his own site consumption and performance, but look at that alone,
on an empty computer. But, the issue is more the impact on their single page,
on a computer that is already loaded with a few applications and tabs.
Suddenly, a website using 5% of cpu and 250 MB of memory, starts to have a
very huge impact on the user.

------
hyperpape
No idea if the author will read this, but it would be nice to break out sites
that have none of the frameworks. It's a tiny fraction of them, but still
could be interesting.

~~~
theandrewbailey
See the footnotes. [https://timkadlec.com/remembers/2020-04-21-the-cost-of-
javas...](https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-
frameworks/#footnote-1)

~~~
hyperpape
Honestly, it's kind of a confusing footnote. It provides a subset of the
stats, while sorta-but-maybe-not arguing that they're not relevant?

------
a13n
> JavaScript Bytes Served to Desktop Devices, by Percentile

Is this gzipped or uncompressed bytes?

Article doesn't specify, but based on the word "Served", I'd assume gzipped?
As in bytes over the wire? Would love clarification.

~~~
tkadlec
Bytes over the wire (I can clarify in the post too).

So _most_ of that weight is gonna have gzip or brotli applied. (Last I looked,
around 17% of JS requests recorded by HTTP Archive are uncompressed.)

------
petulla
Would be interesting to see this normalized by say DOM elements per page. Also
Svelte and other lean bundle approaches should be included.

------
leke
I'm loving React at the moment, but I'm also learning Svelte for this very
reason too.

------
galaxyLogic
What about browser-cache? Doesn't it solve this problem to a large extend?

------
naranha
On the bright side, the performance tax we had to pay before the current
generation of frameworks was often the "full page reload" tax, needing to
parse megabytes of CSS, JS for almost every user interaction.

~~~
goatlover
Aren't those usually cached? Page reloads these days are fast.

~~~
avens19
They said parse which is true regardless of caching

~~~
goatlover
The JS parsing would be less.

------
up2you
With Static Site Generation, you can use React to generate plain HTML/CSS/JS
that you then deploy as your actual website. Seriously, this tech is very very
fast. Just check out how fast these websites are:

[https://spectrum.chat](https://spectrum.chat)
[https://vercel.com](https://vercel.com)
[https://gatsbyjs.org](https://gatsbyjs.org)

