19 ms·

The Baseline Costs of JavaScript Frameworks

221 points by GeneralMaximus 8y ago

Battochon 8y ago
This person doesn't know a thing about Angular and he is benchmarking it?! Angular is not loading the whole RxJS and I doubt AOT was setted properly. This is a misleading paper again. I would like that 3 experts on each framework do their best to provide the same app and then we could compare.
- deleted 8y ago
  [deleted]
- copperx 8y ago
  This isn't a research paper.
shaunpersad 8y ago
> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it Weren't your assets deployed on Netlify's CDN? Shouldn't that make location roughly irrelevant (assuming enough PoPs)?
- ht85 8y ago
  He's referring to the typical phone performance (parse and execute) and network bandwidth for an Indian user, not the network latency.
fold_left 8y ago
Damn, Svelte is not on there. I'd be curious what the author thinks to it as an approach https://svelte.technology/ https://svelte.technology/
- nailer 8y ago
  I was about to say, this is precisely the reason Svelte exists. I rewrote my personal site in it a year ago [1], and the development experience was similar to a Vue or Ractive app, but with compilation (ie, the resulting webpage doesn't have Svelte included - it's just my app specifically compiled) the result was tiny. [1] https://mikemaccana.com https://mikemaccana.com, probably has a lot of small bugs since I spent my time working on more important things.
  - KaoruAoiShiho 8y ago
    Couldn't SSR with later JS hydration be just as effective at getting instant startup?
    - nailer 8y ago
      Svelte also does SSR (if you set it up, which I haven't bothered), but you don't have to pull down a whole framework, so the hydration step is much faster.
      - KaoruAoiShiho 8y ago
        Right, but with SSR the other frameworks basically have no downside. Their loading is also instant. A 1 second long hydration is not a big deal.
        nailer 8y ago
        1000ms hydration may be a big deal, hydration may also take more than 1000ms.
        KaoruAoiShiho 8y ago
        What matters to people is the content loading and being able to see the page. For the majority of apps the hydration is almost irrelevant because the time it takes to read the page and decide to interact with it takes vastly more than 1000ms, though there could be exceptions. It's certainly the case for all the apps I've worked on.
hayksaakian 8y ago
That's assuming you don't do any server side rendering right? I can send completely readable html over the wire that becomes interactive once the JS finishes loading. What am I missing.
- dancek 8y ago
  The days of work needed to set up server-side rendering? I realize I must look stupid saying this, because when you know your tech stack inside out the setup might be 15 minutes instead of days. But a large proportion of developers only learn to do things when they have to, and so you learn server side rendering the first time you have a customer willing to pay for the time it takes you to learn.
  - EpicEng 8y ago
    And conversely they would also have to learn these JS frameworks, right? Something like Angular is far harder to master (and debug) then server side rendering.
    - dancek 8y ago
      Of course, but time is limited and there's a huge number of things to learn. So my point about a customer paying the cost of learning SSR may be moot, but someone has to pay it. I also assume the ease of implementing SSR is highly dependent on the backend tech stack. My guess is that only Node.js makes it relatively easy.
  - tboyd47 8y ago
    "SSR" is the default behavior of most pre-2016 web frameworks. Only when ReactJS became hip did it appear on lists of nice-to-haves that people weigh the pros and cons of.
    - dancek 8y ago
      Yes, I'm talking in the context of SPA frameworks (which the article referred to).
55555 8y ago
I used to write all my static sites using Hugo, until I saw a site that was built using Gatsby. Gatsby has a larger overhead on the initial page load but feels much faster and subsequent page loads have less overhead (or maybe more, if it's prefetching a lot of adjacent pages which you'll never navigate to). It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby. This would be the ideal if we're optimizing for perceived latency. So the first page load is fast, then as long as you stay on that page for a second or two before clicking elsewhere, everything after that point will be snappy too. Ofcourse, many other devs are optimizing for network usage, etc, so to each their own.
- prophesi 8y ago
  You can attain Gatsby's SPA feel/speed with Hugo, via Turbolinks[0]. A much smaller overhead on initial page load, and you can hook up a service worker to do any prefetching/caching. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  - 55555 8y ago
    Awesome, thank you. I dislike working with Gatsby and much preferred Hugo. But what about prefetching?
    - prophesi 8y ago
      From my experience, it seems like you'd have to jump through a few hoops to get prefetching working with Turbolinks. I just relied on having my service worker do all of the prefetching/caching of the site's important pages + static assets.
- IggleSniggle 8y ago
  Nuxt handles this issue nicely imho.
  - 8y ago
maxfurman 8y ago
I'm not surprised that Angular ships a larger bundle than React and Vue, it intentionally covers a much larger surface area of functionality. But Angular also includes build tools meant to reduce the size of the final bundle - can anyone tell if those were used in this comparison?
- jamamp 8y ago
  Yes, his Angular page [0] uses AoT compilation which results in the bundle, instead of individual files by default (meant for development only). Also I agree with you. It's a bit unfair to be comparing a barebones Angular app to a barebones React/Vue app (even with a router library for each of those). Angular also has a forms and validation library already installed, and its dependency injection framework, etc. The baseline React/Vue apps don't have those pre-installed, which you would typically install when building an actual app. [0] https://angular-ngrx-router.netlify.com/ https://angular-ngrx-router.netlify.com/
  - Drdrdrq 8y ago
    That's kind of the point though, right? If you don't need forms, can you remove them in Angular? While we're on the subject, does anyone know a good forms and validation library for React? :-)
    - ghego1 8y ago
      Yes you can
    - pbedat 8y ago
      react-final-form simply blew my mind after I had to deal with that horrible reactive angular forms... It also works pretty well in tandem with redux
    - zbuttram 8y ago
      For React forms and validation the combo of Formik and Yup is quite nice. Formik takes a schema prop specifically for integration with Yup, it's covered in the docs. https://github.com/jaredpalmer/formik https://github.com/jaredpalmer/formik https://github.com/jquense/yup https://github.com/jquense/yup
hn_throwaway_99 8y ago
The main conclusion from this article isn't accurate. This is one reason to load common libraries from a known CDN so that if any website has downloaded that library version previously, and the user's cache has not been cleared or expired, the next time that library can just be loaded from cache, even if from a different website.
- nexensis 8y ago
  That's fine for jQuery, Bootstrap etc, however most modern frameworks are bundled into a single package with all of the templates and logic, making a shared CDN useless. It would be interesting to see some benchmarks of a cached CDN Angular file and non-cached template/logic file, however lots of other sites would have to jump on board to get the cached file into users' browsers reliably.
- robin_reala 8y ago
  Historically that was a major security issue. It’s less of an issue now that SRI exists (you’re using SRI, right?), but it’s still a problem when you have a broken pathway to the CDN but your site loads OK. Well, assuming you’re not building with progressive enhancement. You’re building with progressive enhancement right?
  - hleszek 8y ago
    sorry what is SRI ?
    - robin_reala 8y ago
      Subresource Integrity. It’s designed specifically for this scenario: a resource included into your page from a seperate server that could potentially be compromised. Your hash the known good resource and include that hash in your script or link tags as an integrity attribute. When the user’s browser downloads the resource it’ll hash it again and check for a match. Only if the two match will it parse and execute the contents. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Bahamut 8y ago
One thing it should be noted with Angular is that there is currently work on a new renderer that should allow framework bundle size to be optimized with the whole framework being tree-shakeable. I wonder how Angular would compare once that is done, as this has long been known as probably the main negative with Angular performance-wise, the initial load (but it should be faster than most of the rest once it does load).
- coding123 8y ago
  Really faster than react? Having a hard time with that one...
  - equasar 8y ago
    No sure if it could be faster than react but you can check what is accomplishing by reading this: https://www.telerik.com/blogs/first-look-angular-ivy https://www.telerik.com/blogs/first-look-angular-ivy Or watching this: https://www.youtube.com/watch?v=dIxknqPOWms&feature=youtu.be&t=22m37s https://www.youtube.com/watch?v=dIxknqPOWms&feature=youtu.be...
  - Bahamut 8y ago
    For all numbers excepting initial load, everything I've seen shows Angular is significantly faster than the rest - the difference is more pronounced with more DOM nodes. Angular also has the advantage of incremental update, although React will also gain that benefit within a year as well. Note: I used to work primarily with Angular, but I currently use React since the coding style encouraged with React works better with the team I'm on & React is fast enough to us.
    - deleted 8y ago
      [deleted]
    - ralfn 8y ago
      >everything I've seen shows Angular is significantly faster than the rest That contradicts every published test. It is also hard to imagine. Angular is both reading and writing the DOM. And i haven't touched it after they switched to a new version, but in the old version they noticed state changes by contiously comparing all of your state. (so more state meant it would be slower). I'm assuming they switched to a more native implementation of the observable pattern in the newer version, rather than that pathetic hack. Of course neither React or Angular are as fast as hand written code. Since, what both take responsibility away from the developer. In the case of React: don't worry about what you need to update, just re-render the whole thing again. Simpler code, and the performance price you pay for it is somewhat limited because it then diffes a virtual dom. Angular's approach, annotating HTML however, simply reinforces what we learned later: that is was written by someone with absolute no experience as a front-end developer. Because performance wise it's about the dumbest thing you could do. Every time you switch from writing to the DOM, to reading the DOM you force the browser to do another layout&paint and for all of that to happen synchronously, instead of the concurrent model that modern browsers actually offer. What has happened is that these frameworks have become the new platforms. People don't realize that everything from online chess games to google maps isn't written using these frameworks and it's questionable any of them could do that with good enough performance. At our company when recruiting we now distinguish actual front-end developers from angular or react developers. They may know these frameworks, that does not imply they could write them or understand enough of front-end development in general to debug actual cross browser issues, performance issues or rendering issues. And we give them a test that requires building something complicated in pure html/css/js.
monsieurbanana 8y ago
> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it What about cache? In that 1.1s figure, 0.9s are for the download of react. Is it reasonable to assume that for most subsequent loads the website would load in 0.2s?
- pjmlp 8y ago
  HTTPS everywhere kills caches, in the sense that only end devices can provide them, but other network nodes not. Check Eric Meyer's complaints.
  - iaml 8y ago
    Does it also affect caching via service workers? Pretty standard practice in PWAs.
    - pjmlp 8y ago
      No, but it impacts the initial download as it needs to be end to end, instead of the closest access point. Also a very good way to waste traffic quota, e.g. a school network connection vs students computers.
      - pythonaut_16 8y ago
        Which interestingly is a problem IPFS would solve, right? But IPFS potentially introduces other drawbacks. It would be cool to able to build dual-distribution applications, where publicly available assets and content blobs (e.g. app.js) could be distributed in an immutable, cache-able manner, and server interactions and private assets could still be handled in a more traditional client/server way. Perhaps then we might even be able to realize the original intent of including dependencies from a CDN, being able to share a cached version of React across websites. (I'm not and IPFS advocate or detractor)
    - judah 8y ago
      No, HTTP caching and PWA web worker caching works fine. (In fact, web workers require HTTPS to even function.) Eric Meyer's "HTTPS busts caching" complaint refers not to HTTP or web worker caching, but man-in-the-middle local servers caching responses. It sits between the internet and your local box, and serves cached requests. This breaks with HTTPS, which is designed to break man-in-the-middle attacks.
monkeynotes 8y ago
Comparing a barebones view layer libraries (Vue, React etc.) with full frameworks (Angular, Ember etc.) is not comparing apples to apples.
- ilovecaching 8y ago
  I'm assuming you didn't read the article? He was comparing react + redux + react-router using create-react-app compared to Angular. So it is an apples to apples comparison.
  - kevindqc 8y ago
    Yay, it's comparing apples to pears!
  - monkeynotes 8y ago
    Even if you add redux and react-router you still don't have feature parity. The comparison is inherently arbitrary. All I really know from his experiment is if I load up a feature rich framework vs. a bare-bones view+route+state combo the framework is going to be heavier. Is that really news?
- schwap 8y ago
  > Methodology: > ... > 2. Installed routing and data management libraries in each project, and made sure they were part of the JavaScript bundle.
KaoruAoiShiho 8y ago
He's not using SSR which is wrong in 2018. Vue's startup performance will also supposedly double in the next version. Looking forward to that.
- wishinghand 8y ago
  Do you mean halve? That's what I took away from the twitter post by the creator Evan You.
  - KaoruAoiShiho 8y ago
    Performance double, time halve. I think my comment was fine.
superkuh 8y ago
>Or consider not using a framework at all. For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts. This should be the takeaway from the article. There's absolutely no need for javascript on most websites that use javascript. I understand if you're forced into it by the time and economic contingencies of your work but if you bring JS frameworks home to your personal sites you're doing it wrong.
- StreamBright 8y ago
  Exactly. I avoid JS as much as possible. Unfortunately most of web developers want to develop SPAs regardless of the actual need of the projects.
  - snaky 8y ago
    SPA building experience, coupled with popular JS frameworks, sells usually better than the skills of carefully engineering solution for the task.
    - maxxxxx 8y ago
      Resume driven development works. Unfortunately.
    - gedy 8y ago
      These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, and ability to test, share and modularize suffers. SPAs usually are better engineered UIs than the alternatives.
      - malvosenior 8y ago
        The backend has to handle all of the scale. That's where the real difficult engineering comes in and if you're using JS there, you're going to pay a huge price. It doesn't seem like many front-end JS developers understand that pulling data from different places isn't actually a hard problem but instead correctly storing and managing that data at scale is where the actual engineering happens.
austincheney 8y ago
> Truth is, when you build your application on top of a modern JavaScript framework, you agree to pay a certain baseline performance cost that can never be optimized away. In exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime. All of that is completely subjective except for that final bit about runtime performance. I bet nobody can prove runtime performance improves in correlation with layers of abstraction.
- snaky 8y ago
  It depends. ML or ATS code can perform faster than hand-written C code, despite the fact both MLton and ATS compilers actually generate C code, effectively adding the layers of abstractions. And you can have the verification for free also. > We introduce a new approach for implementing cryptographic arithmetic in short high-level code with machine-checked proofs of functional correctness. We further demonstrate that simple partial evaluation is sufficient to transform into the fastest-known C code, breaking the decades-old pattern that the only fast implementations are those whose instruction-level steps were written out by hand. http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP19.pdf http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...
  - austincheney 8y ago
    Compiler output isn't an abstraction. It's what is ultimately executed where the compiler's source sample is not. For an apples to apples comparison I am claiming the code compiled from a framework is going to be slower than well written code without a framework. I am also claiming you well be painfully challenged to prove otherwise. Frameworks don't exist to make code faster. They exist to provide an abstraction layer.
vdnkh 8y ago
Please stop using gzip size for these sorts of comparisons. One, gzip affects download speed, but not JS evaluation and compilation. Two, it makes the libraries seem much smaller than they actually are.
- jefftk 8y ago
  > One, gzip affects download speed, but not JS evaluation and compilation They measured scripting time directly, which is a much better measurement than uncompressed bytes. > Two, it makes the libraries seem much smaller than they actually are Would you prefer they gave unminified sizes as well? The gzipped size of a library lets us predict how long it will take to download, and how much that will cost for users.
- erikpukinskis 8y ago
  Raw file size is meaningless though. For example, if I use long variable names I will have a bigger source file. But with gzip it wouldn’t affect anything at all. You can think of gripped size as a rough measure of the actual information in a file, as opposed to file size which is largely meaningless in a networked environment.
- deleted 8y ago
  [deleted]
- Roboprog 8y ago
  https://en.m.wikipedia.org/wiki/BREACH https://en.m.wikipedia.org/wiki/BREACH Assume you have an app, rather than a site. Your app has a login Your password is not sent in clear-text, your server uses HTTPS for all its traffic. You probably don’t want to use compression, then.
ivanhoe 8y ago
To better make sense of this data it needs to be compared against the time needed to build a non-trivial interface using each of the frameworks.
- 10-6 8y ago
  This is exactly right. A lot of posts regarding loading times or bundle sizes for frameworks/libraries forget that there are trade-offs when it comes to building an application. The correct way to frame this is: use a slow/clunky/large/etc framework vs. build everything from scratch (which comes with its own costs). Sure, you can optimize parts of your application to speed up the JS portion or even remote it completely [1], but it's not always as simple as "your framework is making your application slow so you should think about ditching it." This article actually ends with a very reasonable conclusion in the section "Are Frameworks Evil?" but I've seen plenty of articles where the author doesn't offer an alternative to some library/framework [2]. [1] https://twitter.com/netflixuie/status/923374215041912833?lang=en https://twitter.com/netflixuie/status/923374215041912833?lan... [2] https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-framework-3g24 https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-framewo...
arendtio 8y ago
I wonder how much bootup time Ember.js takes nowadays. I mean, a few years back Ember was probably the worst when it came to initial loading times (it has other strengths), but I heard it got better over the years.
neya 8y ago
It's simple. Don't use frameworks for content consumption. It adds no value to the end user. No, I don't need your full fledged my-data-sucking SPA just to read an article on your site. Keep it simple. The best example? https://www.react.rocks https://www.react.rocks is a site built on react to advocate people to use React. This is how it looks like without JS. https://webcache.googleusercontent.com/search?q=cache:WRll6h8NQc8J:https://react.rocks/example/react-chrome-redux+&cd=6&hl=en&ct=clnk https://webcache.googleusercontent.com/search?q=cache:WRll6h... A site built on React to advocate React doesn't serve its primary purpose. The irony.
- enlyth 8y ago
  I don't understand your complaint here. Your issue is that a site written with a JS framework doesn't load without JS? The HN anti-JS brigade will never cease to amaze me. You think the 0.001% of people who browse with JS disabled are the primary target for such a website?
  - ebcode 8y ago
    >You think the 0.001% of people who browse with JS disabled are the primary target for such a website? Because you obviously grabbed this number out of thin air, I would like the HN community to know that the actual percentage of users without JS is much closer to 1%[0]. [0] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
    - wafflesraccoon 8y ago
      Do you have any updated sources? This data is from 2013.
      - ebcode 8y ago
        No I don't, unfortunately. But I imagine that this figure will be fairly stable for the foreseeable future. There are always going to be people with disabilities who turn off JavaScript for accessibility reasons, and privacy-conscious individuals and corporations that have it disabled. I think the parent comment's exaggeration of the number is bad form for web developers, and goes against the spirit of the web, which I believe is based on the principles of universal access and inclusiveness.
innocentoldguy 8y ago
Of all the client-side JavaScript libraries available for making responsive web applications, I've found that Elm suits me best. I haven't done any benchmarks, but it feels faster than React and Angular to me and the Elm compiler eliminates virtually all runtime issues before I ever deploy my code. Another alternative to large client-side libraries I've been looking at lately is Phoenix's LiveView. It is a server-side rendering library that uses web sockets. I've only just started using LiveView, but so far my pages seem to perform better than React or Angular.
- RobertKerans 8y ago
  Given Live View was only announced two months ago, is in development, and hasn't been released in any form whatsoever, I'm curious as to how you've managed to use it to make that comparison?
  - innocentoldguy 8y ago
    Duh! Sorry, I meant Drab. I had LiveView on the brain. You can check it out here: https://tg.pl/drab https://tg.pl/drab
StillBored 8y ago
As a US based user of an A53 based phone, where I use firefox. I'm here to tell you more than 50% of the sites I visit with it (HN being one that actually works well) are completely unusable. There was a saying back in the 1990's that developers should be forced to use obsolete hardware to assure that their software was usable for the regular user, and its even more true today. Developers running around with the latest iphones does nothing to actually represent what the average user actually sees. Picking on amazon, I generally don't even bother going to their site unless i'm on my desktop, where I can physically watch them frequently spike my 4+ Ghz CPU for a few seconds when I type in the search bar, or click a page. Doing the same on my phone or cheap tablet frequently results in a 10+ second waits. The other day I was typing on my tablet and the amazon search completion was literally taking 20+ seconds to display each _character_ and a completion list for it.
- hinkley 8y ago
  My first job I had a machine so slow I could see the screen updates progress. For several months I did perf testing with a stop watch because changes would knock off so much time. Two places I worked, I intercepted someone trying to throw out old computers and set up a testing station at an empty cube or a table on an endcap. Usually with some older versions of browsers. They didn’t get used every day but they got used most weeks for sure.
- paraditedc 8y ago
  And this is the first time I heard someone complain Amazon UI being slow. And Amazon sales or stock are not dropping. Probably you are not part of the 99% of users that Amazon is targeting.
  - StillBored 8y ago
    Well there are others https://www.reddit.com/r/amazon/comments/38tttx/why_is_amazons_website_so_godawfully_slow https://www.reddit.com/r/amazon/comments/38tttx/why_is_amazo... And its weird because the landing page tends to be fairly fast, but if you happen to be signed in, and start clicking around you can see it load the page and then spend another few seconds loading/running a bunch of crap in the background. Once its done that a couple times it just seems to get progressively slower. Although, I suspect a big part of the problem is firefox... As far as their target audience, you might be right WRT their target users tending to be more affluent and having high end phones/etc. But event then, at this point, what are the retail alternatives with such a wide range of products, particularly if one does enough online shopping to have a prime membership and also use it as a netflix substitute?
kmitz 8y ago
It doesn't mention framework versions..
mLuby 8y ago
This isn't about JS frameworks, it's about rendering data on page load. Whether the server renders the data into HTML it responds with or there's some XHR request made by a client library (including VanillaJS) or framework, you're always incurring some cost. But data-on-load what users generally want and expect from modern web apps. Having recently built an almost 100% HTML-based web app, I can tell you the user interactions feel unpleasant. Removing JS from web apps is silly at this point.
commandlinefan 8y ago
> Frameworks exist for a reason. People keep saying that...
yuribit 8y ago
A nice way to improve the time-to-interactive is to prefetch the framework after you load an initial basic page. Here's Addy Osmani explaining how it works: https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9 https://medium.com/dev-channel/a-netflix-web-performance-cas...
- hinkley 8y ago
  Used that on my first Ajax app. It was authenticated so we pruned the JS on the login page like crazy and added a script that injected the main bundle into the page after page ready. Worked great for everybody not using a password manager...
jorblumesea 8y ago
Not using server side rendering, not using a cdn or some form of caching. Not sure this is a good test of anything other than how to fail at implementing SPAs.
agentPrefect 8y ago
> in exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime. You also gain responsiveness to user interactions, a programmatic way to reason about your application/website & and some animation-sugar if you want. Don't throw the baby out with the bath water simply because people follow trends instead of good design practices.
- Roboprog 8y ago
  And in my case, less Java I have to read or write on the back end :-) I agree, though - it’s much easier to reason about the data integrity and security when there is a smaller code base on the back end, by virtue of splitting user interface concerns off to a front end code base. I’ve been programming since the 80s, but I’d rather write FP code in JS than OOP code in Java - so long as I’m not doing anything to make the app work badly for people. So I’ve gravitated towards front end work the last 3 years or so. Another rant for another time...
paraditedc 8y ago
I am surprised by the fact that author completely ignores client side caching using browser and service worker, as well as SSR. One key point of PWA is that it works offline and loads faster after after first load (even after you deploy new changes, with basic service worker configs from sw-precache). So you need 1 second for first load only. Subsequent loads are much faster.
rinchik 8y ago
Why would you compare React/Vue vs Angular??? I don't think the author understands the difference between frameworks and libraries. React vs Vue can be a valid analysis, same as Angular vs Ember. It's silly to benchmark React/Vue vs Angular/Ember. Lets create a benchmark of ponies vs zebras/horses!
- wuliwong 8y ago
  Seems pretty clear they understand the difference judging by what was written in the article.
  - rinchik 8y ago
    Do they though? have you read the article? Medium says its a 5min read. 5min of a completely wasted time. Btw its says right here that react is not a framework https://reactjs.org/ https://reactjs.org/. Always amazed how people calling themselves "engineers" while being unable to grasp such simple, basic nuances.
astockwell 8y ago
I'm the only person on my current team (an internally-focused engineering team) who has experience building websites/apps for external paying clients (e.g. people who will freak out if anything fails to load faster than they can blink, on their phone's 3G connection). I was taken aback by how many times I had to argue with my team, our sister teams, our consultants/contractors, and even our (non-technical) leadership about NOT building a SPA when we came across 1 form in our large codebase that required some extra interactivity. For some reason many developers seem to be fine turning a blind eye to the actual page-rendering time, maybe because it's hard to benchmark with tools? (although I'm skeptical of that). I find an overlap however in that those same developers seem to not understand why multiple database query roundtrips are worse than 1 query followed by some in-memory munging. I'm sure I'm biased by my background, where we were profiling like mad, doing crazy things like purposely modifying images/hand-building sprites to pack better, minifying CSS before SASS/LESS existed, and every millisecond to finish rendering mattered. Good times.
- politician 8y ago
  What I find funny about this comment is that your experience of being a flabbergasted subject matter expert is basically the same for every SME in any domain on your team, your sister teams, etc. I've been there too. It's rare to find developers who've deeply specialized in multiple different domains.
