
JavaScript growth and third parties - panic
https://speedcurve.com/blog/javascript-growth/
======
rantanplan
EDIT: The HN title changed so I don't know if this comment is relevant
anymore.

That sounds like saying "living is the leading cause of death".

I mean, I don't particularly like JS, but it seems like we decided long ago
that plain documents and links won't cut it. Everything, apparently, needs to
be a rich web application with huge images and a gazillion of ads.

Why is that Javascript's fault?

~~~
TeMPOraL
It's not the fault of JavaScript the language, but JavaScript as the name we
give to the parts of a web page that are not HTML and not CSS.

And it's not really "living is the leading cause of death"; most of that
JavaScript is superfluous garbage - ad scripts, trackers, bloated frameworks.
You don't need this for a page to serve a socially useful purpose. You just
need someone in your company with enough clout, who's willing to say, "out of
respect for our users and for engineering as a practice, we will not partake
in the latest iteration of the insanity that is the modern web".

~~~
andrewingram
You need to be pretty damn high up in a company to overrule the business
reasons for trackers, and perhaps more critically, helpdesk widgets. The size
of the very common Zendesk widget is obscene.

~~~
TeMPOraL
You might not be high enough in a large company, but in smaller companies and
startups, an employee-level pushback can go a long way.

------
azeotropic
I don't understand why JavaScript is so ubiquitous now. There seem to be very
few cases where it is actually necessary and useful (e.g. a calculator form
that does computations client side that would otherwise overwhelm the server).

I am constantly surprised at the number of sites that should be totally static
(e.g. a local restaurant's menu page) that display nothing at all when I visit
with JavaScript disabled.

Can someone who actually makes websites explain why this has happened? Is this
about varying screen resolutions and aspect ratios in the era of phones and
tablets? Can't you just use CSS instead?

~~~
kowdermeister
JS is very useful in many cases. Don't just think about documents or single
blog posts in those cases static content should be sufficient.

But the web evolved to be way more than being a dumb content delivery pipe,
it's an application development platform bypassing the underlying OS.

So ask yourself, if you need well behaved image galleries, do you need JS?
Yes. Do you want to avoid page reloading to navigate? You need JS. Do you want
login/form validation? You need JS. Need an inline calculator? Update content
from the server? Monitor the progress of a long lasting server job? Add any
logic to a shopping cart?

And these are very simple use cases, web apps are needless to say changed the
way we ship apps and they all rely on JS.

I'm very much in support of offloading as many tasks to CSS as possible, but
JS is hard to avoid if you want to do anything beyond static content delivery.

~~~
nikanj
But it’s also used in completely idiotic places. Want to display a 100% static
blog post? With just thirteen megabytes of JS, you can break scrolling,
zooming, screen readers, and many others.

Reminds me of emails and newsletters. Yes, they have many legitimate uses, but
that doesn’t change the fact that a large part of them are just plain crap.

I feel like both sides of the debate are refusing to admit the other side
might also have some valid points. Which admittably seems to be the theme in
all of the internet.

~~~
kowdermeister
Authors are free to alienate their audience the way they please :)

------
onion2k
Poorly implemented JS makes websites slower. Well implemented JS makes
websites faster. The lesson here is not "use less JS" because you'll miss out
on some things that JS can do that actually improves (perceived) performance,
but rather it's "Use JS intelligently or risk harming your site's
performance." The raw number of downloads doesn't impact the speed at all if
most of them are done asynchronously in the background while the browser is
idle after the first paint and after the page is interactive.

Developers seem to have forgotten progressive enhancement entirely and just
piled more and more JS in to the first page load. Consequently users complain
about JS, but JS itself is not the problem. There are patterns for building
websites that are _fast_ , in terms of both literal download and rendering
speed and the perceived speed the user feels. We 'just' need better developers
who actually care about the sites they build.

~~~
lucideer
Imo, the real problem is that most people believe what you're saying is true,
but if we assume that JS itself is not the problem, and that finding the right
patterns for building fast websites with JavaScript, the next question
becomes: who do we look to to learn the right patterns from.

For most people, the intuitive thing is to look to successful companies:
Google, Facebook, etc. The problem here is two fold: (1) operating at scale
often has requirements that supercede making individual pages fast for
individual visitors and (2) massive market dominance/semi-monopolies/vendor-
lock-ins means these companies don't really need to compete on perf. See
Facebook.com/gmail.com as lovely examples of some of the worst performance on
the web.

You're right that one can make a webpage fast with correctly implemented js,
but I disagree that _people_ can make webpages fast en masse with correctly
implemented js; dissuading the use of JS is much more likely to have a
positive effect than expecting people to somehow spontaneously learn how to
write good js.

------
SCdF
Ironically after 47 minutes on HN their site doesn't load at all.

