Comment by godot | Hacker News Reader

Comment by godot | Hacker News Reader

Every time one of these JS-related posts come up (especially performance-related ones), I find interesting the seemingly huge disconnect between the JS-hating audience of HN and the actual silicon valley corporate/startup world where heavy-JS/React/SPA is everything.

Let me begin by stating that I'm not hating on either side of the fence -- I've been on both sides (and arguably, I still am on both sides, if that were possible).

As someone who works on a lot of side projects, I can very easily see the argument of keeping web sites JS-light, and not even dive into all the React stuff. Most projects don't necessarily call for it except for certain very specific things. (I actually do not use React on any side projects of mine, and still stick with jQuery.) On the other hand, after having joined a JS-fullstack startup this year, I can see that an article like this one is completely speaking to me/us. All I can say is, without the giant background context of working on a monolithic fullstack JS codebase, none of it makes sense; but when you're in such a job, everything of it makes sense.

I think it's so weird that many people on HN can't fathom a website being more complex than Medium. I've spent the last 5+ years doing nothing but develop data-heavy visualization apps. The alternative is not building a website without JS, it's building a desktop application using Swing or QT.

The problem is that most of the "bad" JS violators aren't building data viz, they're doing something much less complicated with the same tools.

Edit: the article mentions CNN, which is a mostly "static" site, but has enough JS to take 13 seconds to load on the "average" phone.

The counter-problem is that the "solution" that is peddled is to have pages that run perfectly with JS disabled rather than advocating for better usage.

> I've spent the last 5+ years doing nothing but develop data-heavy visualization apps.

Those aren't what this article is talking about though, For a huge client facing desktop web app, you can load things up front, expect the user to wait a bit, and then off you go.

But imagine if every page on HN took ~15 seconds to load. Heck the reddit mobile experience right now is that the comments section takes 4-5 seconds to load, and sometimes it doesn't load at all. Of course it is instant in their mobile app, and also instantaneous in their legacy mobile view. (Which makes me seriously question what in the world the modern mobile site is doing.)

Most content is temporary and short lived. Caching a script does next to no good if I only ever visit a site once or twice a month, I'd prefer there not be a script at all!

In regards to content, HN is one of the most valuable sites I use. The JavaScript is so tiny as to be inconsequential.

Give me a CNN.com that is as responsive.

I know your request is tongue-in-cheek, but here you go:

http://lite.cnn.io/en

an old fashion img tag at top and I'd be delighted.

Need to resize the browser window to get a good column width, but that site is fast.

(pure black on pure white also isn't easy on the eyes, but plain ol HTML can change that as well! :) )

Which is a pleasure, because I can go all the way down to OS APIs if needed and don't have to bother with browser rendering engine quirks and differences in how they understand the whole Web stack, sometimes even on the same browser just different versions.

The only way to achieve something similar on the Web is to stick with canvas and WebGL.

I don't see it as any different than the other disconnects between "what I want myself" and "what I get paid to do".

It's not unlike other fields. A composer who gets paid to write jingles for TV commercials won't listen only to TV commercial music. I once talked to an award-winning industrial designer at Fluke who admitted he couldn't care less about test and measurement, and didn't even know Ohm's Law. Michael Caine was paid $1M for "Jaws III", and says he's never watched it.

As a user, I avoid JS-heavy web apps (I think even StackOverflow has way too much JS). As an employee, if my employer (when I have one) wants me to build that, then that's what they get. HN gets responses from people wearing both hats.

"everything of it makes sense"

No it doesn't. Because you are obviously not implementing something that is meant to be used by a human being.

That load times are measured in multiple seconds even on a 4G phone is mind boggling.

You don't have to be combative. I agree with you.

The article is advocating for JS developers to be aware of what makes their SPA react JS app heavy and load slowly. I'm saying that an article like this only makes sense when you have the full context behind working on a SPA react JS mono codebase. If you haven't worked on one, it all sounds like gibberish and your mind just goes off to wonder "why even build this heavy react JS app to begin with when you could build a site without JS".

Reply on news.ycombinator.com