- paraditedc 8y ago
  Really depends on what is your product and how users use it. If the user just visit a few pages every time, you probably don't need SPA. However, if your website has hundreds of pages and users need to navigate around a lot, SPA would actually reduce load time by cutting down the amount of data being transferred over network every time users goes to a different page. It also makes the experience navigating between pages smoother.
  - gondo 8y ago
    browser cache solves this problem
btbuildem 8y ago
Including megabytes of unrelated .gifs in the blog post kind of undermines the point here...
- wuliwong 8y ago
  I don't agree. Those gifs are explicitly added. The author's point is about load times that are relatively unavoidable.
lioeters 8y ago
This is why I'm a happy user of Preact - the core feature set of React minus the bloat. Especially with some recent additions to React (context, hooks) which I don't have any need for, I'm glad to stay with the smaller surface area of Preact instead.
- brlewis 8y ago
  Preact is the most React-like small framework, probably the best for your resume and for hiring people who want a good resume. Mithril is the small framework that most directly addresses the issues brought up in this article. It has routing built in and comes with a small streams library that, for apps I work on, is all the state management I need. For those who really love JSX, Inferno is a really clean, small React-like framework. Its advantage over Mithril is that JSX expressions evaluate to components, not vnodes, so your HOC code will be slightly cleaner.
