209
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 Oct 2024
209 points (97.3% liked)
Firefox
17302 readers
49 users here now
A place to discuss the news and latest developments on the open-source browser Firefox
founded 4 years ago
MODERATORS
This seems to be the argument that the web was designed for documents and that we should stop trying to shoe-horn apps into documents. Hard to disagree at this point, especially when the app in question is, say, a graphics tool, or a game. I still think that, in the case of more document-adjacent applications, a website implemented with best-practices progressive enhancement is about as elegant a solution as is imaginable. Basically: an app which can gracefully degrade to a stateless document, and metamorphose back into an app, depending on system resources and connectivity, and all completely open source and open standards and accessible. That was IMO the promise of the web fulfilled: the separation of content from presentation, and presentation from functionality. Unfortunately there were never more than a tiny minority of websites that achieved this. Hardly any web developers had the deep skill set needed to pull it off.
I was once skeptical about WASM on the grounds that it's effectively closed-source software - tantamount to DRM. But people reply that functionally there's not much difference between WASM and a blob of minified JS, and the WASM security can be locked down. So I guess I accept that WASM is now the best the web can hope for.
I'm personally of the opinion it's not so much an issue of a lack of talent that prevented graceful fallback from being adopted, but simply the amount of extra effort necessary to implement it properly.
In my opinion, to do it properly you can't make any assumptions about the browser your app is running on; you should never base anything on the reported user agent string. Instead, you need to test for each individual JavaScript, HTML, (or sometimes even CSS) feature and design the experience around having a fallback for when that one singular piece of functionality isn't present. Otherwise you create a brand new problem where, for example, a forked Firefox browser with a custom user agent string doesn't get recognized despite having the feature set to provide the full experience, and that person then gets screwed over.
But yeah, that approach is incredibly cumbersome and time consuming to code and test for. Even with libraries that help with properly detecting the capabilities of the browser, you'll still need to implement granular fallbacks that work for your particular application, and that's a lot of extra work.
Add to that the fact devs in this field are already burdened with having to support layouts and designs that must scale responsively to everything ranging from a phone screen to a 100" inch TV and it quickly becomes nearly impossible to actually finish any project on a realistic timeline. Doing it that way is a monumental task to undertake, and realistically it probably mainly benefits people that use NoScript or similar -- so not a lot of people.
Actually, it doesn't just benefit "geeks who use NoScript". The original audience for accessibility was disabled users, which is why some of the best websites ever made are for government agencies. But sure, they don't count much when there's a deadline to keep. I know what you're talking about, I know that progressive enhancement and respecting WCAG etc is just time-consuming and time is money. I was in the meetings. But it's also just hard, for the reasons you describe, and few developers have ever been able to do it. Maybe precisely because the skillset straddles different domains: not just programming but also UX and graphic design and information architecture. The first web developers were tinkerers and lots of them came from the world of print. Now they're all just IT guys who see everything as an app. Even when it's in essence a document.