Hacker News Reader

Comment by Taig | Hacker News Reader

I really appreciate that kind of focus and dedication. I recently had another dive into web development after a couple years of absence and was pleasantly surprised by tools like react. In combination with server side rendering it allowed me to serve a solid/usable HTML page with no JS required. When I started pulling in components from popular Material Design libraries, though, I realized that nobody thought about progressive enhancement even for a second. Rather than serving a plain `<select />` and then progressively enhancing it, all I got was an unusable mix of HTML tags and styling. It's a shame that even down at the library level people don't care about progressive enhancement. Are there any (react) projects that try to do better or is the mantra more like: react without JS is nonsense?

View on HN

There's no substitute for caring, and unfortunately much of the contemporary JS/Web world just doesn't care about these issues.

> There's no substitute for caring

Or for being paid, progressive enhancement is more work than not doing it and if the client/manager/… doesn't want to pay for it… the dev is unlikely to bother doing it on their own dime.

The 80 / 20% rule applies once more - why spend 80% of work on the 20% of users that would benefit from progressive enhancement? Unless those 20% of users generate 80% of revenue, which in all likelihood they don't.

I'm a startup guy so of course I understand this, but on the other hand accessibility is one of those things that takes practice and know-how, so if you never do it of course it seems like this giant mountain to climb. However if you make it a priority, it's not 80% of the work, more likely it influences how you do things, so maybe you spend 20% more effort and end up with a little less whiz-bang. There is a cost, but we shouldn't paint it as an insurmountable thing. This is why we have the ADA, so that people with disabilities don't have to go through life as second-class citizens.

You only have to handle the 20% of users as a special case if you have gone and made some technology choices that excludes them. There is nothing inherent about the internet or web that says that needs to be the case.

A rephrasing might ask why we make technology choices that exclude 20% users?

If we're not able to produce a single page web app that reaches 100% of users, that's cool... just make a many page web site without lots of JavaScript that does.

My biggest gripe with this, though it seems sensible on the surface, is that these numbers are often simply pulled out of someone's ass to argue their stance. Often a manager or a front-end person who just wants to work with the new hotness. How do we know 20%(or whatever the number is) is at all a relevant estimation? Who are the demographics that this number makes up? Why is it important to isolate them or exclude them? Furthermore, at best this number often only accounts for the known people that the product is already not serving or poorly serving. Not the people who bail immediately upon realizing that this service isn't for them because they opted against an inclusive strategy.

I did some actual math on progressive enhancement costs vs. graceful degradation in consideration of reach: https://medium.com/@AaronGustafson/the-true-cost-of-progress...

Too right - PE costs more and unless explicitly specified and understood it's not going to be done.

PE is the default of how HTML, CSS and JS work. You have to go out of your way to screw it up. Which is precisely what the whole web world delights in doing now.

> PE is the default of how HTML, CSS and JS work.

PE is not what the client pays you for.

> You have to go out of your way to screw it up.

Hardly. The shortest path to the whizzbang the client wants will break PE all on its own.

Quite a lot of websites don't have clients that pay for design - in many cases (especially SaaS), the person wholy responsible for the look&feel target is your colleague the designer, sitting in the office next to yours.

Come to think of it, given how most websites are designed, I'm starting to think we're making a mistake with sticking to HTML/CSS/JS. We should move to "executable Photoshop image" format - so that the beautiful magazine-like layouts made by designers could be implemented without a shit ton of hackery and bloat webdevs have to put nowadays. We could also push some security and sanity decisions into the format this way, so that the tool itself would tell the designers they can't (or shouldn't) do something.

(I'm only slightly sarcastic here.)

> Quite a lot of websites don't have clients that pay for design - in many cases (especially SaaS), the person wholy responsible for the look&feel target is your colleague the designer, sitting in the office next to yours.

Call them boss, call them stakeholder, call them prospects, call them whatever you want, point is, progressive enhancement requires actual hard work, it's not the default state of things when you move beyond the "research paper" format of having a bunch of paragraphs of text interspersed with section titles on a completely static page.

I still disagree - I made websites back in the ancient days when people used to generate HTML server-side. Things worked perfectly well. Current proliferation of heavy JS frameworks buys us nothing over those times, but wastes more electricity and time of our users.

Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily, it's just the default because that's how he web started. I'm not saying we should skip progressive enhancement but there's truth to it being more work (when compared to how easy we can do things without it using JS only), regardless of how the web was originally designed to work.

"Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily"

I used to throw them together in Frontpage or Dreamweaver with a few optional scripts. Scripts for things like page counters or menus I just cut and pasted off dynamicdrive.com followed by tests in several browsers. Backend handled forms and such. Worked on every browser, loaded up fast on dialup, and everyone knew what my HTML/CSS code did without training. Can't say that about most of these sites and frameworks these days. So, I'd say it's easiest and a sensible default.

To be clear, I'm not critiquing complex, web applications that truly need advanced tooling client-side. I'm talking about 90+% of what's out there that just publishes content with minimal dynamic elements needed.

It’s easy to knock something together with JS. It’s very difficult to make it work well, certainly in our experience harder than having reasonable fallbacks.

Reply on news.ycombinator.com