And there are plenty of other “layouting primitives”, all of which are quite cumbersome. And due to HTML encoding some form of semantic meaning only (though seldom used even for that), drag n drop tools can’t generate easy to read/modify output. Also, without js frameworks, you can’t really just embed another component into it trivially.
And I’m not trying to shit on web tech, JS has absolutely overcome its shitty past, and is quite a likable language nowadays, and CSS is an extremely powerful and expressive system (though this latter is due in part to how shitty html is). My only gripe is with HTML that is simply not fit for the task (as it was never meant for that).
If by structure you mean things like hbox/vbox then no, html is not supposed to do that. HTML should only represent the semantic structure.
There are a couple of exceptions for interfaces that are genuinely unconventional, or that deal with multiple spacial dimensions, or that are primarily representing graphs and visual/audio data. But most interfaces should be representable in pure text.
This argument that "the web is only for documents" is missing the point that most applications are just interactive documents when you really break down their UI. A labeled tree is a fine way to represent user-facing state for most apps, and most apps would benefit from exposing a more semantic interface to users that was easier for them to manipulate and read programmatically.
Swing, Qt, et al do not have great answers to this problem, and definitely not superior ones than css.
but I agree in general with your statement.
Like I wouldn't want to have to deal with an interfrace like facebook in native stuff. I don't think it's impossible, but I feel like it would require a lot more up-front design and correct engineering.
You're right about XML being a medium, just kinda my memories of working with this stuff.
Yeah, its true — though you can leave an area empty where you will dynamically load one from a set of already drag’n’drop created layouts.
CSS:
.vbox, .hbox { display: flex }
.vbox { flex-direction: column }
.vbox > *, .hbox > * { flex-grow: 1 }
<div class="hbox">
<div class="vbox">
<button>Top left</button>
<button>Bottom left</button>
</div>
<div class="vbox">
<button>Top right</button>
<button>Bottom right</button>
</div>
</div>
If I had to pick a stack to do a new web app entirely in canvas, I'd probably choose to port a ton of interface components from AS3 into PixiJS... but the point is, where have we gotten? Ten years from now we'll be writing apps the way they were written in 2010 -- inside a black box in a canvas or VM. The HTML5/JS revolution has been a sham from the start, just a way for one corporation to dismantle another with the side benefit of forcing all of us to rewrite our code from scratch in a crappier language.
Anyway, that's not very important.
What web apps never had is a visual app builder as popular as the first Visual Basic for Windows 3. We had some tools like that (example Jwt [2]) but none of them got a critical mass of users. Maybe it's difficult to match Visual Basic's success because Microsoft controlled the tool, the operating system and the language. If this is the case the only current candidate is Google, because of Chrome. They are investing on Flutter and Dart now but making them prosper on the web looks like a uphill battle. Much easier on Android.
HTML is simply a terrible GUI base, JS is quite great nowadays and CSS would be great, but has to provide way too much of what HTML should be doing. But the web ui frameworks are just barely getting at the level of where native frameworks have been in a decade.