Hacker News Reader

Comment by sudodevnull | Hacker News Reader

I'm very much of the opinion that progressive enhancement leads to lowest common denominator and you should just do a static MPA (nothing wrong with that). Modern browsers are a combination of HTML+CSS+JS and you should just embrace that as what modern hypermedia is. We aren't fighting against the browser. If you want just links and forms, you should just do that and have less code to maintain. But in my experience that's not what most are looking for in their apps.

View on HN

> But in my experience that's not what most are looking for in their apps.

What are they looking for (in your experience)?

In my experience, most people use an app (website) to solve some problem (buy something, pay taxes, whatever). They care more about functionality than how smooth the loading animation and transition was. Progressive enhancement seems like a very good way to build something people actually use (and rely on).

Progressive enhancement is about accommodating JS being disabled. You have missed, in your description of what users care about, anything about disabling JS. Having JS disabled is a preference observable among Opinion Havers which crawl out of the woodwork on HN, but not observable among your target audience, even when your target audience is mostly HN.

Progressive enhancement isn't about supporting the minority of users that disable JavaScript. It's about sound engineering and building a robust system that is tolerant to errors. A system that can fail gracefully.

There's nothing wrong with using JavaScript. There's nothing wrong with depending on JavaScript for specific functionality. However, I don't think it's acceptable to completely break down if that JavaScript fails to load.

With SPAs and "modern" web development practices, it's all or nothing. Either everything works, or nothing works.

Not with things I build.

Have you ever given an iota of thought to how your website looks when the CSS doesn't load? Contemplated arranging elements into `<table>`s to preserve some semblance of formatting, crammed some truly necessary styling into `style=`? If not, then the users that disable JS are the primary driver of thinking about how your website looks when the JS doesn't load; any two given files are about equally likely to not load, JS isn't privileged here compared to CSS (and is much harder to gracefully handle its absence).

I do a fair amount of thinking around all failure states (CSS included).

I think you may be overthinking the appearance aspect of a failure state. The application doesn't need to look the same when CSS fails to load. However, the application should be functional.

This thinking carries over to the backend as well. My application server doesn't require all services to be up and running. Instead, it's able to query and tell what is working and what isn't. That information is then bubbled down to the UI in one way or another. That may mean certain functionality is unavailable (ex, if solr isn't reachable then search is disabled).

My impression is people really like frameworks because they all ultimately end up with a plugin system. Then the use of the "the framework" really just becomes "gluing a bunch of plugins together."

I've never liked where those code bases ultimately end up, which seems to be just a twisted maze of hacky solutions to make a bunch of poorly aligned code to work together.

Reply on news.ycombinator.com