Live data from Hacker News

JavaScript growth and third parties

speedcurve.com

21–30 of 77 posts

Re: JavaScript growth and third parties

#21

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?

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.

Re: JavaScript growth and third parties

#22

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?

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.

Re: JavaScript growth and third parties

#23
post #18
post #10

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?

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?

Re: JavaScript growth and third parties

#24

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

Re: JavaScript growth and third parties

#26

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…

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"

Re: JavaScript growth and third parties

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

Re: JavaScript growth and third parties

#28

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…

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

Re: JavaScript growth and third parties

#29
post #10

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?

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

Re: JavaScript growth and third parties

#30

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…

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.
Post reply on HN