underwater 8y ago
> If you want your application to become interactive on your users’ devices in under 5 seconds, can you afford to spend a fifth of that time just booting up React? If you care about load time you should pick a framework because of the value it brings, rather than what it costs. That one second overhead might make your application code twice as efficient. For example Next.js and React will give you route based bundle splitting and navigation preloading for free. Yes, a vanilla JS app could implement the same, but requires a lot more boilerplate to achieve. So in practice most devs are more likely to skip that part and their lightweight no-framework app becomes a bloated mess.
- conanbatt 8y ago
  I switched a classical html stack to a next.js app and although the first page load is definitely lagging, the speed gains of inter-page navigation is incredible. People navigate 70 pages within a couple of minutes. Definitely worth it for many modern-day usages.
spankalee 8y ago
This is why obsoleting frameworks by expanding the native component model of the web is good for the world.
- zanny 8y ago
  I'm really loving just casually writing websites for Rust web frameworks because I get to try out all these new tricks in html / css / ecma7 to avoid pulling in any third party libraries. Then you get goodies like compile time templates and regexes while having only 30ms from initial request to tls handshake to routing, request handling, response and rendering all done (on the same network).
nikkwong 8y ago
Tangental, but it's frustrating creating a website and optimizing it for performance down to the bone; and then having 'mission critical' plugins totally rip the potential performance gains to shreds. My ecommerce site [0] (built on a custom stack, not shopify; making it orders of magnitude faster). I got it down to 600kb with 27 network requests total (with it being heavily media/image based). Now find me any other ecommerce site which can boast a comparable network payload. Unfortunately, after throwing google analytics + fb ad trackers + a chat widget + a youtube video, the network requests have ballooned to 100+. It's very ironic how these companies promote the development a performance driven web, but the tools they want us to embed do quite the contrary. They do, however, offer a lot of value. What to do? [0] — www.getfractals.com
- spullara 8y ago
  Your site is still really fast compared with almost all ecommerce sites. I built the backend for a friend of mine's blog and I always use it as an example of how fast the web could be but yours might be a more impressive example: https://www.lukew.com https://www.lukew.com
  - nikkwong 8y ago
    Thank you kindly! The site you have attached is also rocket speed! CMS's like shopify offer great value, and are a great starting place even for technical folks. However I think the lack of prioritization they've placed on the performance of sites on their platform has overall been a net negative for e-commerce at large. The mobile experience of most shopify stores is usually atrocious and the inclination to bounce before page load is all too real. I understand they are working with an old stack, and changing course may be nigh impossible at this point. However, I built my stack in 2014, and the dividends of doing something custom vs the status quo have more than paid off.
  - whitepoplar 8y ago
    Check out http://changelog.com http://changelog.com for an example of a fast (it's the fastest site I've ever used) site that's rendered server-side without any of the SPA madness. It's open source, built on Phoenix and makes good use of Turbolinks. (https://changelog.com/posts/why-we-chose-turbolinks https://changelog.com/posts/why-we-chose-turbolinks)

