Multi select in particular feels like it's stuck in the 90's.
Also select's lack of consistent search capabilities is painful.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
https://bradleytaunt.com/dynamic-checkboxes/
Sticking to HTML and CSS won't necessarily get rid of this - new stuff is being added to CSS all the time, in particular. And browser support is just as patchy.
All browsers seem to have bugs with it. I also don't understand how it's essential.
CSS unfortunately doesn’t work that way, so apart from graceful degradation you’re out of luck.
I wonder whether this phenomenon is driven by HTML, CSS, and JavaScript being such lacklustre tools for building applications?
Many things that are completely reasonable to deal with in any “native” stack (animations, local storage, offline access, hardware access, accessibility just to name a few), while usually possible with a web stack, are often unnecessarily difficult or awkward.
Things are improving fairly rapidly because of the insistence that everything should be web based these days, and I could totally see that driving people to the bleeding edge.
I mean hell, I do it myself. I’m a web developer, and when reading about shiny new features I’m often eager to start using them ASAP — especially when it would replace a bunch of kludgy JavaScript I’d been relying on previously.
Most web pages will not need any JavaScripts, although some might need it. And in some other cases, optional JavaScript might help, such as to auto-fill or validate a form, in which case the form will still work with JavaScript disabled. (Also note that, for example, Lynx does not implement JavaScript.)
For some of that, my idea of a <widget> element might help a bit. It would improve performance, allow better user customizations, allow enabling some functions that would previously require JavaScript even though JavaScript is disabled, and is compatible even with browsers that do not implement <widget>.
CSS is also overused, although even if you use it, you should try to also allow working without CSS in cases where such a thing makes sense (which it often does, although not always). (CSS styles often just make stuff worse in my opinion anyways; that is why I put in my own CSS codes for stuff.)
I think, the end user need to have enough ropes to hang yourself and also a few more just in case. The entire control of the interface should be controlled by the end user.
Also, these web pages and HTTP(S) are rather overused anyways. There are other protocols, such as Gopher and Telnet and SSH and NNTP and IRC, which are better for some things (and worse for some things, too, I suppose). (But multiple protocols and multiple interfaces can be offered if wanted, anyways, I suppose.)
Only for certain things. A lot of web browsing is still pure information-consumption. The "native apps" are also turning into effective webapps, thanks to Electron and the like.
Even this site, which is interactive, doesn't require JS to use (it provides some enhancements, but the site is still quite usable without.)
[0]: https://www.reddit.com/r/programming/comments/ar1qj1/_/egl52...
You can watch IO talks from Android, Chrome, Flutter where the presenter eventually throws some jabs at other competing stacks as if they aren't from the same employer.
Where I work, departments bill each other. Sometimes, two departments develop competing tools that are third department could make use of. Instead the third department use an off the shelf tool because the "license" for the internal tools is too expensive.
At these scales, companies are almost like states. A group of entities with shared services but otherwise working independently.
No it isn't. Competition with native apps is the completely wrong way to think of it. The web should complement native apps.
Drop those apostrophes - a web developer is a completely valid, skilled profession.
Web apps unequivocally compete with native apps, that is a fact. I prefer the Slack web client to the native version. I use Google Docs instead of Microsoft Word. I use Google Drive, iCloud, Google Photos etc. instead of my own harddrive.
To think that web apps don't compete with native apps is simply untrue.
Slack doesn't have a native version, does it? They have a desktop client, but that's just the web version wrapped inside Electron.
A web developer, doing what they know what to do on the web, is a legitimate developer.
A web "developer" that only knows webdev, doesn't have the skill or will to learn anything else but webdev, insists on splurging web crap as "apps" outside of the web—that's, to me, is not legitimate, and "dev" worthy.
I'd say it starts with dialing back the "new feature/change fetish" that a lot of web developers have. Yes, I know some things simply can't be done without a JS webapp, but not all and probably not even a majority, so if HTML and CSS will do the job fine, then so be it; and even if it needs to use JS, it likely doesn't need to be latest-browser-only JS either.
The constant "X is bad, use Y; no, Y is bad, use Z; no, Z is bad, use..." churn and that "push the web forward" trendchasing seems to be so entrenched in "modern" (there's another buzzword) web dev culture that I wonder if Google/Chrome is responsible for cultivating and propagating it, because it's not quite as endemic in other areas of software and also helps Chrome keep its monopoly, since it keeps the target moving and beckons at others to "catch up".
I think web developers need to adopt a more "do what you can with what you have"/demoscene-ish (for lack of a better term) attitude and not the silly "I could do it with just X, but I'll use Y because it's newer/better-but-I-can't-explain-why-and-everyone-else-is" that really just assists Google's monopoly. In other words: Writing a webapp that could work over 20 years of browsers may not be as hard as it sounds (I've done it --- and I'm not even a web developer --- which might be the reason why...), and you will definitely help browser diversity that way.