10 ms·

The Cost of JavaScript

177 points by shawndumas 9y ago

pasta 9y ago
It's not the cost of Javascript. It's the cost of shipping the latest trend as fast as possible by throwing in another lib that has all the options you will use 1% of. This is happening everywhere. And this is also why we are wasting so much time waiting for that page or program to load. It's a nice article but isn't this something that should be so obvious for the avarge programmer?
- Waterluvian 9y ago
  As a programmer I know all this. But I don't articulate as well as Addy. So He's given me a fantastic link to share with the non-programmers above me.
- SippinLean 9y ago
  This is covered in the article >Removing unused code
  - Chyzwar 9y ago
    Nope. it is about including stuff that you really need. I saw apps that where shipping angular + jquery just to provide a single interactive icon. Article focus on very specific cases of the mobile web application. In most SPA it is not a big deal to ship a 1mb of JS.
    - SippinLean 9y ago
      They specifically mention tree-shaking and tools to strip unused code from libraries.
      - Chyzwar 9y ago
        Read my answer more carefully. It is about using frameworks when you really need it. A lot of people include dependencies to their projects that can be avoided by better knowing JS and Web APIs.
- symlinkk 9y ago
  It's happening because when you search for a job you get posting after posting that calls for experience with specific JavaScript frameworks. "Looking for a React ninja". "Looking for an Angular hacker". So programmers push for using those frameworks even on projects that don't necessarily call for them, so they can pad their resume and keep up with the ridiculous churn of frontend JS development. This is the advantage of working with a platform like iOS - there is one framework to make UI's and that's all you need to know for your entire career. Yes, the framework upgrades and changes, but you don't have to learn a completely new paradigm to change the contents of a text box for the hundredth time.
smacktoward 9y ago
This is one of the biggest things I have found remarkable about the modern Web: how slow everything feels. Nothing just loads anymore! Instead everything loads in dribs and drabs, as various bits of it stream down to the device, get parsed and get rendered. I waste so much time staring at placeholder graphics and missing clicks because the element I was aiming at skidded across the page after something else popped in. The more front-end technology we throw at the Web, the worse it seems to get. It's hard to remember that once upon a time Web pages were fast, even though we were viewing them on 1990s-era hardware that even today's budget mobile devices put to shame. We love the Web so much we are strangling it to death.
- rhizome 9y ago
  I've been paying attention to how slow the web is these days, and just as often as not I can finish a newspaper article (by far the worst offenders in 3rd Party API callouts) before the tab's page-loading indicator completes.
  - JustSomeNobody 9y ago
    If it completes at all!
- bitwize 9y ago
  > We love the Web so much we are strangling it to death. "And I'm gonna hug 'im and squeeze 'im and name 'im George..."
- jandrese 9y ago
  This is one of the reasons I use noscript. By blocking those dozens of calls to external trackers/ad networks/etc... you can significantly reduce the time between clicking the link and the page being readable.
sirjaz 9y ago
This is why the webbrowser was not built for every little thing. We as programmers need to get back to writing applications and use the web more as a data stream. Thus letting the app do all the rendering ahead of time and we are just refreshing the data
- draw_down 9y ago
  > This is why the webbrowser was not built for every little thing. Fortunately, software is changeable :)
- LolNoGenerics 9y ago
  Well, average desktop app size exploded too.
- pjmlp 9y ago
  Yes, the browser should be kept for HTML / CSS, and maybe some JavaScript for interactive documents.
