The unreasonable effectiveness of simple HTML
1–10 of 387 posts
Re: The unreasonable effectiveness of simple HTML
#2Re: The unreasonable effectiveness of simple HTML
#3Client-side javascript is underrated. We put simple websites in embedded devices with shockingly low memory/flash. They're for configuring the device. The pages are pretty serviceable with html controls, color schemes, logo etc. Embedded javascript to make them responsive. A couple of kilobytes total html.
Re: The unreasonable effectiveness of simple HTML
#4The 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.
Re: The unreasonable effectiveness of simple HTML
#5Client-side javascript is underrated. We put simple websites in embedded devices with shockingly low memory/flash. They're for configuring the device. The pages are pretty serviceable with html controls, color schemes, logo etc. Embedded javascript to make them responsive. A couple of kilobytes total html.
And what if the device can't or won't run JavaScript?
Re: The unreasonable effectiveness of simple HTML
#6Earlier quoted context omitted.
And what if the device can't or won't run JavaScript?
I didn't make myself clear. The embedded device is the web server in this setup. The browsing device (phone, tablet etc) runs javascript. You're right, no way a tiny embedded device runs javascript.
You've still got javascript requirements there on the browsing device, eating up more CPU/Memory/Battery than a straight HTML page would.
Re: The unreasonable effectiveness of simple HTML
#7Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…
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.
Re: The unreasonable effectiveness of simple HTML
#8Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…
Re: The unreasonable effectiveness of simple HTML
#9Earlier quoted context omitted.
I didn't make myself clear. The embedded device is the web server in this setup. The browsing device (phone, tablet etc) runs javascript. You're right, no way a tiny embedded device runs javascript.
"And what if the device doesn't run javascript" You've still got javascript requirements there on the browsing device, eating up more CPU/Memory/Battery than a straight HTML page would.
That sounds optional and a bit of JS for making things responsive certainly doesn't automatically create a CPU/Memory/Battery drain.
Re: The unreasonable effectiveness of simple HTML
#10The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unusable for disabled people.
Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them.
Making your site accessible isn't just a good practice, in the US, it is the law. Courts have ruled that the ADA applies to web sites along with any other type of business. A small sample of sites where people thought they could smash together super-fancy sites without concern for basic needs of users: https://www.atilus.com/top-10-ada-lawsuits/