Hacker News Reader

Comment by gfodor | Hacker News Reader

Good engineers don't make judgements like this in a vacuum. Design choices are about tradeoffs and are not inherently good or bad. For a system like gmail where you have tens (hundreds?) of millions of daily active users, coming from countless different types of clients, a mode that eliminates JS dependency seems critical.

Most sites are not gmail, they're not even close. Decoupling JS, particularly if it's done just to ensure the tiny fraction of people who disable it can use the site, can rightfully be very low on the priority list if it is a non-trivial engineering cost.

View on HN

While there is sense in what you are saying you don't have to create the problem for yourself. Don't create situations where you rely on javascript in the first place.

Granted there are some cases where it is an acceptable decision to get yourself into the problem (because the advantages you gain by doing so are worth the costs). But often companies just create the problem for themselves for no good reason - they could have avoided becoming dependent on javascript to do stuff they didn't need to do in a way that broke (degraded un-gracefully) if javascript wasn't available.

I said that if the functionality of a website is broken without JS there were poor design choices made; not that a web developer should focus on people who disable JS.

You can't seriously be implying it takes more time to write functional HTML than JS. One requires the other to work, when you flip it around it's bad design.

By that standard GMail is a bad design. They have a completely different UI for users who do not have JS. This is almost surely an enormous amount of work to build and maintain. To me this tradeoff usually only makes sense when a sizable % of your users are going to use that alternative.

rightfully be very low on the priority list if it is a non-trivial engineering cost.

yeah like writing basic html is so hard and more expensive than maintaining piles of js code.

But it's not just HTML and CSS - you need to create a completely new user journey because you can't make asynchronous requests to the server. In some instances you may even need to manage server requests completely differently. UI elements may have to be changed as well as you can no longer rely on Javascript to animate them.

You're essentially maintaining a second UI that is divorced from your main UI. There's significant cost in that. It's the same reason most sites don't support IE6 anymore.

Reply on news.ycombinator.com