You're talking purely about performance. Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. In many cases they aren't build on any kind of platform at all. They often have element/text positions hardcoded to a specific screen shape. Which is exactly what the browser spends most of its effort preventing: all sizing and positioning is determined automatically based on rules and content, which can be expensive to calculate, but is what makes it so robust.
Qt still exists. It's still being actively developed and still gets used for some modern software. It's actually a perfect stand-in for the current peak of native cross-platform frameworks. It's a contemporary of the web, it supports all the platforms, it has a rich feature set. It even directly supports several languages, something the web doesn't really do. And yet: it's only used in a very small fraction of the apps out there. Why? Because (if you ask me) it simply isn't as flexible or accessible of a GUI layer. It's a very performant GUI layer, and it works very well for certain types of applications. But the web works pretty well for all types of applications. And that's exactly my point.
> And yet: it's only used in a very small fraction of the apps out there.
Qt is estimated to account for ~10-15% of all c++ development, which is a very fair amount for any one single framework. You just don't see it because most of the time it blends in perfectly. Do you think about Qt when you're using your LG TV ? (LG WebOS is Qt). Or OneDrive Desktop ?
> Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI.
Not probably, but definitely
> But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones.
Yeah, no. Games have had UI scaling since monitors got more resolutions than 640x480.
The reason why the web is horrible at UI performance is simple: it was never built for UIs. It is, at its core, a system to display simple texts with a few images in between, and that's it.
Look at the sad state over at https://csstriggers.com. Setting text shadow will cause a full-screen reflow. What does this have to do with "flexibility baked into its bones"?Nothing. If anything, it's entirely inflexible. Same for any type of animation apart from a handful of css transforms: touching any part of an element will cause a full-age reflow (and that's why animating `height: auto` is one of the web's holy grails). This has nothing to do with "changing screen size or the input type". The web was never built for this, and anything outside simple-text-plus-a-few-images is just a bolted-on hack that barely works.
> all sizing and positioning is determined automatically based on rules, which can be expensive to calculate, but is what makes it so robust.
iOS uses a significantly more complex system layout constraints not dissimilar to Cassowary. Cassowary was proposed for the web in the late 1990s and was rejected because it was considered to be too expensive to calculate on the hardware of the times. The vast majority of the web was designed with one goal in mind: avoid expensive calculations. To the point that the actual algorithms to decide how to layout and draw stuff are specified in the standards. And the core of the web is designed around ... a single pass. The first time an allowance for two passes appears is for some stuff in tables (was it vertical alignment?) in early 00s.
And the actual complexity on the web comes from the fact that it was never designed for any of this stuff. And, of course, there's no robustness to speak off. Even looking at the web sideways will break it in innumerable ways: from the fact that just asking for an element's size will cause a full-page reflow to inability to properly encapsulate anything.
> Qt still exists. It's still being actively developed and still gets used for some modern software.
I know it still exists. What I was saying that Qt and Delphi in early 00s and TurboVision in 1990s had tools that surpass anything the web has to offer today. Which is not unusual, because they were developed as UI frameworks/libs/tools. Unlike the web. It can barely display a simple page with text and images, and now we've built an unholy mountain of hacks on top of it.
The web is the first and only UI system that lacks any and all tools to actually build and customise a UI beyond a very restricted set of badly interconnected very rigidly defined primitives. Where any UI lib/framework gives you a rich set of complex controls, the web gives you a few form elements with little to no functionality. Where any UI lib/framework gives you a plethora of tools to design/change any control or primitive you want (going as far as letting you redefine your own paint functions), the web gives you nothing.
I keep repeating this in various comments, but: there's a reason why most CSS/UI frameworks on the web repeat the same handful of primitive elements: a badge, a text input, a button, a breadcrumb, an avatar. Because that's all you can do in any reasonable amount of time. Very very very few attempt a date picker or a complex dropdown (inevitable with significant a11y issues). More complex UI elements like virtual lists, tree views, master-detail sheets, proper data tables, truly complex layouts where you can actually mix and match any and all components? Ahahahahahaha. And of course, nothing even approaching visual editors of early 00s because they are simply impossible on the web.
> But the web works pretty well for all types of applications.
The web performs poorly for any type of application and performs barely well enough for pages.
> Games have had UI scaling since monitors got more resolutions than 640x480
Scaling is different from resizing. Maybe it was my fault for using the wrong word.
Have you ever tried to play an old game on a widescreen monitor? Even a lot of modern, triple-A games have weird HUD layouts on ultrawide monitors because they have to be re-hard-coded for that aspect ratio. So if they haven't, you just get the layout they're hardcoded to for widescreen monitors.
I'm not saying it would make sense to trade performance for robustness in the case of games specifically, because they're always going to be full-screen and usually target one of only a handful of aspect-ratios (at least for consoles and PC; mobile may be a different story). I'm just saying they definitely get to skip a whole lot of hard problem-solving due to the constraints of the end product.
I don't have time to read more than the first part of your reply right now; maybe I will later.
> Have you ever tried to play an old game on a widescreen monitor? Even a lot of modern, triple-A games have weird HUD layouts on ultrawide monitors because they have to be re-hard-coded for that aspect ratio. So if they haven't, you just get the layout they're hardcoded to for widescreen monitors.
Have you ever seen any UI on the web that approaches the complexity of game UIs? I haven't [1]. Anywhere there's such complexity on the web, you get lots and lots of hardcoded values: from hardcoded media breakpoints to entirely different layouts for different resolutions and screen sizes.
> I don't have time to read more than the first part of your reply right now; maybe I will later.
Now worries, I got carried away a bit. As Stephen King calls it, "diarrhoea of the word processor" :)
> Have you ever seen any UI on the web that approaches the complexity of game UIs?
I have personally built tools on the web more complex than the game UIs in your link.
> Anywhere there's such complexity on the web, you get lots and lots of hardcoded values: from hardcoded media breakpoints to entirely different layouts for different resolutions and screen sizes.
...and I didn't use a single media breakpoint in any of them, and very rarely hardcoded any positions or sizes.
The only time I've ever needed an explicit device-size breakpoint, it was for a site that needed to toggle from a laid-out navigation menu to a hamburger menu when the user was on a phone-sized device (or had their window narrowed to that size! the web doesn't care what device you're actually on, just how much space is available). There was a single breakpoint for "phone-ish" sizes, and that was that. It was necessary in this case because, unlike most values in CSS/the DOM, it was a discrete change and not a continuum. In most cases media-queries are a code smell.
Sorry for butting in on this interesting conversation but regarding media queries being code smell, I currently see no other portable way to deliver multi-resolution background images. :-( Without JS libs that is...
"Code smell" doesn't mean "never justified", it just means "you should look at it with a skeptical eye"
Your usecase sounds legitimate to me. Given that you're talking about different image files, you're fundamentally talking about discrete cases, for which media queries are appropriate. The problems come up when people take something that doesn't need to consist of discrete cases - like element sizing, or whatever - and turn it into a set of discrete cases using media queries. This makes the page fragile against unexpected new sizes, instead of interpolating cleanly. Good CSS derives as many of its values as possible by channeling the continuous inputs of content size, viewport size, etc into other continuous values like the size and positioning of individual elements. The browser already does this by default; you just have to implement your vision while preserving as much of that intrinsic property as possible :)
> I have personally built tools on the web more complex than the game UIs in your link.
Then you are a far better developer than I am, and I dare say than the vast majority of developers out there. It will take most developers no time to come up with UI of any complexity in any of the non-web toolkits. Whereas on the web even small tasks like placing a badge on an avatar reliably is a thankless gargantuan task. Can't speak for the game UIs (they are undoubtedly hard) but considering the sheer diversity in them that the web hasn't seen since the flash era...
Qt still exists. It's still being actively developed and still gets used for some modern software. It's actually a perfect stand-in for the current peak of native cross-platform frameworks. It's a contemporary of the web, it supports all the platforms, it has a rich feature set. It even directly supports several languages, something the web doesn't really do. And yet: it's only used in a very small fraction of the apps out there. Why? Because (if you ask me) it simply isn't as flexible or accessible of a GUI layer. It's a very performant GUI layer, and it works very well for certain types of applications. But the web works pretty well for all types of applications. And that's exactly my point.