undefined | Better HN

0 pointsjoshstrange10y ago0 comments

While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was. I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost? I could, given time, recreate the entire platform I code on every day to be js-free but I'd be fired for pissing off clients. I could probably even reimplement our google map that you can draw a polygon on without JS but it would take a LOT more time and it would be so painful to use that it wouldn't matter.

I don't want to say people who rely on screen readers don't matter and I think it can be fixed for them. However people who disable JS really shouldn't matter to you unless you are Facebook, Google, Apple, Amazon, etc. Even then some of those sites don't work without JS which could (Like google drive). It's simply not worth the resources to support a small group of people who have knocked out the foundation of a house and are expecting it to stand up just fine. "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.

When it comes to the web you need to optimise for the 98% not the 2% (I'm being generous with that 2% number BTW) especially when that 2% CHOOSE to create this problem for themselves.

0 comments

1 comments · 1 top-level

yellowapple10y ago

> While I fully agree that Trello could be js-free I don't think either of us would have known the name "Trello" to talk about today if it was.

I disagree. Very little (if any) actual functionality would be lost. The differences would be more-or-less cosmetic and (to a limited extent, though I think this would be positive rather than negative in many cases) ergonomic.

> I understand that you can degrade your web app to the point it works without JS but at what (UI/UX) cost?

None if you design your app with progressive enhancement in mind. Drag-and-drop and other forms of "interactivity" could be added onto the non-JS version rather easily.

> It's simply not worth the resources

It costs resources if it's not something you consider right from the get-go.

In other words, it only looks like it would use more resources because you're coming at this from the perspective of "okay, here's a JS-heavy app; how do we make it JS-free?" instead of the more efficient perspective of "okay, here's an app solely in HTML, CSS, and Rails; what JavaScript should we add to make this cooler?". The former is like trying to learn how to ride a motorcycle before learning how to ride a bicycle.

> "Screen readers don't play nice with js frameworks" (which is not true across the board) are not an argument for no-js, it's an argument for building better screen readers.

I agree with this. That doesn't mean that the existence of Javascript can always be assumed.

j / k navigate · click thread line to collapse