> Sorry, the point of the article went way past your head.
This is not useful or helpful tone and really does not belong on HN [1]. My comments addressing security and privacy were in response to the current top comment [2].
I fully realize that performance is the goal of the article. What I strongly disagree with is the article's projected viewpoint of the universality of JS being slower.
> despite the best effort of (...) tools that send less JS be default
> Video of a single slow-loading page lands in a visceral way; abstract graphs don’t.
Saying JavaScript is universally slower is as true as saying client side code is always slower. This is obviously not the case. Just imagine if the next CounterStrike game tried to do everything with server side rendering rather than transferring 5GB of game code one time and tiny fractions of that from then on. Obviously the argument is not universal. Costs can be amortized. Code can be cached and intelligently replaced. There are entire industries where nobody would even think to debate that a lot of client side code is the only way to achieve their goals.
I'm not saying everybody does this well, but I'm confident saying that the answer is not going to be universally less JavaScript.
Edited because I had the wrong link. I had posted that exact service earlier as an example of things being feasible but not best for latency, which is a very real component of user-perceived speed.
This is not useful or helpful tone and really does not belong on HN [1]. My comments addressing security and privacy were in response to the current top comment [2].
I fully realize that performance is the goal of the article. What I strongly disagree with is the article's projected viewpoint of the universality of JS being slower.
> despite the best effort of (...) tools that send less JS be default
> Video of a single slow-loading page lands in a visceral way; abstract graphs don’t.
Saying JavaScript is universally slower is as true as saying client side code is always slower. This is obviously not the case. Just imagine if the next CounterStrike game tried to do everything with server side rendering rather than transferring 5GB of game code one time and tiny fractions of that from then on. Obviously the argument is not universal. Costs can be amortized. Code can be cached and intelligently replaced. There are entire industries where nobody would even think to debate that a lot of client side code is the only way to achieve their goals.
I'm not saying everybody does this well, but I'm confident saying that the answer is not going to be universally less JavaScript.
[1] https://news.ycombinator.com/newsguidelines.html
[2] https://news.ycombinator.com/item?id=17963207