[kaba0]

Absolutely not true. Windows forms, WPF, JavaFX, Swing all are much more productive than the vanilla web. Like, how many lines of code does the most basic vbox/hbox thing requires in web technology? Many of them even have dragndrop ui creations, and this XML hatred is downright stupid at this point. How about criticizing the technology and not a random medium for that? Is writing something stupid in JSON inherently better?

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.

[ath92]

That example you mentioned would be just a couple of lines of html with css (which you could inline if you wanted), and there are plenty of drag and drop tools for the web (WebFlow is a modern example, but they have been around for decades).

[kaba0]

Why would it need any sort of CSS? Isn’t HTML supposed to be responsible for the structure of a webpage? And of course it can be done, but if we do something like hbox inside a vbox inside a vbox, the resulting code will be ugly as hell (perhaps Webcomponents will help a bit here?). Like, what is the point of HTML at that point? To spam divs (pun sort of intended)?

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).

[yoz-y]

> Isn’t HTML supposed to be responsible for the structure of a webpage?

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.

[kaba0]

Yeah I know, but that is because it was meant for documents. It is not a great fit for web applications.

[danShumway]

Applications aren't special.

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.

[eurasiantiger]

What is a better fit for web applications?

[kaba0]

Nothing, because web applications are by definition html css js. Though canvas-based solutions can circumvent the layouting problem, but at the price of reinventing everything in a non-standard way.

[rtpg]

Drag n drop UIs don't really help when you have too much dynamism (like "oh only have this button appear in these conditions", "do this here", etc). And I would say that box layout offered by CSS is much nicer than the constraint layout system _when you have a lot of dynamism_.

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.

[kaba0]

> Drag n drop UIs don't really help when you have too much dynamism

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.

[hnbad]

> Like, how many lines of code does the most basic vbox/hbox thing requires in web technology?

CSS:

    .vbox, .hbox { display: flex }
    .vbox { flex-direction: column }
    .vbox > *, .hbox > * { flex-grow: 1 }

HTML:

    <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>

Or was that a rhetorical question?

[noduerme]

Such a great point. HTML is a terrific way to write documents and TERRIBLE way to lay out applications - especially for lots of different screen sizes. It's not surprising at all to see Google embracing Canvas now to underpin Docs; basically they are admitting that it would have been better to write the whole program in a Java VM or in Flash than to rely on the browser for layout. This is patently obvious to anyone who builds large web applications. Ten years ago we had ASWing, JSwing and plenty of other actual frameworks where you didn't have to diddle around with tons of logic embedded in templates which were embedded in other logic; but thanks to Apple we're still saddled with this wretched Javascript/HTML paradigm that was never meant to do much more than inline some animated GIFs back in the 90s. Yes, it's gotten better (I've been doing this since the 90s, so I know). But it's so inelegant. To some degree this is just a problem with open web standards. It would be better if any one company actually had dominated to the point where they could write a closed standard, because at least it would be coherent and cross-platform. It was a lot easier to write a web app in 2010 than it is now, and it pains me to think how many hours I could have avoided reinventing the wheel if Flash had been allowed to stick around. Any app written entirely now on canvas is just replicating a VM that already existed a decade ago in what was by then a much more mature ecosystem - and was faster then than canvas or WebGL is now.

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.

[friend-monoid]

I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.

[kaba0]

How come the minuscule userbase of native frameworks have better tooling than the numero uno popular web? It may mean that there is a technical reason in the background.

[goto11]

They solve a simpler and more constrained problem which makes it easier to make tools. Something like Windows Forms are basically WYSIWYG - you drop some controls on a canvas and now you have a GUI. But the GUI will not gracefully adapt to different screen dimension from large monitors to mobile.

[pseudalopex]

Native frameworks support flexible and resolution dependent layouts too.

[kaba0]

Responsive layouting is an orthogonal problem.

[goto11]

Orthogonal to what?

[pmontra]

30+ years of history?

[kaba0]

Interestingly enough JavaFX is much younger than the web, and is quite niche, yet it has SceneBuilder.

[pmontra]

It's younger than the web but much older than the current bunch of frontend technologies. JavaFx is from 2008 [1]

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.

[1] https://en.wikipedia.org/wiki/JavaFX

[2] https://en.wikipedia.org/wiki/JWt_(Java_web_toolkit)