This person doesn't know a thing about Angular and he is benchmarking it?! Angular is not loading the whole RxJS and I doubt AOT was setted properly. This is a misleading paper again. I would like that 3 experts on each framework do their best to provide the same app and then we could compare.

deleted 8y ago
[deleted]
copperx 8y ago
This isn't a research paper.

shaunpersad 8y ago

> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it Weren't your assets deployed on Netlify's CDN? Shouldn't that make location roughly irrelevant (assuming enough PoPs)?

ht85 8y ago
He's referring to the typical phone performance (parse and execute) and network bandwidth for an Indian user, not the network latency.

fold_left 8y ago

Damn, Svelte is not on there. I'd be curious what the author thinks to it as an approach https://svelte.technology/ https://svelte.technology/

nailer 8y ago
I was about to say, this is precisely the reason Svelte exists. I rewrote my personal site in it a year ago [1], and the development experience was similar to a Vue or Ractive app, but with compilation (ie, the resulting webpage doesn't have Svelte included - it's just my app specifically compiled) the result was tiny. [1] https://mikemaccana.com https://mikemaccana.com, probably has a lot of small bugs since I spent my time working on more important things.
- KaoruAoiShiho 8y ago
  Couldn't SSR with later JS hydration be just as effective at getting instant startup?
  - nailer 8y ago
    Svelte also does SSR (if you set it up, which I haven't bothered), but you don't have to pull down a whole framework, so the hydration step is much faster.
    - KaoruAoiShiho 8y ago
      Right, but with SSR the other frameworks basically have no downside. Their loading is also instant. A 1 second long hydration is not a big deal.
      - nailer 8y ago
        1000ms hydration may be a big deal, hydration may also take more than 1000ms.
        KaoruAoiShiho 8y ago
        What matters to people is the content loading and being able to see the page. For the majority of apps the hydration is almost irrelevant because the time it takes to read the page and decide to interact with it takes vastly more than 1000ms, though there could be exceptions. It's certainly the case for all the apps I've worked on.

hayksaakian 8y ago

That's assuming you don't do any server side rendering right? I can send completely readable html over the wire that becomes interactive once the JS finishes loading. What am I missing.

dancek 8y ago
The days of work needed to set up server-side rendering? I realize I must look stupid saying this, because when you know your tech stack inside out the setup might be 15 minutes instead of days. But a large proportion of developers only learn to do things when they have to, and so you learn server side rendering the first time you have a customer willing to pay for the time it takes you to learn.
- EpicEng 8y ago
  And conversely they would also have to learn these JS frameworks, right? Something like Angular is far harder to master (and debug) then server side rendering.
  - dancek 8y ago
    Of course, but time is limited and there's a huge number of things to learn. So my point about a customer paying the cost of learning SSR may be moot, but someone has to pay it. I also assume the ease of implementing SSR is highly dependent on the backend tech stack. My guess is that only Node.js makes it relatively easy.
- tboyd47 8y ago
  "SSR" is the default behavior of most pre-2016 web frameworks. Only when ReactJS became hip did it appear on lists of nice-to-haves that people weigh the pros and cons of.
  - dancek 8y ago
    Yes, I'm talking in the context of SPA frameworks (which the article referred to).

55555 8y ago

I used to write all my static sites using Hugo, until I saw a site that was built using Gatsby. Gatsby has a larger overhead on the initial page load but feels much faster and subsequent page loads have less overhead (or maybe more, if it's prefetching a lot of adjacent pages which you'll never navigate to). It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby. This would be the ideal if we're optimizing for perceived latency. So the first page load is fast, then as long as you stay on that page for a second or two before clicking elsewhere, everything after that point will be snappy too. Ofcourse, many other devs are optimizing for network usage, etc, so to each their own.

prophesi 8y ago
You can attain Gatsby's SPA feel/speed with Hugo, via Turbolinks[0]. A much smaller overhead on initial page load, and you can hook up a service worker to do any prefetching/caching. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
- 55555 8y ago
  Awesome, thank you. I dislike working with Gatsby and much preferred Hugo. But what about prefetching?
  - prophesi 8y ago
    From my experience, it seems like you'd have to jump through a few hoops to get prefetching working with Turbolinks. I just relied on having my service worker do all of the prefetching/caching of the site's important pages + static assets.
IggleSniggle 8y ago
Nuxt handles this issue nicely imho.
- 8y ago

maxfurman 8y ago

I'm not surprised that Angular ships a larger bundle than React and Vue, it intentionally covers a much larger surface area of functionality. But Angular also includes build tools meant to reduce the size of the final bundle - can anyone tell if those were used in this comparison?

jamamp 8y ago
Yes, his Angular page [0] uses AoT compilation which results in the bundle, instead of individual files by default (meant for development only). Also I agree with you. It's a bit unfair to be comparing a barebones Angular app to a barebones React/Vue app (even with a router library for each of those). Angular also has a forms and validation library already installed, and its dependency injection framework, etc. The baseline React/Vue apps don't have those pre-installed, which you would typically install when building an actual app. [0] https://angular-ngrx-router.netlify.com/ https://angular-ngrx-router.netlify.com/
- Drdrdrq 8y ago
  That's kind of the point though, right? If you don't need forms, can you remove them in Angular? While we're on the subject, does anyone know a good forms and validation library for React? :-)
  - ghego1 8y ago
    Yes you can
  - pbedat 8y ago
    react-final-form simply blew my mind after I had to deal with that horrible reactive angular forms... It also works pretty well in tandem with redux
  - zbuttram 8y ago
    For React forms and validation the combo of Formik and Yup is quite nice. Formik takes a schema prop specifically for integration with Yup, it's covered in the docs. https://github.com/jaredpalmer/formik https://github.com/jaredpalmer/formik https://github.com/jquense/yup https://github.com/jquense/yup

hn_throwaway_99 8y ago

The main conclusion from this article isn't accurate. This is one reason to load common libraries from a known CDN so that if any website has downloaded that library version previously, and the user's cache has not been cleared or expired, the next time that library can just be loaded from cache, even if from a different website.

nexensis 8y ago
That's fine for jQuery, Bootstrap etc, however most modern frameworks are bundled into a single package with all of the templates and logic, making a shared CDN useless. It would be interesting to see some benchmarks of a cached CDN Angular file and non-cached template/logic file, however lots of other sites would have to jump on board to get the cached file into users' browsers reliably.
robin_reala 8y ago
Historically that was a major security issue. It’s less of an issue now that SRI exists (you’re using SRI, right?), but it’s still a problem when you have a broken pathway to the CDN but your site loads OK. Well, assuming you’re not building with progressive enhancement. You’re building with progressive enhancement right?
- hleszek 8y ago
  sorry what is SRI ?
  - robin_reala 8y ago
    Subresource Integrity. It’s designed specifically for this scenario: a resource included into your page from a seperate server that could potentially be compromised. Your hash the known good resource and include that hash in your script or link tags as an integrity attribute. When the user’s browser downloads the resource it’ll hash it again and check for a match. Only if the two match will it parse and execute the contents. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Bahamut 8y ago

One thing it should be noted with Angular is that there is currently work on a new renderer that should allow framework bundle size to be optimized with the whole framework being tree-shakeable. I wonder how Angular would compare once that is done, as this has long been known as probably the main negative with Angular performance-wise, the initial load (but it should be faster than most of the rest once it does load).

coding123 8y ago
Really faster than react? Having a hard time with that one...
- equasar 8y ago
  No sure if it could be faster than react but you can check what is accomplishing by reading this: https://www.telerik.com/blogs/first-look-angular-ivy https://www.telerik.com/blogs/first-look-angular-ivy Or watching this: https://www.youtube.com/watch?v=dIxknqPOWms&feature=youtu.be&t=22m37s https://www.youtube.com/watch?v=dIxknqPOWms&feature=youtu.be...
- Bahamut 8y ago
  For all numbers excepting initial load, everything I've seen shows Angular is significantly faster than the rest - the difference is more pronounced with more DOM nodes. Angular also has the advantage of incremental update, although React will also gain that benefit within a year as well. Note: I used to work primarily with Angular, but I currently use React since the coding style encouraged with React works better with the team I'm on & React is fast enough to us.
  - deleted 8y ago
    [deleted]
  - ralfn 8y ago
    >everything I've seen shows Angular is significantly faster than the rest That contradicts every published test. It is also hard to imagine. Angular is both reading and writing the DOM. And i haven't touched it after they switched to a new version, but in the old version they noticed state changes by contiously comparing all of your state. (so more state meant it would be slower). I'm assuming they switched to a more native implementation of the observable pattern in the newer version, rather than that pathetic hack. Of course neither React or Angular are as fast as hand written code. Since, what both take responsibility away from the developer. In the case of React: don't worry about what you need to update, just re-render the whole thing again. Simpler code, and the performance price you pay for it is somewhat limited because it then diffes a virtual dom. Angular's approach, annotating HTML however, simply reinforces what we learned later: that is was written by someone with absolute no experience as a front-end developer. Because performance wise it's about the dumbest thing you could do. Every time you switch from writing to the DOM, to reading the DOM you force the browser to do another layout&paint and for all of that to happen synchronously, instead of the concurrent model that modern browsers actually offer. What has happened is that these frameworks have become the new platforms. People don't realize that everything from online chess games to google maps isn't written using these frameworks and it's questionable any of them could do that with good enough performance. At our company when recruiting we now distinguish actual front-end developers from angular or react developers. They may know these frameworks, that does not imply they could write them or understand enough of front-end development in general to debug actual cross browser issues, performance issues or rendering issues. And we give them a test that requires building something complicated in pure html/css/js.

monsieurbanana 8y ago

> your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it What about cache? In that 1.1s figure, 0.9s are for the download of react. Is it reasonable to assume that for most subsequent loads the website would load in 0.2s?

pjmlp 8y ago
HTTPS everywhere kills caches, in the sense that only end devices can provide them, but other network nodes not. Check Eric Meyer's complaints.
- iaml 8y ago
  Does it also affect caching via service workers? Pretty standard practice in PWAs.
  - pjmlp 8y ago
    No, but it impacts the initial download as it needs to be end to end, instead of the closest access point. Also a very good way to waste traffic quota, e.g. a school network connection vs students computers.
    - pythonaut_16 8y ago
      Which interestingly is a problem IPFS would solve, right? But IPFS potentially introduces other drawbacks. It would be cool to able to build dual-distribution applications, where publicly available assets and content blobs (e.g. app.js) could be distributed in an immutable, cache-able manner, and server interactions and private assets could still be handled in a more traditional client/server way. Perhaps then we might even be able to realize the original intent of including dependencies from a CDN, being able to share a cached version of React across websites. (I'm not and IPFS advocate or detractor)
  - judah 8y ago
    No, HTTP caching and PWA web worker caching works fine. (In fact, web workers require HTTPS to even function.) Eric Meyer's "HTTPS busts caching" complaint refers not to HTTP or web worker caching, but man-in-the-middle local servers caching responses. It sits between the internet and your local box, and serves cached requests. This breaks with HTTPS, which is designed to break man-in-the-middle attacks.

monkeynotes 8y ago

Comparing a barebones view layer libraries (Vue, React etc.) with full frameworks (Angular, Ember etc.) is not comparing apples to apples.

ilovecaching 8y ago
I'm assuming you didn't read the article? He was comparing react + redux + react-router using create-react-app compared to Angular. So it is an apples to apples comparison.
- kevindqc 8y ago
  Yay, it's comparing apples to pears!
- monkeynotes 8y ago
  Even if you add redux and react-router you still don't have feature parity. The comparison is inherently arbitrary. All I really know from his experiment is if I load up a feature rich framework vs. a bare-bones view+route+state combo the framework is going to be heavier. Is that really news?
schwap 8y ago
> Methodology: > ... > 2. Installed routing and data management libraries in each project, and made sure they were part of the JavaScript bundle.

KaoruAoiShiho 8y ago

He's not using SSR which is wrong in 2018. Vue's startup performance will also supposedly double in the next version. Looking forward to that.

wishinghand 8y ago
Do you mean halve? That's what I took away from the twitter post by the creator Evan You.
- KaoruAoiShiho 8y ago
  Performance double, time halve. I think my comment was fine.

superkuh 8y ago

>Or consider not using a framework at all. For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts. This should be the takeaway from the article. There's absolutely no need for javascript on most websites that use javascript. I understand if you're forced into it by the time and economic contingencies of your work but if you bring JS frameworks home to your personal sites you're doing it wrong.

StreamBright 8y ago
Exactly. I avoid JS as much as possible. Unfortunately most of web developers want to develop SPAs regardless of the actual need of the projects.
- snaky 8y ago
  SPA building experience, coupled with popular JS frameworks, sells usually better than the skills of carefully engineering solution for the task.
  - maxxxxx 8y ago
    Resume driven development works. Unfortunately.
  - gedy 8y ago
    These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, and ability to test, share and modularize suffers. SPAs usually are better engineered UIs than the alternatives.
    - malvosenior 8y ago
      The backend has to handle all of the scale. That's where the real difficult engineering comes in and if you're using JS there, you're going to pay a huge price. It doesn't seem like many front-end JS developers understand that pulling data from different places isn't actually a hard problem but instead correctly storing and managing that data at scale is where the actual engineering happens.

austincheney 8y ago

> Truth is, when you build your application on top of a modern JavaScript framework, you agree to pay a certain baseline performance cost that can never be optimized away. In exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime. All of that is completely subjective except for that final bit about runtime performance. I bet nobody can prove runtime performance improves in correlation with layers of abstraction.

snaky 8y ago
It depends. ML or ATS code can perform faster than hand-written C code, despite the fact both MLton and ATS compilers actually generate C code, effectively adding the layers of abstractions. And you can have the verification for free also. > We introduce a new approach for implementing cryptographic arithmetic in short high-level code with machine-checked proofs of functional correctness. We further demonstrate that simple partial evaluation is sufficient to transform into the fastest-known C code, breaking the decades-old pattern that the only fast implementations are those whose instruction-level steps were written out by hand. http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP19.pdf http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...
- austincheney 8y ago
  Compiler output isn't an abstraction. It's what is ultimately executed where the compiler's source sample is not. For an apples to apples comparison I am claiming the code compiled from a framework is going to be slower than well written code without a framework. I am also claiming you well be painfully challenged to prove otherwise. Frameworks don't exist to make code faster. They exist to provide an abstraction layer.

vdnkh 8y ago

Please stop using gzip size for these sorts of comparisons. One, gzip affects download speed, but not JS evaluation and compilation. Two, it makes the libraries seem much smaller than they actually are.

jefftk 8y ago
> One, gzip affects download speed, but not JS evaluation and compilation They measured scripting time directly, which is a much better measurement than uncompressed bytes. > Two, it makes the libraries seem much smaller than they actually are Would you prefer they gave unminified sizes as well? The gzipped size of a library lets us predict how long it will take to download, and how much that will cost for users.
erikpukinskis 8y ago
Raw file size is meaningless though. For example, if I use long variable names I will have a bigger source file. But with gzip it wouldn’t affect anything at all. You can think of gripped size as a rough measure of the actual information in a file, as opposed to file size which is largely meaningless in a networked environment.
deleted 8y ago
[deleted]
Roboprog 8y ago
https://en.m.wikipedia.org/wiki/BREACH https://en.m.wikipedia.org/wiki/BREACH Assume you have an app, rather than a site. Your app has a login Your password is not sent in clear-text, your server uses HTTPS for all its traffic. You probably don’t want to use compression, then.

ivanhoe 8y ago

To better make sense of this data it needs to be compared against the time needed to build a non-trivial interface using each of the frameworks.

10-6 8y ago
This is exactly right. A lot of posts regarding loading times or bundle sizes for frameworks/libraries forget that there are trade-offs when it comes to building an application. The correct way to frame this is: use a slow/clunky/large/etc framework vs. build everything from scratch (which comes with its own costs). Sure, you can optimize parts of your application to speed up the JS portion or even remote it completely [1], but it's not always as simple as "your framework is making your application slow so you should think about ditching it." This article actually ends with a very reasonable conclusion in the section "Are Frameworks Evil?" but I've seen plenty of articles where the author doesn't offer an alternative to some library/framework [2]. [1] https://twitter.com/netflixuie/status/923374215041912833?lang=en https://twitter.com/netflixuie/status/923374215041912833?lan... [2] https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-framework-3g24 https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-framewo...

arendtio 8y ago

I wonder how much bootup time Ember.js takes nowadays. I mean, a few years back Ember was probably the worst when it came to initial loading times (it has other strengths), but I heard it got better over the years.

neya 8y ago

It's simple. Don't use frameworks for content consumption. It adds no value to the end user. No, I don't need your full fledged my-data-sucking SPA just to read an article on your site. Keep it simple. The best example? https://www.react.rocks https://www.react.rocks is a site built on react to advocate people to use React. This is how it looks like without JS. https://webcache.googleusercontent.com/search?q=cache:WRll6h8NQc8J:https://react.rocks/example/react-chrome-redux+&cd=6&hl=en&ct=clnk https://webcache.googleusercontent.com/search?q=cache:WRll6h... A site built on React to advocate React doesn't serve its primary purpose. The irony.

enlyth 8y ago
I don't understand your complaint here. Your issue is that a site written with a JS framework doesn't load without JS? The HN anti-JS brigade will never cease to amaze me. You think the 0.001% of people who browse with JS disabled are the primary target for such a website?
- ebcode 8y ago
  >You think the 0.001% of people who browse with JS disabled are the primary target for such a website? Because you obviously grabbed this number out of thin air, I would like the HN community to know that the actual percentage of users without JS is much closer to 1%[0]. [0] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
  - wafflesraccoon 8y ago
    Do you have any updated sources? This data is from 2013.
    - ebcode 8y ago
      No I don't, unfortunately. But I imagine that this figure will be fairly stable for the foreseeable future. There are always going to be people with disabilities who turn off JavaScript for accessibility reasons, and privacy-conscious individuals and corporations that have it disabled. I think the parent comment's exaggeration of the number is bad form for web developers, and goes against the spirit of the web, which I believe is based on the principles of universal access and inclusiveness.

innocentoldguy 8y ago

Of all the client-side JavaScript libraries available for making responsive web applications, I've found that Elm suits me best. I haven't done any benchmarks, but it feels faster than React and Angular to me and the Elm compiler eliminates virtually all runtime issues before I ever deploy my code. Another alternative to large client-side libraries I've been looking at lately is Phoenix's LiveView. It is a server-side rendering library that uses web sockets. I've only just started using LiveView, but so far my pages seem to perform better than React or Angular.

RobertKerans 8y ago
Given Live View was only announced two months ago, is in development, and hasn't been released in any form whatsoever, I'm curious as to how you've managed to use it to make that comparison?
- innocentoldguy 8y ago
  Duh! Sorry, I meant Drab. I had LiveView on the brain. You can check it out here: https://tg.pl/drab https://tg.pl/drab

StillBored 8y ago

As a US based user of an A53 based phone, where I use firefox. I'm here to tell you more than 50% of the sites I visit with it (HN being one that actually works well) are completely unusable. There was a saying back in the 1990's that developers should be forced to use obsolete hardware to assure that their software was usable for the regular user, and its even more true today. Developers running around with the latest iphones does nothing to actually represent what the average user actually sees. Picking on amazon, I generally don't even bother going to their site unless i'm on my desktop, where I can physically watch them frequently spike my 4+ Ghz CPU for a few seconds when I type in the search bar, or click a page. Doing the same on my phone or cheap tablet frequently results in a 10+ second waits. The other day I was typing on my tablet and the amazon search completion was literally taking 20+ seconds to display each _character_ and a completion list for it.

hinkley 8y ago
My first job I had a machine so slow I could see the screen updates progress. For several months I did perf testing with a stop watch because changes would knock off so much time. Two places I worked, I intercepted someone trying to throw out old computers and set up a testing station at an empty cube or a table on an endcap. Usually with some older versions of browsers. They didn’t get used every day but they got used most weeks for sure.
paraditedc 8y ago
And this is the first time I heard someone complain Amazon UI being slow. And Amazon sales or stock are not dropping. Probably you are not part of the 99% of users that Amazon is targeting.
- StillBored 8y ago
  Well there are others https://www.reddit.com/r/amazon/comments/38tttx/why_is_amazons_website_so_godawfully_slow https://www.reddit.com/r/amazon/comments/38tttx/why_is_amazo... And its weird because the landing page tends to be fairly fast, but if you happen to be signed in, and start clicking around you can see it load the page and then spend another few seconds loading/running a bunch of crap in the background. Once its done that a couple times it just seems to get progressively slower. Although, I suspect a big part of the problem is firefox... As far as their target audience, you might be right WRT their target users tending to be more affluent and having high end phones/etc. But event then, at this point, what are the retail alternatives with such a wide range of products, particularly if one does enough online shopping to have a prime membership and also use it as a netflix substitute?

kmitz 8y ago

It doesn't mention framework versions..

mLuby 8y ago

This isn't about JS frameworks, it's about rendering data on page load. Whether the server renders the data into HTML it responds with or there's some XHR request made by a client library (including VanillaJS) or framework, you're always incurring some cost. But data-on-load what users generally want and expect from modern web apps. Having recently built an almost 100% HTML-based web app, I can tell you the user interactions feel unpleasant. Removing JS from web apps is silly at this point.

commandlinefan 8y ago

> Frameworks exist for a reason. People keep saying that...

yuribit 8y ago

A nice way to improve the time-to-interactive is to prefetch the framework after you load an initial basic page. Here's Addy Osmani explaining how it works: https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9 https://medium.com/dev-channel/a-netflix-web-performance-cas...

hinkley 8y ago
Used that on my first Ajax app. It was authenticated so we pruned the JS on the login page like crazy and added a script that injected the main bundle into the page after page ready. Worked great for everybody not using a password manager...

jorblumesea 8y ago

Not using server side rendering, not using a cdn or some form of caching. Not sure this is a good test of anything other than how to fail at implementing SPAs.

agentPrefect 8y ago

> in exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime. You also gain responsiveness to user interactions, a programmatic way to reason about your application/website & and some animation-sugar if you want. Don't throw the baby out with the bath water simply because people follow trends instead of good design practices.

Roboprog 8y ago
And in my case, less Java I have to read or write on the back end :-) I agree, though - it’s much easier to reason about the data integrity and security when there is a smaller code base on the back end, by virtue of splitting user interface concerns off to a front end code base. I’ve been programming since the 80s, but I’d rather write FP code in JS than OOP code in Java - so long as I’m not doing anything to make the app work badly for people. So I’ve gravitated towards front end work the last 3 years or so. Another rant for another time...

paraditedc 8y ago

I am surprised by the fact that author completely ignores client side caching using browser and service worker, as well as SSR. One key point of PWA is that it works offline and loads faster after after first load (even after you deploy new changes, with basic service worker configs from sw-precache). So you need 1 second for first load only. Subsequent loads are much faster.

rinchik 8y ago

Why would you compare React/Vue vs Angular??? I don't think the author understands the difference between frameworks and libraries. React vs Vue can be a valid analysis, same as Angular vs Ember. It's silly to benchmark React/Vue vs Angular/Ember. Lets create a benchmark of ponies vs zebras/horses!

wuliwong 8y ago
Seems pretty clear they understand the difference judging by what was written in the article.
- rinchik 8y ago
  Do they though? have you read the article? Medium says its a 5min read. 5min of a completely wasted time. Btw its says right here that react is not a framework https://reactjs.org/ https://reactjs.org/. Always amazed how people calling themselves "engineers" while being unable to grasp such simple, basic nuances.

astockwell 8y ago

I'm the only person on my current team (an internally-focused engineering team) who has experience building websites/apps for external paying clients (e.g. people who will freak out if anything fails to load faster than they can blink, on their phone's 3G connection). I was taken aback by how many times I had to argue with my team, our sister teams, our consultants/contractors, and even our (non-technical) leadership about NOT building a SPA when we came across 1 form in our large codebase that required some extra interactivity. For some reason many developers seem to be fine turning a blind eye to the actual page-rendering time, maybe because it's hard to benchmark with tools? (although I'm skeptical of that). I find an overlap however in that those same developers seem to not understand why multiple database query roundtrips are worse than 1 query followed by some in-memory munging. I'm sure I'm biased by my background, where we were profiling like mad, doing crazy things like purposely modifying images/hand-building sprites to pack better, minifying CSS before SASS/LESS existed, and every millisecond to finish rendering mattered. Good times.

