
The Cost of JavaScript - shawndumas
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
======
bo1024
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
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
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.

~~~
betageek
There was never a time in the modern web era when JavaScript wasn't widely
used. You'd have to go way back pre-2000 to find a time when popular websites
didn't use JS at all. The Cambrian explosion of 'Web 2.0' wouldn't have
happened without JavaScript and we wouldn't be where we are - doing everything
on the server sucked big time, I do not want to go back to party like it's
1996.

To use Gmail, the poster boy of Web 2.0, as an example of why sites don't need
to use JavaScript is bizarre. It destroyed other webmail sites because it used
JS to give users a real GUI mail client on the web - the HTML backup works,
but if that was all they'd given us we'd still be on Hotmail.

~~~
mikeash
I thought gmail’s big competitive advantage was giving users 1GB of space
instead of 10MB or whatever that other free webmail providers gave us. I don’t
recall gmail’s UI being remarkably better.

~~~
tinus_hn
Also, good spam filtering and alternative access through protocols like imap.

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

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

~~~
com2kid
> I've spent the last 5+ years doing nothing but develop data-heavy
> visualization apps.

Those aren't what this article is talking about though, For a huge client
facing desktop web app, you can load things up front, expect the user to wait
a bit, and then off you go.

But imagine if every page on HN took ~15 seconds to load. Heck the reddit
mobile experience right now is that the comments section takes 4-5 seconds to
load, and sometimes it doesn't load at all. Of course it is instant in their
mobile app, and also instantaneous in their legacy mobile view. (Which makes
me seriously question what in the world the modern mobile site is doing.)

Most content is temporary and short lived. Caching a script does next to no
good if I only ever visit a site once or twice a month, I'd prefer there not
be a script at all!

In regards to content, HN is one of the most valuable sites I use. The
JavaScript is so tiny as to be inconsequential.

Give me a CNN.com that is as responsive.

~~~
tomr_stargazer
I know your request is tongue-in-cheek, but here you go:

[http://lite.cnn.io/en](http://lite.cnn.io/en)

~~~
com2kid
an old fashion img tag at top and I'd be delighted.

Need to resize the browser window to get a good column width, but that site is
fast.

(pure black on pure white also isn't easy on the eyes, but plain ol HTML can
change that as well! :) )

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

~~~
greggman
I programmed assembly then C then C++ through the the 80s, 90s and 2000s. I
love JavsScript. It just so damn easy. No fighting with headers, include
paths, linker options, make files , cmake files, scons files, etc. No cross
platform bs. When I want to share I just send a link. Electron does have a few
platform issues to build the app but they're most solved for me. I get
formatting, styles, animation, for free. I get cross platform graphics, video,
and audio for free, networking is trivial. I also get pretty amazing debugging
tools.

iteration time is orders of magnitude faster than any C/C++ project I've ever
worked on.

I hated JavaScript at first because I didn't understand it. It took about 2
year to stop trying to turn in back into C++. It didn't help that my first
real intro was in an environment that used Google Closure and the closure
compiler both of which were designed by Java programmers to try to treat
JavaScript as Java and disallowed real JavaScript.

now I mostly loath going back to C++ and having to fight the dev tools on each
platform which seem to change every 5 years such that all old samples fail.

is it JS perfect? no, i think I kind of miss static typing but not always.
It's often a joy to just do it.

~~~
megaman22
> No fighting with headers, include paths, linker options, make files , cmake
> files, scons files, etc

Instead you get to fight with often poorly-versioned bower/npm dependency
hell, and gulp/grunt/webpack config errors with inscrutable messages.

> having to fight the dev tools on each platform which seem to change every 5
> years such that all old samples fail.

Such stability! If anything in javascript still works five months later, I
count my lucky stars.

~~~
jeeberz
I hear you but since I've been using yarn to lock all package versions I
haven't had any issues.

[https://yarnpkg.com/lang/en/docs/yarn-
lock/](https://yarnpkg.com/lang/en/docs/yarn-lock/)

JS development without yarn is complete madness.

~~~
merb
which means that you do not use a npm proxy.

------
pasta
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?

~~~
SippinLean
This is covered in the article

>Removing unused code

~~~
Chyzwar
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
They specifically mention tree-shaking and tools to strip unused code from
libraries.

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

------
smacktoward
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
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
If it completes at all!

------
diminish
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
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
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
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...](https://github.com/markerikson/react-redux-
links/blob/master/react-performance.md)

[1] [http://blog.isquaredsoftware.com/series/practical-
redux/](http://blog.isquaredsoftware.com/series/practical-redux/)

~~~
diminish
Wow that's awesome. Thank you for your kind interest..

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

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

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

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

~~~
pjmlp
Yes, the browser should be kept for HTML / CSS, and maybe some JavaScript for
interactive documents.

------
vdnkh
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-
transpil...](https://medium.com/@jbartos/to-ship-less-code-write-transpiler-
aware-javascript-a56250296760)

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

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

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

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

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

------
megamindbrian2
I use AOT in dev mode.

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

