23 ms·

The Cost of JavaScript Frameworks

154 points by elorant 7y ago

hyperpape 7y ago
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 7y ago
  See the footnotes. https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/#footnote-1 https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
  - hyperpape 7y ago
    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?
tengbretson 7y ago
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 7y ago
  There is: http://todomvc.com/ http://todomvc.com/
  - guntars 7y ago
    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/vanilla-es6/src/view.js https://github.com/tastejs/todomvc/blob/gh-pages/examples/va...
    - chrisco255 7y ago
      Yeah, this is what web dev was like before these frameworks came about (except web standards were worse 8 years ago). If you're building a complex application with more than 2 or 3 devs, a framework is a must.
    - itronitron 7y ago
      That looks like fairly standard code for defining UI behavior in native frameworks as well, it's not particularly nightmarish.
    - karatestomp 7y ago
      ... what's so bad about it?
      - guntars 7y ago
        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.
- jordache 7y ago
  grouping feature set complexity is going to be subjective exercise as well. A randomly sampling is better.
a13n 7y ago
> 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.
- jordache 7y ago
  Isn't relative comparison they key point here? Absolutes doesn't mean much
- tkadlec 7y ago
  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.)
lukifer 7y ago
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?
- deleted 7y ago
  [deleted]
- flowerlad 7y ago
  How about these libs: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/
- g_delgado14 7y ago
  Well with wasm, this analogy doesn't really make much sense.
  - thephyber 7y ago
    wasm doesn’t have the ability to access the DOM, which is the majority of the purpose of JS in the browser.
  - lukifer 7y ago
    It is a very very loose analogy ;)
- IggleSniggle 7y ago
  I like your analogy, but I think it's a little off. HTML/CSS/JS are "Java" and React/Angular are "Spring." I love writing vanilla js, but the problem that the frameworks are really solving for is stripping away the history of HTML/CSS/JS for a 'document oriented web' and present a "re-abstraction" for an crossplatform 'application oriented web' that just happens to live in the most dominant VM platform (the browser). In the analogy, Assembly is WebAssembly, and C is C. We just don't have the frameworks and libraries written for them yet! --- Edit: ...but yeah you're right it's Svelte. Although I hear that Angular also compiles down to something pretty "close to the metal" these days.
Scarbutt 7y ago
Turbonlinks is a decent compromise for many sites.
- hfourm 7y ago
  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.
arpowers 7y ago
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"
- hinkley 7y ago
  Yes, but when the framework continues to grow 100kb release after release we blame the person who uses it for doing so. If you don't like it, stop using it. You can't win, and there will always be a developer ready and willing to kick you while you're down.
- lhorie 7y ago
  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.
  - 7y ago
mrighele 7y ago
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
naranha 7y ago
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 7y ago
  Aren't those usually cached? Page reloads these days are fast.
  - avens19 7y ago
    They said parse which is true regardless of caching
    - deleted 7y ago
      [deleted]
    - goatlover 7y ago
      The JS parsing would be less.
  - nitsky 7y ago
    Yeah, parsing of megabytes of CSS and JS is not necessary on each page load, but you still need a round trip to a server on each interaction, and a full page of HTML, even if only a small part of it has changed.
    - hinkley 7y ago
      And then the Phoenix (Elixir) framework introduces LiveView in 2020... If you haven't already figured out, everything old is new again. This was an old pattern when someone taught it to me at my first job. It felt like it wasn't happening for a few years but only because everything was new to me. Then I started seeing people win arguments arguing for the things that we had just finished replacing, and the most I've ever seen since is brief respites as the pendulum approaches the apex on each swing.
commandlinefan 7y ago
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 7y ago
  Ironically, the standard and nicer API that was jQuery’s value proposition has mostly already arrived in browsers.
  - horsawlarway 7y ago
    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 7y ago
      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 7y ago
        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.
- wolco 7y ago
  angularjs gives you something no other framework has. Two way binding. Change a variable in the frontend the backend changes. Change it in the backend the frontend changes.
horsawlarway 7y ago
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 7y ago
  So basically we're getting shit slow apps as users because they're cheap to make. As a user I thank you.
  - claytongulick 7y ago
    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 7y ago
      90% of the cases... yes, it would be better.
aardvark1 7y ago
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 7y ago
  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 7y ago
    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.
irrational 7y ago
Am I reading this right? Of the frameworks studied, Vue consistently has the best numbers by far?
- IshKebab 7y ago
  You can't really draw any conclusions from any of this because of selection bias.
- rk06 7y ago
  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 7y ago
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.
petulla 7y ago
Would be interesting to see this normalized by say DOM elements per page. Also Svelte and other lean bundle approaches should be included.
seph-reed 7y ago
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 7y ago
  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.
  - jimmyspice 7y ago
    where can I read more about SDx? never heard of that term before
    - seph-reed 7y ago
      EDIT: I made a really simple demo of SDx. It's missing all of the features for nicer syntax, better performance (derivation batching), and garbage collection features (avoiding direct references). You also can't run derivers inside of derivers. But it gets the idea across. https://codepen.io/SephReed/pen/gOaeQLv?editors=1010 https://codepen.io/SephReed/pen/gOaeQLv?editors=1010 -------- I made it up, but MobX has some rudimentary implementations of it: https://mobx.js.org/README.html https://mobx.js.org/README.html
      - jimmyspice 7y ago
        Thanks, that's a pretty cool demo with almost no code. Seems like a lightweight observable as you say.
galaxyLogic 7y ago
What about browser-cache? Doesn't it solve this problem to a large extend?
keb_ 7y ago
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.
up2you 7y ago
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
austincheney 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      Hum... Are you candidating yourself?
      - austincheney 7y ago
        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.
