But I also want just a document viewer. Great job building all that, developers of the world, now how can I read a news article or an email in a modern sense without a complicated machine executing code that’s not at all for my benefit.
I do very little on the web where I actually want there to be code running on my document.
None of those things require client side code other than an HTTP POST.
Some things yes client side code makes sense, like an appointment finder, and that’s fine, but such things make up a tiny amount of my internet activity.
Sure, but you are talking about a complete minimalist implementation, one that before all of this Javascript explosion, made people pull their hair out. For example you need javascript for dropdowns or form validation to begin with. I think there is a lot of stuff done by front end developers these days that people take for granted.
Drop downs do not require JavaScript. HTML has basic form validation and your POST endpoint needs to validate the form anyways, sending the form back to the user for corrections is not very difficult.
This is just the same argument as the comments upthread rehashed. In the absolute most minimalist, hair pullingly annoying implementation, that is correct. However the polish you are used to on dropdowns plus countless other controls you interact with every day require javascript.
> However the polish you are used to on dropdowns plus countless other controls you interact with every day require javascript.
I got one can do without the "polish I am used to". I'm generally fine with HTML form controls.
My problem with JavaScript frameworks is they are huge beasts that build their components out of non-semantic block elements. A button or text field is just a giant mass of divs and spans with events attached everywhere with one-off CSS. The browser is stuck doing tons of work in its single-threaded JavaScript engine to build and manage these components.
It's a lot of wasted memory and clock cycles to recreate a text field the browser already provides. It makes for a worse user experience, wastes my battery, and eats up my bandwidth. To me it's not polish but waste.
Ok, so when registering on a new site you don't mind waiting back to hear from the server after clicking submit, to find out your passwords don't match, or don't meet the required policy? That's fine. But the majority of impatient and perhaps spoilt users do. In fact I hear people these days complain violently about the most trivial UX issues on websites they visit. User's expectations are sky high.
Regarding the massive nestings of divs. Well this is computer generated HTML. It is ugly as hell, but browsers are well geared up to deal with it, it doesn't create any serious performance issues unless taken to stupid levels. The other side of the coin, with this rather ugly generated HTML, is you get a human benefit, a time saving efficiency. You can spin up a web page with React/Bootstrap in a fraction of the time it took you in the 1990s.
Emphatically no. The absolute vast majority of those "polished dropdowns" are horrible to use, and break all possible platform conventions (for example, not accessible or usable with a keyboard)
> countless other controls you interact with every day require javascript.
Very few, if any, "polished controls" used on the absolute vast majority of web sites require javascript.
Emphatically yes. The most popular UI framework's dropdown component, documentation reads as follows:
"Dropdowns are toggleable, contextual overlays for displaying lists of links and more. They’re made interactive with the included Bootstrap dropdown JavaScript plugin"
I do very little on the web where I actually want there to be code running on my document.