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.
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.)
> 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.
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.
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.
> 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.
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.
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.)
So worth or not, doesn't matter.
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.
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. :(