PerryCox 9y ago
We live in a world where everyone wants to make Electron apps instead of doing anything in a compiled language or anything other than JavaScript really. Maybe it's because I've never been a webdev but I just don't understand the fascination with JavaScript. Personally I hate JavaScript any time I have to code in it. Give me literally any other language.
- bpicolo 9y ago
  Electron isn't great just because it runs javascript, it's great because you get to use the HTML/CSS you're used to making pretty UIs with to make pretty desktop UIs. HTML/CSS have their warts, but they're a fantastically efficient way to build out UIs.
  - megaman22 9y ago
    So instead of running WinForms or Qt or GTK or, god help us, Swing, components in a tight, snappy desktop app, we're mostly running Bootstrap components in a webview. Six of one, half-dozen of the other, in my book. The Stockholm syndrome around using browser technology everywhere, just because you've been brutalized into learning its wrinkles to work on the web, is scary.
    - greggman 9y ago
      having built both native and electron my experience is it's an order of magnitude faster to use electron to ship on win/Mac/Linux than any native tech clone this repo, follow steps at bottom of readme, ship on 3 platforms https://github.com/greggman/electron-hello-world https://github.com/greggman/electron-hello-world
      - jarjoura 9y ago
        Every single platform has their 1-line hello world example. iOS has storyboards, Windows has XAML, Linux has QT components. If all you need is an action button to trigger some underlying code, then those hello-world products are very simple. Electron is NOT that easy to use of a platform. In fact, it's quite technical and requires a lot of knowledge about node and HTML/CSS. It requires that the developer understand you're running a node process that feeds its results to a browser that has a native chrome. Visual Studio Code and Slack for example have native plugins that light-up the various platform's features. So you're never completely guarded from having to write native code. At the end of the day it's just another UI toolkit and language choice you can make when building out your software.
lcfcjs2 9y ago
I can almost spell the Old Spice in this thread.
setzer22 9y ago
I feel the web is so much faster on my phone since I started using brave and blocking all js by default. It's surprising how many pages load just fine with no javascript. Most HN articles do.
megamindbrian2 9y ago
I use AOT in dev mode.
bo1024 9y ago
Nice article, especially the data, but I'm disappointed they didn't cover more of the most effective approach: Design your site not to use javascript except where really needed! I think most sites can be broadly classified as (1) "relatively static" such as hackernews itself, news/blogs, text-based sites in general, or (2) an entire program/application running in the browser, such as a game or collaborative text editor. Most sites fall into category 1 and therefore need very little JS to do their job effectively, but they come up with 50 different things for JS to do on their webpage, then spend time and effort optimizing and minifying instead of just not doing those things (or doing them in HTML).
- Scarbutt 9y ago
  You are thinking only on two extremes, between a news/blogs and game/collaborative text editor there a thousands of web apps that don't fit the two. What would you call webapp for generating and keeping track of invoices?
  - the_gastropod 9y ago
    While it's possible I'm not understanding some important aspect of invoice generation, I don't believe JavaScript is necessary for this process... Plain HTML form inputs -> Server -> Generate PDF? What am I missing? Why's JavaScript required here? I think we forget that the web was a pretty productive thing even before JavaScript was widely used. GMail existed (and still does) in a javascript-free form. You can even use Google Maps without JavaScript. Granted, JavaScript enhances both experiences, but it's not strictly required.
    - Scarbutt 9y ago
      Granted, JavaScript enhances both experiences, but it's not strictly required. Yep, Javascript is not strictly required but that was what I was trying to refer to, the enhancement part. A blog or news site like HN doesn't really need much enhancements, a web app for invoices lends itself to be way more interactive than HN. In your gmail example, the HTML version doesn't have: Chat Spell checker Keyboard shortcuts Adding or importing contacts Custom "from" addresses Rich formatting