politician 8y ago
What I find funny about this comment is that your experience of being a flabbergasted subject matter expert is basically the same for every SME in any domain on your team, your sister teams, etc. I've been there too. It's rare to find developers who've deeply specialized in multiple different domains.
paraditedc 8y ago
Really depends on what is your product and how users use it. If the user just visit a few pages every time, you probably don't need SPA. However, if your website has hundreds of pages and users need to navigate around a lot, SPA would actually reduce load time by cutting down the amount of data being transferred over network every time users goes to a different page. It also makes the experience navigating between pages smoother.
- gondo 8y ago
  browser cache solves this problem

btbuildem 8y ago

Including megabytes of unrelated .gifs in the blog post kind of undermines the point here...

wuliwong 8y ago
I don't agree. Those gifs are explicitly added. The author's point is about load times that are relatively unavoidable.

lioeters 8y ago

This is why I'm a happy user of Preact - the core feature set of React minus the bloat. Especially with some recent additions to React (context, hooks) which I don't have any need for, I'm glad to stay with the smaller surface area of Preact instead.

brlewis 8y ago
Preact is the most React-like small framework, probably the best for your resume and for hiring people who want a good resume. Mithril is the small framework that most directly addresses the issues brought up in this article. It has routing built in and comes with a small streams library that, for apps I work on, is all the state management I need. For those who really love JSX, Inferno is a really clean, small React-like framework. Its advantage over Mithril is that JSX expressions evaluate to components, not vnodes, so your HOC code will be slightly cleaner.

