In both scenarios, I'm trying to complete my task as quickly as possible while I still have a good connection. A simple HTML page (with JS layered on top for fancier stuff) would be plenty to get the job done. Instead you get hindered by sites that aren't optimised in any way for slow devices or slow internet.
Heard that Facebook before had "2G Tuesdays" where the product teams throttled their internal net speeds to 2G while browsing the site to see what it was like — that should be the standard for dev teams. The trouble is so many things are designed and tested by people on T1 broadband in a downtown office, but that's not the set-up of a majority of their users.
I wish. A T1 is 1.5mbit. CNN's front page is 6MB - 30 seconds at full T1 bandwidth.
How about when it is quite easy in many cases to support them, by using standard conform simple HTML?
Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is supposed to give you security, I need to allow scripts, to have a login. Otherwise there is only a background picture. Thank you very much, so helpful! And then when I allowed their scripts, guess what. A text became visible, which told me, that in general scripts need to run in order to use the page. How much fail is that? They don't know the noscript tag or something?
That's only today's anecdote. I see this kind of fail every day, except for the days, when I miraculously manage to avoid all badly designed websites. It is getting worse and worse, because web developers seem to find it normal to, by default, reach for JS, instead of thinking about how they can solve the same thing using just HTML and CSS for a second or two.
I think it is still worth pursuing simplicity in web development. For the earlier example: Rendering a login using JavaScript is not simplicity. It is unnecessary, silly, and exclusionary without need.
So my message is: If your service can be done using plain simple standard conform HTML(5), then use it. It will also almost always have less bugs and be simpler code to maintain. Information display does not require dynamic pages per se. Usually it does not and many many websites are about information display, not impossible to solve via REST dynamic pages. Nowadays properly designed static websites are faster than badly designed JS heavy websites, which render on the client-side. The bloat has become this bad already.
Even cheap, old smartphones support JS. You can have fast, efficient JS.
You know... this is true. I know this is true, because we had JS 20+ years ago on Pentium processors. It's possible to write JS that doesn't require multiple cores on a 2019 Ryzen...
But there are also the other sort of sites. You know the ones. Take a stab at which is more prevalent, and receives the majority of ire =[
This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have other priorities than removing JS from the login screen. It's not that hard to believe that scriptless login would fall fairly low on a team's priority list behind features more likely to drive revenue, etc.
From a purely economic point of view: if your competitor's website supports the visually impaired, and yours does not, then even though that's a relatively small market segment you're probably giving away 100% of it. And blind people have friends and family too, and they'll also send all of those people to your competitor.
In my opinion it's why it's especially important to have regulations here, free market won't save us because in most cases the ROI just isn't there. However this is wrong to abandon those people, thus we need incentives to force people to do the right thing.
Once upon a time, a younger engineer worked for a company that dealt with the DOD. The DOD wanted to upgrade their website, and as often happens, the lowest bidder was a giant company who could blacken the sky with lawyers. They worked and worked, and their deadline slipped. Finally, they made something that kind of worked, sort of, as long as the wind wasn't blowing too hard.
The younger engineer noticed that the new DOD website served webpages via carrier pigeon, but with more latency. As in, page loads often took minutes. He proposed to the lord of his domain: "your majesty, what if I crafted a robot to visit all of their pages and enscribe their lore into our own tomes, such that when your customers want the information, we can give it to them in milliseconds, and not minutes. Oh, and I can make the robot labor only at night lest the DOD get persnickety." The lord gave his blessing, and the younger engineer went away and made The Thing.
The Thing worked wonders, and there was much rejoicing among the many kingdoms. But lo, the DOD was not happy, for it made their contractors look as though a pack of jackasses. And so they sent a sternly worded missive: "cease at once, knave, or we shall cut you off from the river of nectar for all of time!" And the younger engineer's lord's voice quavered, for he knew that his own kingdom would starve if this were to happen.
But the younger engineer was cleverer. He noticed that the DOD's website could not be perceived by those who could not see, but his own website was beautiful to behold by both the sighted and those not. He proposed a plan to his lord, and his lord giggled for the plan was good and clever.
The lord sent a missive of his own, both to the Maker Of The Website and the DOD, saying:
"Alas, your own website cannot be perceived by those without sight, as are some of our customers. Our website can be. If you go away and stop sending threatening letters, our customers have agreed to behold the riches of thine data through our site as a proxy, and not file a lawsuit with an injunction that shall turn your website off tomorrow until you spend a few tens of millions of dollars fixing it."
And the Maker Of The Website shut the hell up about it, and the DOD formally approved the plan, and all were happy.
Except for the Maker Of The Website, of course, but lo, they were as though a pack of jackasses.
The younger engineer was celebrated, then moved away to distant lands with better pay.
The end.
But thank you for taking the time to recount this story, I'm glad good prevailed over evil!
How can government compel businesses to provide better experiences? Why, standards and regulations of course.
The vast majority of users will have even a rudimentary smartphone (some years ago I visited the Calais jungle to donate food and supplies, and whilst people were struggling to eat, they knew that a smartphone was a cheap, key thing to obtain and hold onto because they make accessing help and communicating with their support network possible) and or laptop that can handle some lightweight JavaScript and benefit from an enhanced experience.