diminish 9y ago
I had a chance to hack through the new contributor interface for a leading stock photo seller after UX has become erroneous and extremely slow after an update last week. They switched from an under-invested front end interface to a React/Redux for submitting images. I was thinking that maybe the implementation was bad but I concluded that the React/Redux and the set of front end components were to blame. Go read react/redux websites with dozens of cool ideas leading to a user revolt. Didn't we learn something from J2EE technologies that complexity is the source of all evil?
- acemarke 9y ago
  Hi, I'm a Redux maintainer. Can you give some more details on the issues you saw? What concerns do you have about using React and Redux?
  - diminish 9y ago
    Thx for the kind offer. There's a list view where I select one or many video/image cards, and edit their titles, tags, descriptions in a single edit box singly or multiple. It's not about media editing, just their titles, tags and dozens of other data. Redux store contains all 200 image information as well as undo history. Here's the issue - when I put there 200 things to edit, the screen becomes very slow to use. Like the mere act of selecting and having its title/description etc appear on an edit box is 2 seconds. I have installed redux and react dev tools out of curiosity to understand what's happening. My conclusion, is that over 200 images to submit in batch combined with the undoable complex data store can't be handled. So I went to examine redux website and source code - which appears quite thin and performant. At the end I think react gets slow to update 200 cards from the complex store after redux store gets updated. I currently don't have some things to submit otherwise I would post some animated screenshots. But next time I have I can post a github issue and pls let me know what kind of data I must include from to react dev tools for performance check.
    - acemarke 9y ago
      Yeah, at first glance, I wouldn't _think_ that storing, displaying, and tracking selection for those items would be having performance issues, but obviously it depends on the actual code. My React/Redux links list has a large section of articles on measure and improving perf in React and Redux apps [0]. You might want to look through some of those. Also, my "Practical Redux" tutorial series [1] has some posts that talk about perf behavior, including key Redux perf concerns, and ways to buffer form input change events [0] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [1] http://blog.isquaredsoftware.com/series/practical-redux/ http://blog.isquaredsoftware.com/series/practical-redux/
