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.
Comments
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.