Hacker News Reader

Comment by untog | Hacker News Reader

I feel like it’s possible to be way too puritanical about these things. Absolutely, JS bloat is an issue. But JS isn’t inherently bad, and removing it can make the user experience worse, not better.

Take HN, for example. The [-] button to collapse a thread is really useful. But if it had to POST back to the server and reload the entire page just to hide a thread I wouldn’t use it anywhere near as much.

View on HN

Progressive enhancement : make your website work with no javascript and no CSS trick (CSS is not for behavior). Then use JS to add dynamic behavior on the client.

This is the approach I have always tried to take. Unfortunately it seems that most employers now want Angular/React/Vue experience so you wind up with devs shoving it in to projects where it's not really needed just to get that experience. Such is the state of Resume Driven Development.

"No JS" sounds better than "Almost no JS except for a line or two for minor usability enhancements."

What's the difference between a site with no JS and a site that has a few lines of inline JS to handle expanding and collapsing comments? Probably nothing, but one sounds better. It's just like how you never hear people bragging about being almost-completely-vegan-except-for-that-one-egg-sandwich-a-month.

People are never impressed by my strict fasting-between-meals regiment̶.

I, for one, am impressed that you have an entire regiment.

A platoon is the best that most of us could hope for.

Strange. I find people are quite impressed with my one meal a day intermittent fasting.

You can't disable javascript in a browser, but leave "a few minor javascript improvements". So the difference is between allowing all the ad tech, surveillance, malware or not.

Which is fine. If all your JS is doing is adding a few QoL features like collapsing comments, then your site will still be completely usable if the client chooses to not run JS.

Those that run JS will still load probably just as fast as those without it even if it's not truly "no JS."

You can do a lot more than nothing about isolating unwanted javascript. Ublock origin, noscript, privacy badger, use one of many curated hosts files, etc..

If you disable JS on HN that button goes away, but you can still up / down vote. I like that, I wonder if the [-] could be implemented in CSS though, I feel like it can.

Seems like it could be done with a checkbox and some cash. I'm sure someone could figure it out.

The article has exactly this scenario as an example of where pure CSS can replace JS.

It could be done using `input:checked + sibling` selector e.g. like this: https://jsfiddle.net/6bgemn0s/

For something fancier it would be possible to style a label with appropriate for="" attribute and hide the checkbox completely, then even apply some transitions: https://jsfiddle.net/6bgemn0s/1/

https://jsfiddle.net/gaby_de_wilde/ye95zcao/29/

I believe using a checkbox element and the :checked selector alongside siblings matching would do the trick.

That would do nothing for screen readers thus compromising accessibility.

I've done / seen so many hacky things in web dev I would be surprised how many websites even work properly with screen readers.

Such is the sad state of web development.

As I do hacky work on the web I sometimes wonder why specific UI elements don't exist yet instead of people being forced to hack other elements to do things the web doesn't support. I can't remember a good example off the top of my head currently sadly.

If you use the checked state to of a checkbox to change the display property (i.e. toggle between none and initial), that will change the content's visibility and its availability to screen readers.

Could you just nest <details> elements?

I have a similar aversion to JS as the author, but unfortunately it's still the best tool for the job in manipulating the DOM.

Phoenix LiveView looks really cool. Under the hood though it's injecting JS that diffs the current DOM and the new DOM and renders the changes rather than the entire tree. At the end of the day, it's still a JS enhancement.

Yes, a JS enhancement that weighs less than 30 KB. I’ll take that any day over a >100 KB React app.

...and end up keeping a websocket open, transferring far more than 30kb or even 100kb in state changes over the lifetime of the app, while also using up the devices battery and data limits? friendly reminder that 100kb of js can be cached on the device, while a stateful websocket obviously can not.

While we're here, Server Sent Events (SSE) over HTTP2/3 (which websockets doesn't support) is apparently more battery friendly for phones. Symfony recently got support for SSE using the mercure protocol, it would be lovely if more backend frameworks had first class support for SSE.

It definitely seems like two extremes right now. Personally I think we should strive for minimalism when working with JS. Things get bloated very quickly when non-technical departments have requests (tracking, A/B testing, ads, etc). These things often cannot be pushed back on.

My feelings are that front end devs should focus on performance by reducing what is in their control -- basically dependencies and overengineered clients

Looks like you didn't read the article.

I was responding to this:

> Your frontend can't crash if you don't use JavaScript. HTML doesn't throw exceptions. Less code is always better.

Less code is not always better.

I'm aware that the example I chose here is similar to the checkbox trick the article outlines but I'm using it as an example of how JS can improve UI, not as a direct rebuttal to the article.

The checkbox trick itself sounds like an accessibility nightmare, so again, you're not necessarily serving the user's best interest by doing code parkour to avoid two lines of JavaScript.

There’s also nothing stopping you from generating broken HTML or CSS on the server that won’t be interpreted as anything useful by the browser. Or messing up your CSRF tokens so that your forms don’t work. Or having broken links.

Puritanical, and many of the options seem superficial / impractical.

The point about form validation is always made in these types of articles and every time I do form validation I find the built in options too limited. I've used them here or there, but they're hardly a snap in replacement for anything.

And validating them in the backend isn't really viable either if you remove js entirely. No way to send the input to server without a page refresh, which would break the workflow

Agreed. There's a lot of "nothing happens" events if you remove JS and that's very user unfriendly.

The author acknowledges that (see "Coming Clean").

The author also addresses your specific example (see "The Checkbox/Label Trick").

I've never used it because its not to the left of the comment header where it belongs. Voting should be on the right.

I starting thinking that but having read the article he actually did use javascript in a couple of places.

Reply on news.ycombinator.com