deleted 9y ago
[deleted]
saas_co_de 9y ago
> adopt a Performance Budget for ensuring your team are able to keep an eye on their JavaScript costs. This is really good advice for product people.
jeeberz 9y ago
Anyone here deploy ES2015+ or know of any large sites that do?
bunderbunder 9y ago
This phenomenon seems like an almost inevitable symptom of another thing companies do, this one completely understandable: Making sure the dev team has nice equipment to work with. If we're always working with reasonably high-end kit, it impairs our ability to empathize with the experience of someone who's using a cheap Chromebook or the "free" phone. Contrast with a previous place I worked, where the team that was building in-house tools worked on hand-me-down equipment from their end users. That's a shop where the users almost never had to complain about poor UI performance.
codinghorror 9y ago
Pay attention to how much slower all the Android devices are here, whereas iPhone has long since reached laptop parity. So depressing how bad Qualcomm hardware is.
hobofan 9y ago
Not a hardcore JS-dev, but two things I noticed as someone who has optimized their JS output before: - I am surprised that this blog post advertises webpack tree-shaking, as it is completely broken right now, and has been for a year[0] - More and more people are switching to date-fns[1] from moment.js, since it is much smaller and composable by default, and works better with tree-shaking in rollup (or webpack once it's fixed). Yes, their recommendation of ContextReplacementPlugin is valid, but in the case of moment.js, its probably better to just use a replacement. [0] https://github.com/webpack/webpack/issues/2867 https://github.com/webpack/webpack/issues/2867 [1] https://github.com/date-fns/date-fns https://github.com/date-fns/date-fns
- jeeberz 9y ago
  Angular 5 has been using the webpack ModuleConcatenationPlugin to reduce bundle sizes by half. It does Rollup-like scope hoisting. Google for "angular build optimizer".
godot 9y ago
Every time one of these JS-related posts come up (especially performance-related ones), I find interesting the seemingly huge disconnect between the JS-hating audience of HN and the actual silicon valley corporate/startup world where heavy-JS/React/SPA is everything. Let me begin by stating that I'm not hating on either side of the fence -- I've been on both sides (and arguably, I still am on both sides, if that were possible). As someone who works on a lot of side projects, I can very easily see the argument of keeping web sites JS-light, and not even dive into all the React stuff. Most projects don't necessarily call for it except for certain very specific things. (I actually do not use React on any side projects of mine, and still stick with jQuery.) On the other hand, after having joined a JS-fullstack startup this year, I can see that an article like this one is completely speaking to me/us. All I can say is, without the giant background context of working on a monolithic fullstack JS codebase, none of it makes sense; but when you're in such a job, everything of it makes sense.
- tjoff 9y ago
  "everything of it makes sense" No it doesn't. Because you are obviously not implementing something that is meant to be used by a human being. That load times are measured in multiple seconds even on a 4G phone is mind boggling.
  - godot 9y ago
    You don't have to be combative. I agree with you. The article is advocating for JS developers to be aware of what makes their SPA react JS app heavy and load slowly. I'm saying that an article like this only makes sense when you have the full context behind working on a SPA react JS mono codebase. If you haven't worked on one, it all sounds like gibberish and your mind just goes off to wonder "why even build this heavy react JS app to begin with when you could build a site without JS".
- ng12 9y ago
  I think it's so weird that many people on HN can't fathom a website being more complex than Medium. I've spent the last 5+ years doing nothing but develop data-heavy visualization apps. The alternative is not building a website without JS, it's building a desktop application using Swing or QT.
vdnkh 9y ago
I wrote this [1] guide on how to reduce the size of your JS bundles via transpiler optimizations. There's a lot you can do to write code which results in less boilerplate from your toolchain. It also covers code splitting via webpack and some other goodies (like evaulating the size of your polyfills). We've been using these techniques for a while in production (our library is very focused on size) with good success. [1] https://medium.com/@jbartos/to-ship-less-code-write-transpiler-aware-javascript-a56250296760 https://medium.com/@jbartos/to-ship-less-code-write-transpil...
codyb 9y ago
Really neat article, might try to putz around with Brotli, hadn't even heard of it before. Was anyone else totally fascinated at those iPhone 8 processing times? Holy shit, it's faster than a Macbook Pro 16!! That's absolutely insane.
pc2g4d 9y ago
How much might precompling to WebAssembly cut into that compile/parse time?
tempodox 9y ago
Oh the irony, having one of the prime facilitators of web bloat talk about “the cost of JS”.

177 points by shawndumas 9y ago

It's not the cost of Javascript. It's the cost of shipping the latest trend as fast as possible by throwing in another lib that has all the options you will use 1% of. This is happening everywhere. And this is also why we are wasting so much time waiting for that page or program to load. It's a nice article but isn't this something that should be so obvious for the avarge programmer?

Waterluvian 9y ago
As a programmer I know all this. But I don't articulate as well as Addy. So He's given me a fantastic link to share with the non-programmers above me.
SippinLean 9y ago
This is covered in the article >Removing unused code
- Chyzwar 9y ago
  Nope. it is about including stuff that you really need. I saw apps that where shipping angular + jquery just to provide a single interactive icon. Article focus on very specific cases of the mobile web application. In most SPA it is not a big deal to ship a 1mb of JS.
  - SippinLean 9y ago
    They specifically mention tree-shaking and tools to strip unused code from libraries.
    - Chyzwar 9y ago
      Read my answer more carefully. It is about using frameworks when you really need it. A lot of people include dependencies to their projects that can be avoided by better knowing JS and Web APIs.
symlinkk 9y ago
It's happening because when you search for a job you get posting after posting that calls for experience with specific JavaScript frameworks. "Looking for a React ninja". "Looking for an Angular hacker". So programmers push for using those frameworks even on projects that don't necessarily call for them, so they can pad their resume and keep up with the ridiculous churn of frontend JS development. This is the advantage of working with a platform like iOS - there is one framework to make UI's and that's all you need to know for your entire career. Yes, the framework upgrades and changes, but you don't have to learn a completely new paradigm to change the contents of a text box for the hundredth time.

smacktoward 9y ago

This is one of the biggest things I have found remarkable about the modern Web: how slow everything feels. Nothing just loads anymore! Instead everything loads in dribs and drabs, as various bits of it stream down to the device, get parsed and get rendered. I waste so much time staring at placeholder graphics and missing clicks because the element I was aiming at skidded across the page after something else popped in. The more front-end technology we throw at the Web, the worse it seems to get. It's hard to remember that once upon a time Web pages were fast, even though we were viewing them on 1990s-era hardware that even today's budget mobile devices put to shame. We love the Web so much we are strangling it to death.

rhizome 9y ago
I've been paying attention to how slow the web is these days, and just as often as not I can finish a newspaper article (by far the worst offenders in 3rd Party API callouts) before the tab's page-loading indicator completes.
- JustSomeNobody 9y ago
  If it completes at all!
bitwize 9y ago
> We love the Web so much we are strangling it to death. "And I'm gonna hug 'im and squeeze 'im and name 'im George..."
jandrese 9y ago
This is one of the reasons I use noscript. By blocking those dozens of calls to external trackers/ad networks/etc... you can significantly reduce the time between clicking the link and the page being readable.

sirjaz 9y ago

This is why the webbrowser was not built for every little thing. We as programmers need to get back to writing applications and use the web more as a data stream. Thus letting the app do all the rendering ahead of time and we are just refreshing the data

draw_down 9y ago
> This is why the webbrowser was not built for every little thing. Fortunately, software is changeable :)
LolNoGenerics 9y ago
Well, average desktop app size exploded too.
pjmlp 9y ago
Yes, the browser should be kept for HTML / CSS, and maybe some JavaScript for interactive documents.

