JavaScript growth and third parties | Hacker News Reader

JavaScript growth and third parties

speedcurve.com

57 pointspanic76 comments

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?

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

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.

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.

> You don't need this for a page to serve a socially useful purpose.

You don't need JS to "serve a socially useful purpose" most of the time, as well.

As I said, it seems we decided that everything needs to feel like an app.

95%(yes, I'm probably exaggerating) of the actual value of the today's websites could be plain documents with links to each other.

But try and suggest to anyone you're gonna have a company presence site(or anything for that matter) with no JS at all, and see where it gets you.

I feel it's too late to escape the web browser being established as an application distribution platform - though if you're building a document, then you it to your users and your own dignity, to make it like a document, not an application. Most websites are more like documents than apps.

But my comment applies to apps as well - just because you need to write actual software, doesn't mean you should throw away sensible engineering, and produce a bloated, user-hostile, spying & battery-devouring monster. Yet this is what seems to be coming out of most web shops these days.

It is entirely possible to build rich web apps with very small size. As shown in the article, the main source of bloat are 3rd party scripts: ads, tracking, metrics, retargeting, security...

Everyone here is the choir...

Now convince the client that they don't need to track every single possible click of the user - as they experience their "journey" through the site...

...convince the client that all those experience designers effusing about that "emotional layer" they added to that user journey didn't really result in 30% more engagement with the brand - as evidenced by exactly that same user tracking - convince em XD isn't just mouthing a load of horse shit. I mean - why do all the folks in XD dress in black all the time anyway. Would someone run a focus group on that please?

Funny thing is - I don't even know if they are all full of shit or not. Maybe all this is all necessary - maybe not. I don't even know and I build this stuff for a living. Client seems happy so meh...

But yeah - these large JS bundles aint the cause of these large JS bundles... ahem - I mean these slow sites...

There are these obscure files called "logs" which record every interaction with your server. They might be useful, IDK.

I keep JS disabled so most of this crap don't bother me.

I feel like there is some happy medium. For instance, biasing toward declarative documents as much as possible (HTML and CSS DOM) and perhaps fetching and compiling/linking only needed JS functions with intelligent asset pipelines. I built production web sites with Play Framework's asset pipeline that netted a single first party JS file and no external JS. As could be expected via minimalism it felt faster than almost every site on the internet. Even with third party JS you could cache, compile/perform weak linkage step, and ship a single JS file. No site necessarily needs more than three docs (HTML, CSS, JS) for the first hit plus whatever images, sprites, and fonts load async.

You nailed it. Everything doesn't need to be a rich internet application. One important aspect of this trend is that it based on decisions made by a few for their specific use cases and then copied, without much analytical decision making, by the majority. The assumption that Facebook, Google, Amazon, or Apple know better in all categories tech contributed to widespread adoption of SPA's.

Absolutely. The obsession with trying to turn every part of software engineering into something you can generalise and framework on the frontend is the cause of our current woes.

In the post Flash days I was accepting of pushing JS use as far as possible but the fragmentation and complexity that seems to just have become implicitly accepted is just something I'm much happier looking at from a distance than wanting to ever get involved in again.

The fact that it's more difficult setting up a JS project than it is for, say, Scala which is itself a pain in the ass speaks volumes.

> The fact that it's more difficult setting up a JS project than it is for, say, Scala which is itself a pain in the ass speaks volumes.

JS allows various levels of complexity. From inlining JS inside script tags in an html file or requiring a js file in the script tag to transpiling cutting-edge JS (or dialects/supersets of JS) with sourcemaps, minification, code-splitting, etc.

The latter end of the spectrum is reasonably complex; the former is ridiculously simple. I wonder if same can be said about Scala.

JS should be used only/mostly for SPAs. and here and there to validate forms or other optional small enhancements, most websit6es that are linked here are not SPAs so should work without JS

It is not the fault of JavaScript. The article points out very directly the violator is third-party code. As a result I blame marketing and media for all that spyware/analytics bullshit that is thrust into the page.

EDIT: As I wrote this comment the title here was edited to directly reflect the nature of my comment.

It's the fault of giving every random webpage the ability to run a programming language in the browser.

For 99% of the web a markup language with triggers and async loading could have been enough to implement menus, upvote posts, post login forms, and so on.

Also, JS is cached. First time will be slow, others, not so much

The mainstream libraries are fast and optimizable (Angular/React/Vue/etc). Other, not so much.

> Also, JS is cached. First time will be slow, others, not so much

This is a very weak argument.

  * many 3rd party resources are not cacheable or may have bad policies
  * caches may be more often cold then you expect. most apps still cache large combined blobs, which will invalidate with each release.
  * pure JS size has still it's impact on performance
  * caching won't magically cut all network roundtrips which you need due to architectural reasons

Yes, but you can optimize your website for caching. Your points are valid but they mostly boil down to "people don't know/don't care what they're doing", which won't help even if you don't have JS in your site.

And it is: "still its impact"

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?

It happened because most people don't build websites themselves, they contract the work out. And when you look for contractors who build websites, you'll find JS developers, because that is where the lucrative work is therefore that is what developers learn.

There is no pushback on it because as long as it works, people are happy and continue paying. And none of the clients test with js disabled.

Devs use it because the moment the client needs something somewhat dynamic, some js will need to be included anyway so you might as well use your usual stack.

Basically "why do people use js where HTML does the trick" is the same question as "why do people use python where c89 does the trick"

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.

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.

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

I'm a web developer who avoids this sad trend wherever possible. I see two reasons for this: 1) the development experience for things like React is so 'smooth' that many developers use it even when it's not necessary at all (I'm referring to things like hot-reloading and custom components which are more complicated to set up with pre-processors) 2) some animations and advanced interactivity have become expected of us, but instead of tacking it on later, which makes the code objectively less clean, they build everything in JS, making it perform like shit and leading to things like the infamous gray bars placeholder.

But it can be done right. dev.to is a great example of an interactive web application with all the bells and whistles, yet it still performs better than most static sites.

An unrelated question: how many `html` and `body` tags are allowed on a web page? I just looked at the page source of https://dev.to/liquid_chickens/three-qualities-of-failed-mic..., and to my surprise noticed they have about five `html` and `body` tags on that page. They aren't even in iframes either.

One and only one of each. And having more than 1 doctype declaration is ridiculous. Browsers are very resistent to garbage markup, so by looking at the parsed tree and not the raw text, I never actually noticed that.

I have no idea why they would do that. It looks like a misconfigurated preprocessor that thinks each fragment is a doc of its own. I vaguely recall something about them open-sourcing the frontend, so I might look into that...

Yep, my guess would be that they are using a markdown parser that generates a complete html document out of submitted markdown, and then they just stitch those parsed htmls together, like here (the processed_html method on the article instance):

https://github.com/thepracticaldev/dev.to/blob/master/app/vi...

> Browsers are very resistent to garbage markup

Miraculously so! Anything I would have attempted to design would have crapped its pants at the look of this markup, but browsers heroically manage to display it as if nothing weird is happening. I take my hat off to their resilience.

Yes. And actually, this is a mistake in our processing configuration. We don’t want separate body tags, but it hasn’t been a problem so we haven’t gotten around to fixing it.

PRs welcome. :)

Can someone who actually makes websites explain why this has happened?

The cause is split pretty evenly between web developers who don't care about what they build enough to learn how to do it well, and companies who employ them letting them do that rather than pushing them to improve, and client's who don't understand what they've bought well enough to complain.

Everything is like that though. It's not limited to websites. Everything has problems, and it's always someone's fault. Developers tend to notice websites because we use them a lot and (some of us) think it's just laziness on the part of the website dev, but if you were an electrician you'd see problems with powertools, or a nurse you'd see issues with drug companies, and so on. The world is imperfect.

A wild guess is that these days the developers tend to specialise along the front/back end line. So a user-facing Web interface of any kind is usually assigned to front-end developers, which is now mostly synonymous with "Javascript developer", or even more specifically "React/Angular/etc developer" (just like on the back end side we commonly have Django/RoR/Magento/etc developers").

I used to be a full-stack developers, trying to balance my apps/pages just right between the server and browser side. But lately it's much easier to just focus on building APIs and let the front-end devs deal with all the interaction, forms and other user-facing stuff.

A slow website has useless HTTP requests, useless bloated content in those request, inefficient or useless computations and DOM changes, and even animation delays and other types of intentional slowdown on the critical path: it is designed wrong and decent developers should try to do better, regardless of what frameworks were used or not to make it bad and whether lack of communication between front end and back end teams is behind the problems.

The interesting question, then, is what horribly wrong incentives are at work to make web developers accept slow sites (and other trends of bad design like "dark UI patterns" and data collection).

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

I am constantly surprised at the number of people that explicitly disable JavaScript to make their lives difficult in 2018.

My point is, JavaScript makes it easy to build nice websites at scale. Plenty of CMS platforms (like Wix.com) use JavaScript by default.

If 99.9999999% of people are fine with JavaScript, then why should a website cater to your need by providing a version specific to people who disable JavaScript?

> JavaScript makes it easy to build nice websites at scale

> build nice websites at scale

> at scale

What? Might as well mention ML & blockchain while we're at it.

If site is not interactive, it doesn't _need_ JS.

If it does need JS, it more than likely needs _sprinkles_ of it.

By "at scale", I mean building abstractions on top of commonly used html elements and making them interactive, using something like "components" in React. Then you only need to write the shopping cart or image gallery once, and users of website builders can just click a button to add it to their website.

Also, interactivity almost always gives better UX than static websites, if it's done properly by a professional website builder like Wix or Squarespace. So there's not much to hate it except maybe a few MB of extra code that you need to download.

I can't think of any good use cases for static websites in 2018, except maybe blogs in pure plaintext or old fashioned forums. Even HN has JavaScript for that little bit of interactivity (collapsing comments).

> By "at scale", I mean building abstractions on top of commonly used html elements and making them interactive,

This sounds like double-speak. That's not what at scale refers to, even allowing a very loose definition.

How the HTML is generated is moot. Server side templates had re-usability at a "component" level. iFrames exist, redirects exist.

I'm not saying all JS is bad. I'm saying too may new people seem to think JS in and of itself is magic and there is no other way to generate/manipulate the DOM or talk to other computers.

I'm bailing out of this conversation now because you're heavily conflating HTML, browser functionality and www fundamentals with website builders(i don't know why you felt the need to qualify it with "professional")

> Even HN has JavaScript for that little bit of interactivity (collapsing comments).

Yeah no, "even HN" works perfectly with JS blocked. JS for HN is an enhancement, not a requirement. They understand how the web can work...

Remember when those local restaurant's menu page where build in Flash because the owner wanted some "flip like a book" animation ? Javascript is a the same cancer as Flash. Why build "simple" static and performant website when you can sell a higth price pile animated javascript shit who "don't reload the page when your click".

Developers use the tools they are familiar with. If you are a Rails developer, you will probably choose Rails when you have to build a website, even if the website doesn't strictly require Rails.

Many web developers are familiar with React, Angular, or other front-end frameworks; they are familiar with the deployment process, and the tools around it. If they need to build a website, they will use these tools, regardless of the requirements of the website.

Because of the explosive growth and fast paced advancement of the web, most developers are mostly copy/pasting and gluing modules together. When the customer asks for a "image slideshow" they are not going to write one from scratch, even though it's just 10 LOC, they are going to bring in a library/framework which already has that functionality.

Anyone who actually has written a slideshow from scratch knows that it's way more than 10 lines of code: you couldn't even do the CSS in that, let alone accessible HTML, responsiveness, etc. There's a lot of design and testing which goes into superficially simple-seeming components and it'd be irresponsible to take that on each time unless you have a really good business justification.

It may not be functionally necessary from the user's perspective, but much of this JavaScript is included because of the business model of the publisher. It has a function, even though it's not a function that's visible to the user.

It tends to be things like trackers that report back what browser versions, supported plugins, cookies for directed adverts.

I suppose I should 'view source' to check a few, but are local restaurants actually using tracking code on menu pages?

I'll by the lazy developer / uninformed business owner explanation or the flash cancer analogy, but the tracking explanation seems a little far-fetched.

I get that Facebook, Amazon, Apple, and Google are all running ad networks trying to track me, and that globally this accounts for most of the bloat.

I'm trying to understand the dynamic that causes what should be simple static websites to use JS in such a way that they display no information at all when JS is off.

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.

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.

I call this no-js-first. There are apps that are blazing fast and have a lot of fancy/modern js stuff in it, they simply don't require any of it at all.

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

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.

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

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.

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

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

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?

To be fair, Google for years have been perfect examples of developers that can't optimize to save their life. Virtually every other site is faster than any of their sites.

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

https://twitter.com/mikemaccana/status/1073538289582436352

did you just compare a bundle size with the modem bandwidth?

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.

The odds are pretty high. A bunch of google "apps" are pretty inefficient. Like every company, Google has a spectrum of good, ok and bad programmers. It seems like they are working hard on making gmail slower every release.

That's why they added the splash animation. Which also has to be downloaded.

I have been using the html only version of GMail for months. For my user case is much faster than the last webapp implementation.

It's kind of sad because it was the only webapp that made sense to me.

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

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

> 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

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.

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.

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

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.

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

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/

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.

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

Of course, that's what I meant by heavy frameworks.

Ah ok sorry, I misunderstood.

Web pages were better than web apps. Whisper it.

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

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.

Yeeeeeeeeeeeeees.

Reply on news.ycombinator.com