I take an almost opposite view. I think there is actually an issue of trying to use a document model as a basis for an interactive user interface. In that sense flutter is actually an improvement over things like React. The whole idea of representing UI interactions by changes to a document model is absurd. We have had decades of experience building UI toolkits that target interactive interfaces. Then it all went in the garbage because it all had to go "on the web".
I don't think so. 99% of the problems I see on webpages are due to poor choices, whether by product owners, designers, or the developers themselves. So many issues can be avoided simply by choosing what hills not to die on. Most users just want a thing that gives them what they want quickly and clearly; webpages are absolutely capable of this with minimal code, even if you want elements to persist between page transitions.
Most of the web is a mess of unnecessarily complicated design, frameworks, custom fonts, tracker scripts, transpiled code, and oversized assets, perhaps bundled with Webpack. None of that shit is necessary, and usually detracts from UX, but serves to make designers and developers feel clever, and for product owners to believe they are in the same league as The Google. There is no reason most web services today can't be built well, with good UX, using very minimal tools. Arguably, a clone of TikTok for the web could be done pretty easily without something like React. Yet we cargo cult all this bro-tech because we are so afraid of the DOM and desperately want to seem relevant.
This also applies to Flutter. I wouldn't discount that there are times where that approach makes sense, but in most cases subverting the DOM by effectively shipping and entire rendering engine to a webpage is a bad pattern. For games, sure, but I sure hope writing your site in Flutter (bruh) won't become the norm.
You write this as if a "webpage" is one single thing. Maybe you picture a simple news article or blog entry - sure, it's fundamentally a document, HTML is almost purpose-built for publishing that kind of content.
On the other hand, there are countless webapps that are being built to replace what used to be (or would normally have been written as) desktop applications. The document model is poor fit for these. SPAs deliver a better, application-like experience.
These two things can coexist on the web. It doesn't have to be all one or the other. Flutter obviously targets the app experience, and you'd be foolish to use it to target the document experience. You'd be just as foolish to go the other way; page-oriented admin UIs (example: Shopify) are awful.
There is next to nothing about the DOM that doesn't already support application-like experiences. Yes, it was designed with documents in mind, but this claim that documents are antithetical to applications is something I fail to understand. Most SPAs fail to live up to their promise, not because there is something about the DOM that is incompatible with a type of UI, but because the chain of command in software development, especially when it comes to web apps, is dysfunctional. However, there are plenty of native apps that are bad at what they do as well. The difference is that the web attracts different kinds of developers, given that the bar to entry at every stage of development is significantly lower than iOS or Android development.
If you'd like to provide some examples of how the DOM itself works against application-like experiences, I'd love to hear them.
Yes, it was designed with documents in mind, but this claim that documents are antithetical to applications is something I fail to understand.
You fail to understand it because it doesn't make any sense. It's just a bunch of cantankerous complaining excuses that all serve to under mind the only computing medium users & developers have ever gotten to cooperate on.
Most of the big players are using WebComponents. Once you start using the web well, the web's html looks a heckuva lot like Android Layout xml, or any other widget tree in any other "application" system. (Oh except it also has better out of box experience & better support for arbitrary zoom and reactive sizing.)
Most SPAs fail to live up to their promise, not because there is something about the DOM that is incompatible with a type of UI, but because the chain of command in software development, especially when it comes to web apps, is dysfunctional.
Here here!
Most companies make bad apps, period. It's just more visible on the place where we use dozens or hundreds of different sites a day, many of which we've rarely see, and no one uses apps anywhere remotely that actively.
Interestingly I see your second paragraph as an endorsement to use flutter because it is platform agnostic. If the premise is your users want good UX, then they don't care about the rendering mechanics or uniformity (with regards to the rest of the web) of your application.
Sure it's an opaque flutter canvas you're rendering, but then the browser becomes just another platform you target for your app. Your users don't care, they just want the damn app to work everywhere with good UX.
It certainly could be a supporting argument. Whether I am confident that Flutter will be used to provide good UX in most cases is a different issue. Haha Yes, I wouldn't necessarily see the Flutter approach as bad if it improves the web. It's just that I think we have enough tools built-in to accomplish good webpages, even "web apps", and many of the kinds of developers resorting to Flutter may be the types who couldn't figure out why their custom-built blog using React is so slow and buggy (it's gotta be the stupid DOM!).
EDIT: I don't mean to crap on React. It's just a common frontend framework.
The whole idea of representing UI interactions by changes to a document model is absurd.
Citations needed. Works on my & most machines.
The protesting against the DOM is so endless, but golly gee willikers it sure looks a heckuva lot like a Android Layout xml or any of a hundred other widget tree systems. It's a tree of stuff, like every other UI paradigm. All in all, the DOM makes incredibly little impact, one way or another, on UI design. But heavens is it amazing for the user that there is a declarative document, that there is a common interchange, & not just gooping mounds of code that resist user scripting & user agency.
DOM is a pretty powerful flexible system that, frankly, does much better & has a much harder job than native apps. Native apps rarely do a good job supporting a variety of sizes/zooms, are minimally reactive, where-as the web is incredibly flexible.
Then it all went in the garbage because it all had to go "on the web".
Citation needed. Did it?
What other UI systems give users any where as much agency or power? What alternate systems give users any agency or power? Or to your bias, what was the halycon wonderful UI world developers frolicked in before?
I feel like the negative voices on this are extremely persistent, but it's entirely unclear to me what UI paradigm is in any way even in the least bit better. They all seem a bit like soupy messes. None of them are remotely good for culture & society at large except the DOM, for none of them are live & learnable & malleable & userscriptable. Which are better for developers seems to be the only question of the anti-DOM world, and there are, best I can tell, zero highly attractive targets we should go flock to. UIs just are a bit of a mess, especially ad complexity builds.
I also think folks highly underrate the slow but steady trickle of major major companies moving to WebComponents & having great success. GitHub, YouTube, maybe next reddit. The web is such a malleable architecture, the DOM is such a multi-paradigm. Trying to find your groove is not seamless & easy for all. Some people see that as a weakness, but it's a characteristic of an appropriately post modern[1] mode of developement, to have great capabilities & not be shoehorned into a tiny singular path.
To my mind there are fundamentally two ends of the cross-platform-GUI spectrum:
1) Photoshop-designed glamor GUIs that look exactly as the designer intended pixel-by-pixel from the .PSD files. DVD menus, tacky driver installers, videogame menus, etc.
2) Natively-laid-out guis that use the native tools of the platform and will look wildly different from platform to platform or even screen to screen but still offer fundamentally the same experience.
I strongly prefer kits that follow "2", where if somebody says "can I move this button over a few pixels" the kit says "no, also you suck for even wanting that". In those cases, the kit would strongly attempt to map the developer's intent into the concepts native to the platform, but not the developer's exact layout.
But for people who want or need things at the (1) end of the spectrum, an OpenGL-based toolkit makes perfect sense to me. But it does mean that the toolkit is taking on the responsibility of implementing all the accessibility features that would come out-of-the-box with a more native kit.
Because a document model is not a representation of a widget tree. UI toolkits came with preconfigured set of widgets that were rendered in a uniform way, had predefined behaviour that was controlled by the operating system (say for accessibility purposes) did not need to be "styled" unless the user wanted to style it at the OS level etc. Finally the callback system is far more intuitive for an average developer than the whole "UI as a function of state" mantra that dominates web based UI toolkits.
Using callbacks is fairly orthogonal to the document model - you can have a fairly imperative/callback-based web application, and a number of modern desktop GUI toolkits seem to be taking a "UI as a function of state" approach. If you just do vanilla web development (or even classic jQuery), you'll be writing a lot of very imperative, very callback-based code manipulating the widgets sitting in situ in the DOM. So I don't think the functional style is a feature of the document model per se, just a popular idiom that was started in web application development.
The lack of widgets is a fair point, but again, I don't know that that's specific to a document model over any other model. It's more that browsers have been historically poor at providing high-quality native widgets. A lot of other desktop frameworks provide very limited widgets too!
That said, I'm not sure that native widgets are the be-all-and-end-all here either. I like the example of the Ryanair flight date picker - it's essentially a custom widget, but it is really effective for the job that it does. You can easily select a period of time (typically with conventional date picker widgets this is done with two separate input fields and two linked date pickers), but you can also provide extra information inside the picker, so the user can see quickly whether it would be cheaper to fly out a day earlier or later, without having to try out a multitude of different dates.
This would be a terrible widget for a native GUI toolkit, because it's so niche - it is relevant for a handful of travel related applications, and that's it. It's also difficult to imagine a clean way of creating a single date picker widget generic enough to handle all the different use cases involved. But because the web is built out of a lot of very flexible building blocks, it's very easy to create new, very specific widgets. (And yes, they won't look like native ones, but I'm not necessarily sure that's a huge drawback for me. I know it is more important for others, though.)
I mean... they constantly are? Webworkers, webgl, web___, are constantly getting added. The DOM as a model of state is something web devs live with. Often without understanding it. I'm not sure I would count that as a feature.
That said, I don't mean this to be disdain. Having a somewhat targetable VM like environment to deploy applications to is a huge thing. That it has some fairly capable visualization capabilities built in is not a small thing.
That all said, I do think we are still far from how productive a small staff could be with some of the form builders of yesteryear. I'm also not entirely clear those left you with less legacy cruft than the equivalents today. :(
that's nonsense. As OP points out the bedrock of the web is a protocol designed for displaying more or less plain text documents from the 90s and everything else is essentially a hack on top of it. Native apps have plenty of ideas worth stealing, it's just that this is pretty tough to do. (the event based style of web apps for example as a mechanism existed forever in just about any desktop ui framework).
I think you really limit yourself by having such an ardent stance, that creates a place where you are unable to explore the possibility of success by anchoring yourself to very old historical facts.
The web was trying to be a connected online media form from the get go. Calling everything but text a hack is a maligning that seems at best a half truth.
Even if it was a "hack," it's been evolved & changed so much. There's been so much experimentation & so much living with hard constraints for a decade & finally making revolutionary change. Flex ix, grid layout, just hundreds of really amazing sweet super well done improvements to css & we components. It's an incredible blank slate that expresses so many really interesting & open experiences & UIs.
I agree with the parent poster & with you. The web has stolen most of the good ideas from native apps. Most of that is via frameworks & libraries rather than the web itself, & to me, it's amazing that the web can keep innovating & changing it's form to meet developer preferences, while the low level "hack" platform remains. That diversity & possibility is a sign of great success, that it can seed such diverse & competent different modes of development so gracefully.
Comments
I take an almost opposite view. I think there is actually an issue of trying to use a document model as a basis for an interactive user interface. In that sense flutter is actually an improvement over things like React. The whole idea of representing UI interactions by changes to a document model is absurd. We have had decades of experience building UI toolkits that target interactive interfaces. Then it all went in the garbage because it all had to go "on the web".
I don't think so. 99% of the problems I see on webpages are due to poor choices, whether by product owners, designers, or the developers themselves. So many issues can be avoided simply by choosing what hills not to die on. Most users just want a thing that gives them what they want quickly and clearly; webpages are absolutely capable of this with minimal code, even if you want elements to persist between page transitions.
Most of the web is a mess of unnecessarily complicated design, frameworks, custom fonts, tracker scripts, transpiled code, and oversized assets, perhaps bundled with Webpack. None of that shit is necessary, and usually detracts from UX, but serves to make designers and developers feel clever, and for product owners to believe they are in the same league as The Google. There is no reason most web services today can't be built well, with good UX, using very minimal tools. Arguably, a clone of TikTok for the web could be done pretty easily without something like React. Yet we cargo cult all this bro-tech because we are so afraid of the DOM and desperately want to seem relevant.
This also applies to Flutter. I wouldn't discount that there are times where that approach makes sense, but in most cases subverting the DOM by effectively shipping and entire rendering engine to a webpage is a bad pattern. For games, sure, but I sure hope writing your site in Flutter (bruh) won't become the norm.
You write this as if a "webpage" is one single thing. Maybe you picture a simple news article or blog entry - sure, it's fundamentally a document, HTML is almost purpose-built for publishing that kind of content.
On the other hand, there are countless webapps that are being built to replace what used to be (or would normally have been written as) desktop applications. The document model is poor fit for these. SPAs deliver a better, application-like experience.
These two things can coexist on the web. It doesn't have to be all one or the other. Flutter obviously targets the app experience, and you'd be foolish to use it to target the document experience. You'd be just as foolish to go the other way; page-oriented admin UIs (example: Shopify) are awful.
There is next to nothing about the DOM that doesn't already support application-like experiences. Yes, it was designed with documents in mind, but this claim that documents are antithetical to applications is something I fail to understand. Most SPAs fail to live up to their promise, not because there is something about the DOM that is incompatible with a type of UI, but because the chain of command in software development, especially when it comes to web apps, is dysfunctional. However, there are plenty of native apps that are bad at what they do as well. The difference is that the web attracts different kinds of developers, given that the bar to entry at every stage of development is significantly lower than iOS or Android development.
If you'd like to provide some examples of how the DOM itself works against application-like experiences, I'd love to hear them.
You fail to understand it because it doesn't make any sense. It's just a bunch of cantankerous complaining excuses that all serve to under mind the only computing medium users & developers have ever gotten to cooperate on.
Most of the big players are using WebComponents. Once you start using the web well, the web's html looks a heckuva lot like Android Layout xml, or any other widget tree in any other "application" system. (Oh except it also has better out of box experience & better support for arbitrary zoom and reactive sizing.)
Here here!
Most companies make bad apps, period. It's just more visible on the place where we use dozens or hundreds of different sites a day, many of which we've rarely see, and no one uses apps anywhere remotely that actively.
Interestingly I see your second paragraph as an endorsement to use flutter because it is platform agnostic. If the premise is your users want good UX, then they don't care about the rendering mechanics or uniformity (with regards to the rest of the web) of your application.
Sure it's an opaque flutter canvas you're rendering, but then the browser becomes just another platform you target for your app. Your users don't care, they just want the damn app to work everywhere with good UX.
It certainly could be a supporting argument. Whether I am confident that Flutter will be used to provide good UX in most cases is a different issue. Haha Yes, I wouldn't necessarily see the Flutter approach as bad if it improves the web. It's just that I think we have enough tools built-in to accomplish good webpages, even "web apps", and many of the kinds of developers resorting to Flutter may be the types who couldn't figure out why their custom-built blog using React is so slow and buggy (it's gotta be the stupid DOM!).
EDIT: I don't mean to crap on React. It's just a common frontend framework.
Citations needed. Works on my & most machines.
The protesting against the DOM is so endless, but golly gee willikers it sure looks a heckuva lot like a Android Layout xml or any of a hundred other widget tree systems. It's a tree of stuff, like every other UI paradigm. All in all, the DOM makes incredibly little impact, one way or another, on UI design. But heavens is it amazing for the user that there is a declarative document, that there is a common interchange, & not just gooping mounds of code that resist user scripting & user agency.
DOM is a pretty powerful flexible system that, frankly, does much better & has a much harder job than native apps. Native apps rarely do a good job supporting a variety of sizes/zooms, are minimally reactive, where-as the web is incredibly flexible.
Citation needed. Did it?
What other UI systems give users any where as much agency or power? What alternate systems give users any agency or power? Or to your bias, what was the halycon wonderful UI world developers frolicked in before?
I feel like the negative voices on this are extremely persistent, but it's entirely unclear to me what UI paradigm is in any way even in the least bit better. They all seem a bit like soupy messes. None of them are remotely good for culture & society at large except the DOM, for none of them are live & learnable & malleable & userscriptable. Which are better for developers seems to be the only question of the anti-DOM world, and there are, best I can tell, zero highly attractive targets we should go flock to. UIs just are a bit of a mess, especially ad complexity builds.
I also think folks highly underrate the slow but steady trickle of major major companies moving to WebComponents & having great success. GitHub, YouTube, maybe next reddit. The web is such a malleable architecture, the DOM is such a multi-paradigm. Trying to find your groove is not seamless & easy for all. Some people see that as a weakness, but it's a characteristic of an appropriately post modern[1] mode of developement, to have great capabilities & not be shoehorned into a tiny singular path.
[1] http://www.wall.org/~larry/pm.html
To my mind there are fundamentally two ends of the cross-platform-GUI spectrum:
1) Photoshop-designed glamor GUIs that look exactly as the designer intended pixel-by-pixel from the .PSD files. DVD menus, tacky driver installers, videogame menus, etc.
2) Natively-laid-out guis that use the native tools of the platform and will look wildly different from platform to platform or even screen to screen but still offer fundamentally the same experience.
I strongly prefer kits that follow "2", where if somebody says "can I move this button over a few pixels" the kit says "no, also you suck for even wanting that". In those cases, the kit would strongly attempt to map the developer's intent into the concepts native to the platform, but not the developer's exact layout.
But for people who want or need things at the (1) end of the spectrum, an OpenGL-based toolkit makes perfect sense to me. But it does mean that the toolkit is taking on the responsibility of implementing all the accessibility features that would come out-of-the-box with a more native kit.
To be more accurate, React uses its virtual DOM implementation.
https://legacy.reactjs.org/docs/faq-internals.html
Why do you see it as being so absurd?
Because a document model is not a representation of a widget tree. UI toolkits came with preconfigured set of widgets that were rendered in a uniform way, had predefined behaviour that was controlled by the operating system (say for accessibility purposes) did not need to be "styled" unless the user wanted to style it at the OS level etc. Finally the callback system is far more intuitive for an average developer than the whole "UI as a function of state" mantra that dominates web based UI toolkits.
Using callbacks is fairly orthogonal to the document model - you can have a fairly imperative/callback-based web application, and a number of modern desktop GUI toolkits seem to be taking a "UI as a function of state" approach. If you just do vanilla web development (or even classic jQuery), you'll be writing a lot of very imperative, very callback-based code manipulating the widgets sitting in situ in the DOM. So I don't think the functional style is a feature of the document model per se, just a popular idiom that was started in web application development.
The lack of widgets is a fair point, but again, I don't know that that's specific to a document model over any other model. It's more that browsers have been historically poor at providing high-quality native widgets. A lot of other desktop frameworks provide very limited widgets too!
That said, I'm not sure that native widgets are the be-all-and-end-all here either. I like the example of the Ryanair flight date picker - it's essentially a custom widget, but it is really effective for the job that it does. You can easily select a period of time (typically with conventional date picker widgets this is done with two separate input fields and two linked date pickers), but you can also provide extra information inside the picker, so the user can see quickly whether it would be cheaper to fly out a day earlier or later, without having to try out a multitude of different dates.
This would be a terrible widget for a native GUI toolkit, because it's so niche - it is relevant for a handful of travel related applications, and that's it. It's also difficult to imagine a clean way of creating a single date picker widget generic enough to handle all the different use cases involved. But because the web is built out of a lot of very flexible building blocks, it's very easy to create new, very specific widgets. (And yes, they won't look like native ones, but I'm not necessarily sure that's a huge drawback for me. I know it is more important for others, though.)
If native apps had ideas worth stealing the web would have by now.
I mean... they constantly are? Webworkers, webgl, web___, are constantly getting added. The DOM as a model of state is something web devs live with. Often without understanding it. I'm not sure I would count that as a feature.
That said, I don't mean this to be disdain. Having a somewhat targetable VM like environment to deploy applications to is a huge thing. That it has some fairly capable visualization capabilities built in is not a small thing.
That all said, I do think we are still far from how productive a small staff could be with some of the form builders of yesteryear. I'm also not entirely clear those left you with less legacy cruft than the equivalents today. :(
From the top of my head native input controls and buttons and MVC.
that's nonsense. As OP points out the bedrock of the web is a protocol designed for displaying more or less plain text documents from the 90s and everything else is essentially a hack on top of it. Native apps have plenty of ideas worth stealing, it's just that this is pretty tough to do. (the event based style of web apps for example as a mechanism existed forever in just about any desktop ui framework).
I think you really limit yourself by having such an ardent stance, that creates a place where you are unable to explore the possibility of success by anchoring yourself to very old historical facts.
The web was trying to be a connected online media form from the get go. Calling everything but text a hack is a maligning that seems at best a half truth.
Even if it was a "hack," it's been evolved & changed so much. There's been so much experimentation & so much living with hard constraints for a decade & finally making revolutionary change. Flex ix, grid layout, just hundreds of really amazing sweet super well done improvements to css & we components. It's an incredible blank slate that expresses so many really interesting & open experiences & UIs.
I agree with the parent poster & with you. The web has stolen most of the good ideas from native apps. Most of that is via frameworks & libraries rather than the web itself, & to me, it's amazing that the web can keep innovating & changing it's form to meet developer preferences, while the low level "hack" platform remains. That diversity & possibility is a sign of great success, that it can seed such diverse & competent different modes of development so gracefully.
the web's main problem is that they can't innovate without breaking everything, and they can't break compatibility.
So worth or not, doesn't matter.