3 ms·
This, this, so much this. We owe it to our users to provide all of them with a good experience. We also owe it to ourselves to write good, clean, maintainable
by zeveb 10y ago
This, this, so much this.
We owe it to our users to provide all of them with a good experience. We also owe it to ourselves to write good, clean, maintainable applications. The wonder of it is that very, very often if we write RESTful apps then progressive enhancement just falls out naturally: a GET request with some JSON Accept header will return data; with text/html it'll return data, and possibly a form to update it; a POST with some JSON Content-Type will DTRT, and so will one with application/x-www-form-urlencoded or multipart/form-data.
Why wouldn't one do that?
Of course, the user experience of such an app isn't as great as a singing, dancing single-page app (SPA). But a user experience is better than no user experience, which is what offering only an SPA provides.
It's just sloppy to require JavaScript and CSS to use a web site. It's particularly sloppy when that web site is composed of documents.
- mattnewton 10y ago> Why wouldn't one do that? There's a litany of reasons, but they all basically boil down to it's more work than just picking one solution that you think most people will use and executing on it well. Those users usually get a better experience and the pointy-haired boss is happy you shipped so fast. I didn't have the luxury of doing any of this until working at my current Big Co. web job, where accessibility is non-negotiable and we actually take steps to make sure everyone can use our sites. But even then don't serve pages that work without javascript half the time.
- borplk 10y agoFor government websites I can understand it but for commercial stuff I think this attitude of "everyone must be supported at all cost" is nonsensical. Where do you draw the line? Do I have to also support people who prefer to use command line text-based web browsers? Before you know it we'll have someone say "Oh I work for a bank, we have HTML disabled here. Can you make it work without HTML?" give me a break.
- zeveb 10y ago> Do I have to also support people who prefer to use command line text-based web browsers? Yes. The web is about linked HTML documents: if you don't support lynx, links, elinks, w3m, emacs-w3m & eww then you're honestly not doing Web development properly. You have to do more work to not support them, because writing plain HTML + forms is the baseline. > Before you know it we'll have someone say "Oh I work for a bank, we have HTML disabled here. Can you make it work without HTML?" give me a break. That wouldn't be using the Web anymore.
- matthewowen 10y agoMany people aren't building websites. They're building applications which target the cross-platform runtime and APIs provided by modern web browsers.
- TeMPOraL 10y agoMany of those people should not be building applications. Boilerplate startup landing pages, blogging platforms and e-commerce sites should be websites, as they always were. As for those who really are building web applications - well, those are separate beasts. Nobody expects to run Google Docs or Gliffy properly in lynx. But I do expect my banking site to run in a text browser, because there's no valid reason it shouldn't. (Yes, I understand the business reasons for the current sad state of the web. I also believe those reasons are things one should be ashamed of.)
- aarongustafson 10y agoThere is a line: support vs. optimization. Support everyone with a browser & internet access, optimize for the stuff that has the greatest market share or where you can do the most good and stand a good chance of having your dependencies met.