6 ms·

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right

Sorry, but I think there's some stockholm going on here. People use the web for apps because people use the web for apps. It was in the right place at the right time and an extinction event chose JavaScript. That doesn't mean we can't make something better (doesn't mean we can, either).

brundolf 6y ago
If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more powerful platform than the alternatives. I'm not saying we couldn't do better - the CSS API has a lot of warts and the DOM has performance issues if you don't know how to avoid them - but I am saying we had decades to do better and didn't, so there must be something very difficult about doing better and we shouldn't discount the only thing that's ever really succeeded.
- pjmlp 6y ago
  Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?
  - nicoburns 6y ago
    Canvas isn't far off. The web is excellent for the types of UI that people often want to build for application: nestings of boxes interspersed with text.
    - tasogare 6y ago
      So excellent it didn’t have a grid layout until 2018, flexbox landed 2016 and before that there was heated debate for years between table and div to properly align things.
      - coldtea 6y ago
        Well, that was then, and this is now. Even without a grid, people have built more billion dollar software offerings on the web (SaaS) than they have in native form. (Not that I don't prefer native myself. Just saying).
    - pjmlp 6y ago
      Modern native canvas are hardware accelerated, browser canvas can be, but you never know, which is another reason why HTML 5 games are a glimpse of what Flash achieved.
  - coldtea 6y ago
    >Houdini is still barely capable comparable with native drawing. Which is neither here, nor there. The web stack (sans Houdini) is powerful enough for 99% of things an app will need to draw. >Layout managers were already a thing in Motif. Too bad Motif was crap and is irrelevant today. >Where is the great web tooling capable to beat Delphi/VB workflows? One could also reverse the question: where is the Delphi/VB tooling today?
    - pjmlp 6y ago
      If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU. By the way, already mastered all CSS tricks to force hardware rendering? Motif might be irrelevant, yet its ideas live on across all modern toolkits for native programming and the Web had to wait for the WPF team to bother submitting WPF grids to W3C as base concept. Delphi and VB are doing pretty well. https://www.embarcadero.com/products/delphi?aldSet=en-GB https://www.embarcadero.com/products/delphi?aldSet=en-GB https://visualstudio.microsoft.com/vs/features/net-development/ https://visualstudio.microsoft.com/vs/features/net-developme... And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use. https://www.outsystems.com https://www.outsystems.com
      - coldtea 6y ago
        >If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU. Because they can't possibly be pushing very diminishing return features, or stuff that only applies to niche markets ? >And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use. It's not like "used for enterprise software" is a great endorsement :-)
        pjmlp 6y ago
        It is the only target demography that actually pays for tools.
        coldtea 6y ago
- dmitriid 6y ago
  > but I am saying we had decades to do better and didn't If you ignore everything outside the web, sure. Games routinely render thousands of extremely complex objects at over 60 fps. The browser cannot animate a `height: auto` element or display more than a few thousand simple elements without stuttering. Clearly we have done better. Just not on the web. And don't get me started on actual complex UIs. TurboVision from the 90s, Qt and Delphi from early 00s had more power and ease to create complex layouts than anything the web can offer today. You can't even implement a proper accessible modal dialog on the web without tearing your hair out.
  - brundolf 6y ago
    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.
    - dmitriid 6y ago
      > You're talking purely about performance. Not just about performance. > 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 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.
k__ 6y ago
First, Stockholm syndrome isn't a thing. Second, there were a bunch of alternatives and the Web won instead of them and not just because they weren't there. I know, some people like running around telling everybody Qt, GTK, Swing or whatever were or even are better, but they are seemingly not for the points that matter for most of GUI apps. But yes, we should make something better going forward.
- anderspitman 6y ago
  > First, Stockholm syndrome isn't a thing. Have you ever had a useful conversation by starting with this?
  - coldtea 6y ago
    Yes. The information that "Stockholm syndrome" is a bogus pop psychology theory disputed as to its reality today, has proven extremely useful anytime the core argument of the other side is that something was/is "bad" and has only been retained "because of Stockholm syndrome".
    - k__ 6y ago
      yes, thanks
  - k__ 6y ago
    Many.
    - deleted 6y ago
      [deleted]
    - thesnowdog 6y ago
      With a captive audience in Stockholm?