Here is a cached version that works:
[http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://speedcurve.com/blog/javascript-
growth/)

~~~
zeman
Can I just check, do you use Edge browser? We've (SpeedCurve) been seeing some
issues where Edge goes bonkers and makes thousands of requests to our CDN and
fails to load CSS which would look like a broken site.

~~~
SCdF
Apologies, it wasn't down because of HN! I can't edit the original post now,
but it was just my computer blocking your domain at the hosts level via
[https://github.com/StevenBlack/hosts](https://github.com/StevenBlack/hosts)

I should have realised, but it's the first time using that hosts list has ever
stopped a website I've wanted to go to from loading, so I didn't think of it.

------
mschuetz
I'd rather attribute that to ads, especially terrible ones that cause page
reflow, than just javascript.

~~~
vthriller
Page reflow is nothing compared to <canvas>es flying on top of the <video>
thanks to some overengineered JS code.

------
Dowwie
Google Mail feels like it's transmitting over a 57.6k modem these days. If
developers at Google can't make fast JavaScript front ends, what are the odds
that an average front end developer can?

~~~
nailer
It's 6MB (closer to 7 if you round it).

[https://twitter.com/mikemaccana/status/1073538289582436352](https://twitter.com/mikemaccana/status/1073538289582436352)

~~~
onion-soup
did you just compare a bundle size with the modem bandwidth?

~~~
nailer
Not the JS bundle (if that's what you mean), the site itself (to get to the
point where you can use gmail).

And yes, why wouldn't I? My 50Mb/s cable modem can download the fully featured
Fastmail (500K) _13x faster than GMail_. That's how bandwidth works.

------
OliverJones
The wheel of karma keeps on turning. Rich-client / client-server / rich-client
/ client-server. It's been going on since core memory supplanted rotating drum
memory. It's not going to stop.

Javascript is an INSANELY GREAT way of implementing rich clients; the best
I've seen in my almost half-century in the trade. (Progress. Duh.)

The modern clients (browsers) now have compilation right. V8 and its
competitors are astonishing. But as always we have to get the distribution
right: security, caches, progressive and async loading, agendas under control
(meaning justified amounts of third party stuff).

------
VMG
Probably it is not the specific language that is to blame here, but the fact
that websites are programs at all.

We all know plenty of slow Python, C and C++ programs.

I think there are some general "laws" that dictate this

1\. all things that are programmable will be programmed at some point

2\. all programs, no matter what language, we become as slow as the users will
tolerate

------
singularity2001
> In terms of the number of JavaScript requests, first party has gone up 50%
> from 4 to 6 requests, whereas third party has increased 140% from 5 to 12
> requests.

> Third party growth in terms of JavaScript size is more alarming. First party
> JavaScript doubled from 53 KB to 106 KB. Third party JavaScript octupled(!)
> from 32 KB to 258 KB.

one more reason to use NoScript

------
petetnt
While I do acknowledge that increase in generic third-party things like ads
and trackers definitely plays a certain role here isn't the study is kind of
moot unless sites with similar feature sets are compared.

~~~
TeMPOraL
You can compare site's performance with it's performance under uMatrix or even
uBlock. The amount of nonessential third-party JS is really a big problem.

------
ivanhoe
And the saddest thing is that this javascript is mainly used for a) tracking
and b) useless UI features that stopped being impressive to anyone like 10
years ago (highjacking the scroll, parallax, sliders, etc.)

------
z3t4
O(c^n) is what makes websites slow. Piling libraries, frameworks, trackers,
and other third party services on-top of each other, that each has thousands
of dependencies.

~~~
VMG
Also there is nothing special about websites. The same is true for programs
and mobile apps.

------
kowdermeister
Judging by the bundle sizes, the numbers aren't that bad if you consider the
increasing of internet speed:

[https://www.nngroup.com/articles/law-of-
bandwidth/](https://www.nngroup.com/articles/law-of-bandwidth/)

Given that HTTP2 will be more and more available, the number of requests isn't
a problem either. Global, fast CDN-s are thing for a while.

What would be worrying about client side JS is needless use of heavy
frameworks, like Angular, CPU hogging tracking scripts or lame ads, dark UX
marketing widgets.

~~~
jamil7
The problem with a heavy bundle isn't just delivery it's parsing and execution
the bundle aswell.

~~~
kowdermeister
Of course, that's what I meant by heavy _frameworks_.

~~~
jamil7
Ah ok sorry, I misunderstood.

------
hkt
Web pages were better than web apps. Whisper it.

------
onion-soup
Fixed: Ad-tracking libraries is the main cause for making websites slow

------
CoderRefresh
One of the big problems with JavaScript is that some developers don't know it
very well (me included) but have to get some feature working, so import
multiple frameworks/libraries to get their job done, most of which is not
needed.

------
fithisux
Yeeeeeeeeeeeeees.