PerryCox 9y ago

We live in a world where everyone wants to make Electron apps instead of doing anything in a compiled language or anything other than JavaScript really. Maybe it's because I've never been a webdev but I just don't understand the fascination with JavaScript. Personally I hate JavaScript any time I have to code in it. Give me literally any other language.

bpicolo 9y ago
Electron isn't great just because it runs javascript, it's great because you get to use the HTML/CSS you're used to making pretty UIs with to make pretty desktop UIs. HTML/CSS have their warts, but they're a fantastically efficient way to build out UIs.
- megaman22 9y ago
  So instead of running WinForms or Qt or GTK or, god help us, Swing, components in a tight, snappy desktop app, we're mostly running Bootstrap components in a webview. Six of one, half-dozen of the other, in my book. The Stockholm syndrome around using browser technology everywhere, just because you've been brutalized into learning its wrinkles to work on the web, is scary.
  - greggman 9y ago
    having built both native and electron my experience is it's an order of magnitude faster to use electron to ship on win/Mac/Linux than any native tech clone this repo, follow steps at bottom of readme, ship on 3 platforms https://github.com/greggman/electron-hello-world https://github.com/greggman/electron-hello-world
    - jarjoura 9y ago
      Every single platform has their 1-line hello world example. iOS has storyboards, Windows has XAML, Linux has QT components. If all you need is an action button to trigger some underlying code, then those hello-world products are very simple. Electron is NOT that easy to use of a platform. In fact, it's quite technical and requires a lot of knowledge about node and HTML/CSS. It requires that the developer understand you're running a node process that feeds its results to a browser that has a native chrome. Visual Studio Code and Slack for example have native plugins that light-up the various platform's features. So you're never completely guarded from having to write native code. At the end of the day it's just another UI toolkit and language choice you can make when building out your software.

lcfcjs2 9y ago

I can almost spell the Old Spice in this thread.

setzer22 9y ago

I feel the web is so much faster on my phone since I started using brave and blocking all js by default. It's surprising how many pages load just fine with no javascript. Most HN articles do.

megamindbrian2 9y ago

I use AOT in dev mode.

bo1024 9y ago

Nice article, especially the data, but I'm disappointed they didn't cover more of the most effective approach: Design your site not to use javascript except where really needed! I think most sites can be broadly classified as (1) "relatively static" such as hackernews itself, news/blogs, text-based sites in general, or (2) an entire program/application running in the browser, such as a game or collaborative text editor. Most sites fall into category 1 and therefore need very little JS to do their job effectively, but they come up with 50 different things for JS to do on their webpage, then spend time and effort optimizing and minifying instead of just not doing those things (or doing them in HTML).

