undefined | Better HN

0 pointslmm1y ago0 comments

Yes, it is. Unfortunately HN has a crazy bias against JavaScript (the least crazy part of the web stack) and in favour of HTML and CSS, even though the latter are worse in every meaningful way.

0 comments

dickersnoodle1y ago

It isn't crazy, judging by the number of times I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included. Granted that may not be needed for personal websites, but for almost anything that has to be monetized you're going to get stuck with JS cancer because some sphincter in a suit needs for "number to go up".

lmmOP1y ago

> I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included

Perfect example. HN will see a page with 6Mb of images/video, 1Mb of CSS and 200Kb of JavaScript and say "look at how much the JavaScript is bloating that page".

oneeyedpigeon1y ago

I don't even know where to begin with the pretence that you can compare HTML with JS and somehow conclude that one is 'better' than the other. They are totally different things. JS is for functionality, and if you're using it to serve static content, you're not using it as designed.

lmmOP1y ago

I don't particularly care about "designed for". If you've got to serve something to make the browser display the static content you want it to, the least unpleasant way to do so is with JS.

TeMPOraL1y ago

Least unpleasant to the developer. Most unpleasant to the user. It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).

lmmOP1y ago

> It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).

Nah, it's the opposite. JS tends to perform better and be more usable for the same level of feature complexity (people who want more complex sites, for good reasons or bad, tend to use JS, but if you compare like with like), HN just likes to use them as a stick to reinforce their prejudices. (E.g. if you actually test with a screenreader, aria labels work better than "semantic" HTML tags)

1 more reply

j / k navigate · click thread line to collapse

0 comments

dickersnoodle1y ago

lmmOP1y ago

> I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included

Perfect example. HN will see a page with 6Mb of images/video, 1Mb of CSS and 200Kb of JavaScript and say "look at how much the JavaScript is bloating that page".

oneeyedpigeon1y ago

lmmOP1y ago

I don't particularly care about "designed for". If you've got to serve something to make the browser display the static content you want it to, the least unpleasant way to do so is with JS.

TeMPOraL1y ago

lmmOP1y ago

> It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).

1 more reply

j / k navigate · click thread line to collapse