coldtea 6y ago
No, people use the web for apps because: (a) AWT was shitty and Swing an overengineered mess. (b) GTK+ was never decent cross platform. (c) QT was more decent, but had its own issues, and still in an uncanny valley (neither native enough, not its own thing like the web UI is). (d) Cocoa and whatever Windows has this week are not cross platform. (e) Most other alternatives are buggy, understuffed, and just don't look good (f) It's easy to put something on the screen with not even a compiler or download needed.
- judge2020 6y ago
  > whatever Windows has this week Just for informative purposes, it's maui - a cross platform .net core UI. https://github.com/dotnet/maui https://github.com/dotnet/maui Currently predicting Nov 2021 (dates may change) > .NET MAUI general availability November 2021
  - coldtea 6y ago
    I said it half jockingly, but I have read about over 5 transitions from UI framework to UI framework in Windows-land in the past 25 years... Haven't even heard of this maui thing -- the last thing I remember was XAML, WPF, etc.
- alexhutcheson 6y ago
  Also, of those options, only Qt works on mobile, and only since version 5.1 in late 2013. Qt licensing is also a bit complicated on iOS. The web enjoyed a fairly long monopoly as the only cross-platform option if you cared about mobile.
- KronisLV 6y ago
  I really wanted to like Swing - despite it really being an overengineered mess, with some IDE GUI tools for creating UI layouts (a crutch that you might want to use, given how messy the code-first approach would be), it was actually a passable way of creating cross-platform GUI apps. Though you'd still need JDK, which was a drawback (and it wouldn't look or feel native, but then again, at least it worked). JavaFX/OpenJFX, despite its advantages, somehow feels worse integrated into the development workflow that some people like me used to have. Never really got into GTK+ or Qt, or other tools that are more wieldy in the lower level languages, i'm afraid, though i'm sure that with enough time investment, bindings for other languages could be found and you could use them well enough. Though the closest i've seen to "easy" cross-platform GUI development that actually respects the underlying platform (unlike Electron), but that also doesn't make your hair go gray, was the way FreePascal + Lazarus handled it, by attempting to support multiple frameworks in a transparent manner, where possible ( https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library ). Now, normally something like that would fail, since abstractions are leaky, but it seems like a number of useful pieces of software was actually written that way ( https://wiki.freepascal.org/Projects_using_Free_Pascal https://wiki.freepascal.org/Projects_using_Free_Pascal ). It's just sad that the language is kind of dead nowadays, as is the idea of having up-to-date tooling around it, or even many tools for developing web APIs. :/

brundolf 6y ago

If you're trying to build out an arbitrary UI, there is no GUI layer today that's more flexible than the web (in terms of screen sizes, customizability, layout styles, look and feel). Maybe you could argue that this flexibility arose because of the popularity it gained by being in the right place at the right time, but at this point the network-effect is not the only reason we use it. It has genuinely become a more powerful platform than the alternatives. I'm not saying we couldn't do better - the CSS API has a lot of warts and the DOM has performance issues if you don't know how to avoid them - but I am saying we had decades to do better and didn't, so there must be something very difficult about doing better and we shouldn't discount the only thing that's ever really succeeded.

pjmlp 6y ago
Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?
- nicoburns 6y ago
  Canvas isn't far off. The web is excellent for the types of UI that people often want to build for application: nestings of boxes interspersed with text.
  - tasogare 6y ago
    So excellent it didn’t have a grid layout until 2018, flexbox landed 2016 and before that there was heated debate for years between table and div to properly align things.
    - coldtea 6y ago
      Well, that was then, and this is now. Even without a grid, people have built more billion dollar software offerings on the web (SaaS) than they have in native form. (Not that I don't prefer native myself. Just saying).
  - pjmlp 6y ago
    Modern native canvas are hardware accelerated, browser canvas can be, but you never know, which is another reason why HTML 5 games are a glimpse of what Flash achieved.
- coldtea 6y ago
  >Houdini is still barely capable comparable with native drawing. Which is neither here, nor there. The web stack (sans Houdini) is powerful enough for 99% of things an app will need to draw. >Layout managers were already a thing in Motif. Too bad Motif was crap and is irrelevant today. >Where is the great web tooling capable to beat Delphi/VB workflows? One could also reverse the question: where is the Delphi/VB tooling today?
  - pjmlp 6y ago
    If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU. By the way, already mastered all CSS tricks to force hardware rendering? Motif might be irrelevant, yet its ideas live on across all modern toolkits for native programming and the Web had to wait for the WPF team to bother submitting WPF grids to W3C as base concept. Delphi and VB are doing pretty well. https://www.embarcadero.com/products/delphi?aldSet=en-GB https://www.embarcadero.com/products/delphi?aldSet=en-GB https://visualstudio.microsoft.com/vs/features/net-development/ https://visualstudio.microsoft.com/vs/features/net-developme... And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use. https://www.outsystems.com https://www.outsystems.com
    - coldtea 6y ago
      >If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU. Because they can't possibly be pushing very diminishing return features, or stuff that only applies to niche markets ? >And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use. It's not like "used for enterprise software" is a great endorsement :-)
      - pjmlp 6y ago
        It is the only target demography that actually pays for tools.
        coldtea 6y ago
dmitriid 6y ago
> but I am saying we had decades to do better and didn't If you ignore everything outside the web, sure. Games routinely render thousands of extremely complex objects at over 60 fps. The browser cannot animate a `height: auto` element or display more than a few thousand simple elements without stuttering. Clearly we have done better. Just not on the web. And don't get me started on actual complex UIs. TurboVision from the 90s, Qt and Delphi from early 00s had more power and ease to create complex layouts than anything the web can offer today. You can't even implement a proper accessible modal dialog on the web without tearing your hair out.
- brundolf 6y ago
  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.
  - dmitriid 6y ago
    > You're talking purely about performance. Not just about performance. > 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 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.

k__ 6y ago

First, Stockholm syndrome isn't a thing. Second, there were a bunch of alternatives and the Web won instead of them and not just because they weren't there. I know, some people like running around telling everybody Qt, GTK, Swing or whatever were or even are better, but they are seemingly not for the points that matter for most of GUI apps. But yes, we should make something better going forward.

anderspitman 6y ago
> First, Stockholm syndrome isn't a thing. Have you ever had a useful conversation by starting with this?
- coldtea 6y ago
  Yes. The information that "Stockholm syndrome" is a bogus pop psychology theory disputed as to its reality today, has proven extremely useful anytime the core argument of the other side is that something was/is "bad" and has only been retained "because of Stockholm syndrome".
  - k__ 6y ago
    yes, thanks
- k__ 6y ago
  Many.
  - deleted 6y ago
    [deleted]
  - thesnowdog 6y ago
    With a captive audience in Stockholm?

coldtea 6y ago

No, people use the web for apps because: (a) AWT was shitty and Swing an overengineered mess. (b) GTK+ was never decent cross platform. (c) QT was more decent, but had its own issues, and still in an uncanny valley (neither native enough, not its own thing like the web UI is). (d) Cocoa and whatever Windows has this week are not cross platform. (e) Most other alternatives are buggy, understuffed, and just don't look good (f) It's easy to put something on the screen with not even a compiler or download needed.

judge2020 6y ago
> whatever Windows has this week Just for informative purposes, it's maui - a cross platform .net core UI. https://github.com/dotnet/maui https://github.com/dotnet/maui Currently predicting Nov 2021 (dates may change) > .NET MAUI general availability November 2021
- coldtea 6y ago
  I said it half jockingly, but I have read about over 5 transitions from UI framework to UI framework in Windows-land in the past 25 years... Haven't even heard of this maui thing -- the last thing I remember was XAML, WPF, etc.
alexhutcheson 6y ago
Also, of those options, only Qt works on mobile, and only since version 5.1 in late 2013. Qt licensing is also a bit complicated on iOS. The web enjoyed a fairly long monopoly as the only cross-platform option if you cared about mobile.
KronisLV 6y ago
I really wanted to like Swing - despite it really being an overengineered mess, with some IDE GUI tools for creating UI layouts (a crutch that you might want to use, given how messy the code-first approach would be), it was actually a passable way of creating cross-platform GUI apps. Though you'd still need JDK, which was a drawback (and it wouldn't look or feel native, but then again, at least it worked). JavaFX/OpenJFX, despite its advantages, somehow feels worse integrated into the development workflow that some people like me used to have. Never really got into GTK+ or Qt, or other tools that are more wieldy in the lower level languages, i'm afraid, though i'm sure that with enough time investment, bindings for other languages could be found and you could use them well enough. Though the closest i've seen to "easy" cross-platform GUI development that actually respects the underlying platform (unlike Electron), but that also doesn't make your hair go gray, was the way FreePascal + Lazarus handled it, by attempting to support multiple frameworks in a transparent manner, where possible ( https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library ). Now, normally something like that would fail, since abstractions are leaky, but it seems like a number of useful pieces of software was actually written that way ( https://wiki.freepascal.org/Projects_using_Free_Pascal https://wiki.freepascal.org/Projects_using_Free_Pascal ). It's just sad that the language is kind of dead nowadays, as is the idea of having up-to-date tooling around it, or even many tools for developing web APIs. :/