Live data from Hacker News

JavaScript growth and third parties

speedcurve.com

41–50 of 77 posts

Re: JavaScript growth and third parties

#41
post #9

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.

Re: JavaScript growth and third parties

#42

Earlier quoted context omitted.

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…

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.

Re: JavaScript growth and third parties

#43

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…

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 ne…

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.

Re: JavaScript growth and third parties

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

Re: JavaScript growth and third parties

#45

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…

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.

Re: JavaScript growth and third parties

#46

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…

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.

Re: JavaScript growth and third parties

#47

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?

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.

Re: JavaScript growth and third parties

#48
post #27

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 backgr…

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.

Re: JavaScript growth and third parties

#49

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…

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

Re: JavaScript growth and third parties

#50
post #43

Earlier quoted context omitted.

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 ne…

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 sid…

Authors are free to alienate their audience the way they please :)
Post reply on HN