underwater 8y ago

> If you want your application to become interactive on your users’ devices in under 5 seconds, can you afford to spend a fifth of that time just booting up React? If you care about load time you should pick a framework because of the value it brings, rather than what it costs. That one second overhead might make your application code twice as efficient. For example Next.js and React will give you route based bundle splitting and navigation preloading for free. Yes, a vanilla JS app could implement the same, but requires a lot more boilerplate to achieve. So in practice most devs are more likely to skip that part and their lightweight no-framework app becomes a bloated mess.

conanbatt 8y ago
I switched a classical html stack to a next.js app and although the first page load is definitely lagging, the speed gains of inter-page navigation is incredible. People navigate 70 pages within a couple of minutes. Definitely worth it for many modern-day usages.

spankalee 8y ago

This is why obsoleting frameworks by expanding the native component model of the web is good for the world.

zanny 8y ago
I'm really loving just casually writing websites for Rust web frameworks because I get to try out all these new tricks in html / css / ecma7 to avoid pulling in any third party libraries. Then you get goodies like compile time templates and regexes while having only 30ms from initial request to tls handshake to routing, request handling, response and rendering all done (on the same network).

nikkwong 8y ago

Tangental, but it's frustrating creating a website and optimizing it for performance down to the bone; and then having 'mission critical' plugins totally rip the potential performance gains to shreds. My ecommerce site [0] (built on a custom stack, not shopify; making it orders of magnitude faster). I got it down to 600kb with 27 network requests total (with it being heavily media/image based). Now find me any other ecommerce site which can boast a comparable network payload. Unfortunately, after throwing google analytics + fb ad trackers + a chat widget + a youtube video, the network requests have ballooned to 100+. It's very ironic how these companies promote the development a performance driven web, but the tools they want us to embed do quite the contrary. They do, however, offer a lot of value. What to do? [0] — www.getfractals.com

spullara 8y ago
Your site is still really fast compared with almost all ecommerce sites. I built the backend for a friend of mine's blog and I always use it as an example of how fast the web could be but yours might be a more impressive example: https://www.lukew.com https://www.lukew.com
- nikkwong 8y ago
  Thank you kindly! The site you have attached is also rocket speed! CMS's like shopify offer great value, and are a great starting place even for technical folks. However I think the lack of prioritization they've placed on the performance of sites on their platform has overall been a net negative for e-commerce at large. The mobile experience of most shopify stores is usually atrocious and the inclination to bounce before page load is all too real. I understand they are working with an old stack, and changing course may be nigh impossible at this point. However, I built my stack in 2014, and the dividends of doing something custom vs the status quo have more than paid off.
- whitepoplar 8y ago
  Check out http://changelog.com http://changelog.com for an example of a fast (it's the fastest site I've ever used) site that's rendered server-side without any of the SPA madness. It's open source, built on Phoenix and makes good use of Turbolinks. (https://changelog.com/posts/why-we-chose-turbolinks https://changelog.com/posts/why-we-chose-turbolinks)