(not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI).

HTML does work fine when you use it for mostly document focused work, and I enjoy the interactivity and connectivity that web browsers have brought to the web, but I'd love to see an improvement on it all.

If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.

I'm not saying that we should burn the HTML and CSS stack. It has served the web very well and will continue to do so, but until the last few years, it's been a document focused stack that's been twisted into doing app development, and in some sense, it still is.

HTML and CSS are not the best tool for heavy GUI development, a la Photoshop, Visual Studio (not VS Code) or other large GUI intensive things. Most web apps have yet to replicate the combination of features and/or performance of those types native applications. Flexbox is an improvement there that helps with layout, but that doesn't change the fact that we are working with the DOM under the hood, with all of its various quirks and performance issues. (Not to say other GUI frameworks/APIs are perfect, or necessarily better. Some of them just allow you to optimize a little closer to the metal).

One can point out that large GUI tools like Photoshop aren't being created as much these days, outside of AAA game dev, CAD, or the like, or that many large GUI's use web views to help display documents, a la Steam.

I sincerely hope that Servo's "Web Browsers are essentially AAA game engines" approach catches on.

I'd be interested to see how an event-based html5 canvas GUI library would compare to DOM.

Q: How do you make an image maintain an aspect ratio and fill up the width or height of the screen, whichever comes first? A: Nested div hell and JavaScript.

Q: How do you make a scaled background image stay put even when the keyboard input pops up on a phone? A: Supreme JavaScript, CSS, and div hell.

Q: How do you center a paragraph of text vertically in a div? A: Nested div hell.

I'd say FlexBox is pretty inadequate. Why can't we have things like:

    #my-video {width:80%;height:calc(width*2/3);}

HTML/JS/CSS is just a stepping stone like any other, not an endgame. Don't grow complacent with it. Demand something better.

No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

However QML is an improvement. It was a bit quirky to get render the way you wanted and it was not native & look and feel, but maybe have gotten better since I used it. I could imagine that TypeScript + QML could be quite pleasant. Big downside is that the install size of your program is quite big.

I say that from the developer and the user perspective.

> Posted in Dev Loop, Qt Quick Controls, Styles

You might not like the envelope they are pushing, but they are cutting-edge explorations into web tech, coinciding with other cutting-edge developments like HTML/JS -> Native interfaces.

Just because js is good on web, doesn't - and shouldn't - mean that we should be doing that.

Of the 3, javascript is the most dispensable, there's nothing stopping us writing platforms which have UIs designed in HTML/CSS but have a DOM controlled by python/c#/ruby.

I was not suggesting we stop progressing, but we need to recognise the phenomenal amount of overhead involved in replacing these 3 technologies. What benefit would be served when they can just be abstracted on top of, at least with regards to the web?

Case in point, Assembly Language, we could theoretically replace the standards that have been reached over decades of collaboration with something more suited to our modern leanings. But what would be the point, when we've long since abstracted it out of our minds?

In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. A new standard would let us get by with a lot less.

Getting to piggyback on V8 and Blink work is, I suspect, often a benefit rather than a cost in the eyes of developers of Electron-based editors. Sure, it's bigger resource load, but for use cases where the performance is acceptable, it's a lot less developer load to get the functionality out the door.

Because they suck?

Yeah, like my favorite of these lately, widows and orphans. Chrome changed a default that affected inline-blocks within columns that caused them to wrap prematurely after version 52 or so. It is especially bad because the other popular browsers don't even support these yet and looked fine.

Where do I start?

1) Designed for document presentation, not for apps. 2) Limited widget selection (native forms and that's it). 3) Different implementations between vendors. 4) Bad at layout (20+ years to get to Flex and Grid CSS layout which kind of resembles UI layouts but is still not supported everywhere. 5) Slow 6) Batter hungry 7) Too many un-needed UI layers (DOM over native widgets) 8) Extra language layer (JS on top of v8 on top of native execution) 9) JS is not the best language to write large scale software (to put it mildly) 10) Restricted access/integration to native platform APIs.

I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model or the broken float layout techniques or the constant fiddling you are forced to do to get anything working. Every web developer I've seen adopts the 'edit and refresh' trial and error model of developing which is the direct result of a bad spec. Which also explains why there isn't even a reference implementation. As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.

As someone who has spent years implementing those standards, a reference implementation would not help me at all.

> As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.

Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Well, considering that the web has been for decades a landmine of subtle rendering differences based on different interpretations of the same standards, it would surely help others...

Also, I'm not sure what you're saying here. That, warts and all, you love the web as a programming platform?

Well, maybe you do.

But then again, you don't program everyday IN it. You program a rendering engine for it in Rust, so you're safely protected from the horrors of web programming.

>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Aren't (or at least weren't) most computer games "immediate mode" too, and far more demanding than any web page?

Which isn't a problem if you're layout algorithm is fast/simple. If it's not, then it's a bigger issue.

I don't quite understand what you meant your comment to be indicative of. That nobody else would consider it useful? That you personally see no value in reference implementations at all?

>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Could you detail the UI are you thinking of where IMGUI is inefficient but HTML/CSS isn't? Not asking for a formal spec, just a general usecase..

My problem with CSS/HTML is that productivity scales inversely when using them.

XUL is dead now, HTML+CSS won.

  > everyone understands it and can work immediately with it.