Scarbutt 9y ago
You are thinking only on two extremes, between a news/blogs and game/collaborative text editor there a thousands of web apps that don't fit the two. What would you call webapp for generating and keeping track of invoices?
- the_gastropod 9y ago
  While it's possible I'm not understanding some important aspect of invoice generation, I don't believe JavaScript is necessary for this process... Plain HTML form inputs -> Server -> Generate PDF? What am I missing? Why's JavaScript required here? I think we forget that the web was a pretty productive thing even before JavaScript was widely used. GMail existed (and still does) in a javascript-free form. You can even use Google Maps without JavaScript. Granted, JavaScript enhances both experiences, but it's not strictly required.
  - Scarbutt 9y ago
    Granted, JavaScript enhances both experiences, but it's not strictly required. Yep, Javascript is not strictly required but that was what I was trying to refer to, the enhancement part. A blog or news site like HN doesn't really need much enhancements, a web app for invoices lends itself to be way more interactive than HN. In your gmail example, the HTML version doesn't have: Chat Spell checker Keyboard shortcuts Adding or importing contacts Custom "from" addresses Rich formatting

diminish 9y ago

I had a chance to hack through the new contributor interface for a leading stock photo seller after UX has become erroneous and extremely slow after an update last week. They switched from an under-invested front end interface to a React/Redux for submitting images. I was thinking that maybe the implementation was bad but I concluded that the React/Redux and the set of front end components were to blame. Go read react/redux websites with dozens of cool ideas leading to a user revolt. Didn't we learn something from J2EE technologies that complexity is the source of all evil?

acemarke 9y ago
Hi, I'm a Redux maintainer. Can you give some more details on the issues you saw? What concerns do you have about using React and Redux?
- diminish 9y ago
  Thx for the kind offer. There's a list view where I select one or many video/image cards, and edit their titles, tags, descriptions in a single edit box singly or multiple. It's not about media editing, just their titles, tags and dozens of other data. Redux store contains all 200 image information as well as undo history. Here's the issue - when I put there 200 things to edit, the screen becomes very slow to use. Like the mere act of selecting and having its title/description etc appear on an edit box is 2 seconds. I have installed redux and react dev tools out of curiosity to understand what's happening. My conclusion, is that over 200 images to submit in batch combined with the undoable complex data store can't be handled. So I went to examine redux website and source code - which appears quite thin and performant. At the end I think react gets slow to update 200 cards from the complex store after redux store gets updated. I currently don't have some things to submit otherwise I would post some animated screenshots. But next time I have I can post a github issue and pls let me know what kind of data I must include from to react dev tools for performance check.
  - acemarke 9y ago
    Yeah, at first glance, I wouldn't _think_ that storing, displaying, and tracking selection for those items would be having performance issues, but obviously it depends on the actual code. My React/Redux links list has a large section of articles on measure and improving perf in React and Redux apps [0]. You might want to look through some of those. Also, my "Practical Redux" tutorial series [1] has some posts that talk about perf behavior, including key Redux perf concerns, and ways to buffer form input change events [0] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [1] http://blog.isquaredsoftware.com/series/practical-redux/ http://blog.isquaredsoftware.com/series/practical-redux/

deleted 9y ago

[deleted]

saas_co_de 9y ago

> adopt a Performance Budget for ensuring your team are able to keep an eye on their JavaScript costs. This is really good advice for product people.

jeeberz 9y ago

Anyone here deploy ES2015+ or know of any large sites that do?

bunderbunder 9y ago

This phenomenon seems like an almost inevitable symptom of another thing companies do, this one completely understandable: Making sure the dev team has nice equipment to work with. If we're always working with reasonably high-end kit, it impairs our ability to empathize with the experience of someone who's using a cheap Chromebook or the "free" phone. Contrast with a previous place I worked, where the team that was building in-house tools worked on hand-me-down equipment from their end users. That's a shop where the users almost never had to complain about poor UI performance.