leke 7y ago
I'm loving React at the moment, but I'm also learning Svelte for this very reason too.
deleted 7y ago
[deleted]

154 points by elorant 7y ago

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 7y ago
See the footnotes. https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/#footnote-1 https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
- hyperpape 7y ago
  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?

tengbretson 7y ago

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 7y ago
There is: http://todomvc.com/ http://todomvc.com/
- guntars 7y ago
  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/vanilla-es6/src/view.js https://github.com/tastejs/todomvc/blob/gh-pages/examples/va...
  - chrisco255 7y ago
    Yeah, this is what web dev was like before these frameworks came about (except web standards were worse 8 years ago). If you're building a complex application with more than 2 or 3 devs, a framework is a must.
  - itronitron 7y ago
    That looks like fairly standard code for defining UI behavior in native frameworks as well, it's not particularly nightmarish.
  - karatestomp 7y ago
    ... what's so bad about it?
    - guntars 7y ago
      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.
jordache 7y ago
grouping feature set complexity is going to be subjective exercise as well. A randomly sampling is better.

a13n 7y ago

> 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.

jordache 7y ago
Isn't relative comparison they key point here? Absolutes doesn't mean much
tkadlec 7y ago
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.)

lukifer 7y ago

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?

deleted 7y ago
[deleted]
flowerlad 7y ago
How about these libs: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/
g_delgado14 7y ago
Well with wasm, this analogy doesn't really make much sense.
- thephyber 7y ago
  wasm doesn’t have the ability to access the DOM, which is the majority of the purpose of JS in the browser.
- lukifer 7y ago
  It is a very very loose analogy ;)
IggleSniggle 7y ago
I like your analogy, but I think it's a little off. HTML/CSS/JS are "Java" and React/Angular are "Spring." I love writing vanilla js, but the problem that the frameworks are really solving for is stripping away the history of HTML/CSS/JS for a 'document oriented web' and present a "re-abstraction" for an crossplatform 'application oriented web' that just happens to live in the most dominant VM platform (the browser). In the analogy, Assembly is WebAssembly, and C is C. We just don't have the frameworks and libraries written for them yet! --- Edit: ...but yeah you're right it's Svelte. Although I hear that Angular also compiles down to something pretty "close to the metal" these days.

Scarbutt 7y ago

Turbonlinks is a decent compromise for many sites.

hfourm 7y ago
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.

arpowers 7y ago

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"

hinkley 7y ago
Yes, but when the framework continues to grow 100kb release after release we blame the person who uses it for doing so. If you don't like it, stop using it. You can't win, and there will always be a developer ready and willing to kick you while you're down.
lhorie 7y ago
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.
- 7y ago

mrighele 7y ago

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

naranha 7y ago

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 7y ago
Aren't those usually cached? Page reloads these days are fast.
- avens19 7y ago
  They said parse which is true regardless of caching
  - deleted 7y ago
    [deleted]
  - goatlover 7y ago
    The JS parsing would be less.
- nitsky 7y ago
  Yeah, parsing of megabytes of CSS and JS is not necessary on each page load, but you still need a round trip to a server on each interaction, and a full page of HTML, even if only a small part of it has changed.
  - hinkley 7y ago
    And then the Phoenix (Elixir) framework introduces LiveView in 2020... If you haven't already figured out, everything old is new again. This was an old pattern when someone taught it to me at my first job. It felt like it wasn't happening for a few years but only because everything was new to me. Then I started seeing people win arguments arguing for the things that we had just finished replacing, and the most I've ever seen since is brief respites as the pendulum approaches the apex on each swing.

commandlinefan 7y ago

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 7y ago
Ironically, the standard and nicer API that was jQuery’s value proposition has mostly already arrived in browsers.
- horsawlarway 7y ago
  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 7y ago
    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 7y ago
      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.
wolco 7y ago
angularjs gives you something no other framework has. Two way binding. Change a variable in the frontend the backend changes. Change it in the backend the frontend changes.

horsawlarway 7y ago

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 7y ago
So basically we're getting shit slow apps as users because they're cheap to make. As a user I thank you.
- claytongulick 7y ago
  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 7y ago
    90% of the cases... yes, it would be better.

aardvark1 7y ago

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 7y ago
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 7y ago
  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.

irrational 7y ago

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

IshKebab 7y ago
You can't really draw any conclusions from any of this because of selection bias.
rk06 7y ago
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 7y ago

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.

petulla 7y ago

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

seph-reed 7y ago

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 7y ago
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.
- jimmyspice 7y ago
  where can I read more about SDx? never heard of that term before
  - seph-reed 7y ago
    EDIT: I made a really simple demo of SDx. It's missing all of the features for nicer syntax, better performance (derivation batching), and garbage collection features (avoiding direct references). You also can't run derivers inside of derivers. But it gets the idea across. https://codepen.io/SephReed/pen/gOaeQLv?editors=1010 https://codepen.io/SephReed/pen/gOaeQLv?editors=1010 -------- I made it up, but MobX has some rudimentary implementations of it: https://mobx.js.org/README.html https://mobx.js.org/README.html
    - jimmyspice 7y ago
      Thanks, that's a pretty cool demo with almost no code. Seems like a lightweight observable as you say.

galaxyLogic 7y ago

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

keb_ 7y ago

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.

up2you 7y ago

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

austincheney 7y ago

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 7y ago
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 7y ago
  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 7y ago
    Hum... Are you candidating yourself?
    - austincheney 7y ago
      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.

leke 7y ago

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

deleted 7y ago

[deleted]