Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript growth and third parties

speedcurve.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: JavaScript growth and third parties

#51

Post by SignsOfABeast »

raverbashing wrote: post #22
rantanplan wrote: post #6

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.

> 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

Re: JavaScript growth and third parties

#52

Post by pmarin »

Dowwie wrote: 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?

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.

Re: JavaScript growth and third parties

#53

Post by azangru »

weego wrote: post #32
rantanplan wrote: post #6

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?

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…

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

Re: JavaScript growth and third parties

#54

Post by kowdermeister »

jamil7 wrote: post #49
kowdermeister wrote: post #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…

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.

Re: JavaScript growth and third parties

#55

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

Re: JavaScript growth and third parties

#56

Post by HelloNurse »

BerislavLopac wrote: post #17
azeotropic wrote: post #7

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…

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

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

Re: JavaScript growth and third parties

#57

Post by Ruphin »

azeotropic wrote: post #7

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…

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.

Re: JavaScript growth and third parties

#58

Post by azangru »

franga2000 wrote: post #45
azeotropic wrote: post #7

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…

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.

Re: JavaScript growth and third parties

#59

Post by Phenix88be »

azeotropic wrote: post #7

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…

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

Re: JavaScript growth and third parties

#60

Post by SignsOfABeast »

onion2k wrote: 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…

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