codinghorror 9y ago

Pay attention to how much slower all the Android devices are here, whereas iPhone has long since reached laptop parity. So depressing how bad Qualcomm hardware is.

hobofan 9y ago

Not a hardcore JS-dev, but two things I noticed as someone who has optimized their JS output before: - I am surprised that this blog post advertises webpack tree-shaking, as it is completely broken right now, and has been for a year[0] - More and more people are switching to date-fns[1] from moment.js, since it is much smaller and composable by default, and works better with tree-shaking in rollup (or webpack once it's fixed). Yes, their recommendation of ContextReplacementPlugin is valid, but in the case of moment.js, its probably better to just use a replacement. [0] https://github.com/webpack/webpack/issues/2867 https://github.com/webpack/webpack/issues/2867 [1] https://github.com/date-fns/date-fns https://github.com/date-fns/date-fns

jeeberz 9y ago
Angular 5 has been using the webpack ModuleConcatenationPlugin to reduce bundle sizes by half. It does Rollup-like scope hoisting. Google for "angular build optimizer".

godot 9y ago

Every time one of these JS-related posts come up (especially performance-related ones), I find interesting the seemingly huge disconnect between the JS-hating audience of HN and the actual silicon valley corporate/startup world where heavy-JS/React/SPA is everything. Let me begin by stating that I'm not hating on either side of the fence -- I've been on both sides (and arguably, I still am on both sides, if that were possible). As someone who works on a lot of side projects, I can very easily see the argument of keeping web sites JS-light, and not even dive into all the React stuff. Most projects don't necessarily call for it except for certain very specific things. (I actually do not use React on any side projects of mine, and still stick with jQuery.) On the other hand, after having joined a JS-fullstack startup this year, I can see that an article like this one is completely speaking to me/us. All I can say is, without the giant background context of working on a monolithic fullstack JS codebase, none of it makes sense; but when you're in such a job, everything of it makes sense.

tjoff 9y ago
"everything of it makes sense" No it doesn't. Because you are obviously not implementing something that is meant to be used by a human being. That load times are measured in multiple seconds even on a 4G phone is mind boggling.
- godot 9y ago
  You don't have to be combative. I agree with you. The article is advocating for JS developers to be aware of what makes their SPA react JS app heavy and load slowly. I'm saying that an article like this only makes sense when you have the full context behind working on a SPA react JS mono codebase. If you haven't worked on one, it all sounds like gibberish and your mind just goes off to wonder "why even build this heavy react JS app to begin with when you could build a site without JS".
ng12 9y ago
I think it's so weird that many people on HN can't fathom a website being more complex than Medium. I've spent the last 5+ years doing nothing but develop data-heavy visualization apps. The alternative is not building a website without JS, it's building a desktop application using Swing or QT.

vdnkh 9y ago

I wrote this [1] guide on how to reduce the size of your JS bundles via transpiler optimizations. There's a lot you can do to write code which results in less boilerplate from your toolchain. It also covers code splitting via webpack and some other goodies (like evaulating the size of your polyfills). We've been using these techniques for a while in production (our library is very focused on size) with good success. [1] https://medium.com/@jbartos/to-ship-less-code-write-transpiler-aware-javascript-a56250296760 https://medium.com/@jbartos/to-ship-less-code-write-transpil...

codyb 9y ago

Really neat article, might try to putz around with Brotli, hadn't even heard of it before. Was anyone else totally fascinated at those iPhone 8 processing times? Holy shit, it's faster than a Macbook Pro 16!! That's absolutely insane.

pc2g4d 9y ago

How much might precompling to WebAssembly cut into that compile/parse time?

tempodox 9y ago

Oh the irony, having one of the prime facilitators of web bloat talk about “the cost of JS”.