Time and again, people argue as if everyone was just trying to style their blog. HTML isn't only used for documents that roughly look like a printed page, but also for actual web applications. Applications don't map too well onto HTML, and while the pedants are hung up on separating content from appearance, the rest of us is busy working on actual software.
If nobody "does it right", maybe right is just wrong?
> If nobody "does it right", maybe right is just wrong?
It is certainly possible. However, what I have seen in the industry is that there are very few real CSS experts among people who are "busy working on actual software". Few people who have thought deeply about their methodology, the problems that it solves, and the problems that it introduces. And, on the contrary, there are too many people who either regard html/css as a playground for juniors, or are too happy to copy what other people are doing. In such context, it is very difficult to have a well-informed discussion about what is "right", and what is "wrong".
Most of the heavy lifting of modern web applications is still on "userland" JavaScript frameworks instead of the browser, because lots of dynamic interactions can't really be modelled with HTML alone. For example, consider creating a dropdown menu to select a contact, displayed with an avatar, name, and email as a subtitle. Doing that right—so it is accessible to screenreaders, has dynamic completions fetched from a server, adjusts to different output devices—is not only quite complex on its own, but also requires reinvention of several things, like an input field with a custom select box. Support for modal dialogs just became widely available two years ago. Two way data bindings between dynamic state and HTML elements still requires complex Javascript code. Drag and drop is a pain. Input elements haven't really caught up to the last twenty years.
And while HTML does provide capabilities to register custom elements, they don't really catch on for a reason.
I will say HTML is flexible enough to be used for just about anything, but it certainly is better suited for text documents than web applications.
The OpenUI folks have been doing the angel's work of upstreaming various core components. And doing a great job. Popover & dialog are both coming along nicely. https://open-ui.org/
For a while it was all left to appdevs to build a UI toolkit out of basic HTML but OpenUI really has been driving the standard forwards.
Why would you need a custom selectbox in the example you provided? Because you could use the menu element with the popup API and AJAX if I understand your example correctly.
On a sidenote, do you know about HTMX? If so, what do you think about it?
The popover API is pretty much brand new. Sure, that would probably work. That misses my point, however; lots of basic building blocks of modern UIs users expect are missing from browsers today (or on the popover case, yesterday) and need to be added manually.
HTMX is the same story—it's what HTML could be, but isn't, unless monkey-patched in userland.
Yes it's still and always evolving and we need less and less of the heavy JS frameworks to produce interfaces. HTMX is way lighter than React, for instance. And from what I know, it's enough for many, many app use cases.
I'm not sure if I totally agree with this take, but if it's true that's a great reason to not build web applications. If the medium isn't right for the use case, why force it?
Because it's the only ubiquitous, actual multi-platform delivery channel we have. Web browsers are available on pretty much any device in the hands of users right now. And while HTML doesn't map too well, it is certainly good enough—there are simply no viable alternatives anyway, so people are going to use what is available.
Do you think it would be as good of a delivery channel if browsers focus more on features needed to build applications rather than to view documents?
In my experience, application-specific features are really what made the modern web complex and bloated. Building applicstion frameworks and operating systems is insanely difficult, much more so than building a standard document format and rendering protocol.
Can the web be used for applications? Absolutely. But my argument would be that it almost never should be. Native applications will always handle that better, and though there isn't a great cross platform solution for applications today we'd be better off building that than shoehorning that usecase into the web.
But that just doesn't match the way people use the web, like it or not. Building native applications just isn't worth it for many businesses: You need to adhere to compliance and security, different platforms and operating system versions, keep track of different system APIs, handle a giant matrix of build targets, prepare and maintain installation guides with possibly required client SDKs and dependencies, employ specialists for every platform... it's an extremely wide field.
Compare to the web: A single platform to build for. A single API to keep track of. A sandboxed runtime environment with zero dependencies, available on virtually every client system. A way to communicate with your servers that works, even in tightly guarded networks. A giant amount of documentation, available developers, and resources.
In an ideal world, I'd like to see native applications for everything. In the world we have, constraints prohibit that. So for better or worse, the web has to be mended into the universal application runtime environment we use it as.
I thought that exact thought a while back, so I decided to fill in one of the gaps in my application arsenal by building a native application that does nothing but display a grid of images quickly. It's a gallery app.
After trying to make the most basic version of this app I can imagine, here's my takeaway on desktop application development: it sucks. Badly. Displaying a grid of images in a webapp is a few lines of javascript and a few lines of html. In most native application development systems I've seen, it's 20 lines of code just to open the window.
To be fair, the web makes easy things easy and hard things impossible, whereas native desktop applications make easy things hard and hard things possible. But, I definitely see now why most developers prefer to build things in electron.
What's an easier/better way to style an app then? It sure isn't easier with QT (unless you use QSS or QML, both of which are inspired by how you'd build an app on the web).
Easier and better really need context. For me, styling a UI in CSS is easier than manually coding a UI for an iOS app. The visual UI builder in VS Code is pretty damn nice though, and I find that easier than CSS for complex UI.
If I need to do anything related to complex state changes, animations, page navigations, etc I'd also much rather use a native applications built with that scenario in mind. There are a ton of things we simply can't do with CSS - we're starting to see experimental features for simple page animations but they're very limited and manual. I worked on the Windows Phone UI framework back in the day, that was over a decade ago now and the kinds of navigation animations you could do with a few properties and flags was light years ahead of web page transitions today.
Think about it like this: In the beginnings of Web 2.0 people used tables for their layouts. The experience was abysmal, but it worked and allowed quite sophisticated layouts, remnants of which you can still find sometimes today. HTML has changed since then, and lots of things have improved, but its roots undeniably lie in marking up text documents, not applications.
I think that mostly shows in the awkwardness of transferring user interface widgets over. Stuff like popover, modals, combo boxes, toggles, drag and drop, sticky elements, etc. have either just recently become possible or require manual efforts to get right. And that, in my opinion, is an effect of shoehorning application primitives into a document environment.
If nobody "does it right", maybe right is just wrong?