Flutter Web: A Fractal of Bad Design (2020)(hugotunius.se)
hugotunius.se
Flutter Web: A Fractal of Bad Design (2020)
https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-bad-design.html
76 コメント
Do any of the web accessibility issues come up for other platforms as well? How does the iOS screenreader handle Flutter-generated views on iOS?
"It doesn't seem like the Semantic HTML issue will ever be solved too, the Flutter team did mention in the latest conference that they're aiming it more to be used for web apps than websites."
I'm not sure I understand the distinction between web apps and web sites. Don't both of those experiences need to be accessible?
Thanks for sharing your input! Helpful to hear from folks actually using the tech and not just arm-chair analysis.
"It doesn't seem like the Semantic HTML issue will ever be solved too, the Flutter team did mention in the latest conference that they're aiming it more to be used for web apps than websites."
I'm not sure I understand the distinction between web apps and web sites. Don't both of those experiences need to be accessible?
Thanks for sharing your input! Helpful to hear from folks actually using the tech and not just arm-chair analysis.
> Do any of the web accessibility issues come up for other platforms as well? How does the iOS screenreader handle Flutter-generated views on iOS?
Unfortunately I haven't done much accessiblity-focused work with Flutter yet, however the docs do mention there are some capabilities but the amount of info there seems slim: https://docs.flutter.dev/accessibility-and-localization/acce...
> I'm not sure I understand the distinction between web apps and web sites. Don't both of those experiences need to be accessible?
The distinction as I understand is websites are usually more document-orientated focused mostly on reading (e.g. a blog, or even Hacker News), whereas web apps are more focused on user-interaction (e.g. spreadsheet apps, email apps).
Due to Flutter's large bundle size and long initial load time it's definitely not suitable for things like news sites or blogs where initial load, SEO, and readability are all important.
I would agree they both need to be accessible, but there's also extra cons to Flutter Web that make it not the best choice for websites even if it did accessbility perfectly.
Unfortunately I haven't done much accessiblity-focused work with Flutter yet, however the docs do mention there are some capabilities but the amount of info there seems slim: https://docs.flutter.dev/accessibility-and-localization/acce...
> I'm not sure I understand the distinction between web apps and web sites. Don't both of those experiences need to be accessible?
The distinction as I understand is websites are usually more document-orientated focused mostly on reading (e.g. a blog, or even Hacker News), whereas web apps are more focused on user-interaction (e.g. spreadsheet apps, email apps).
Due to Flutter's large bundle size and long initial load time it's definitely not suitable for things like news sites or blogs where initial load, SEO, and readability are all important.
I would agree they both need to be accessible, but there's also extra cons to Flutter Web that make it not the best choice for websites even if it did accessbility perfectly.
(I don't know Flutter well, so I'm a bit commenting from my armchair, sorry). In my experience, Android and iOS provide lower-level accessibility APIs that assume you're going to be making your own controls, while the web standards are considerably more targeted towards the use case of a site with content and forms (not a canvas where you click on stuff).
We didn't even bother using flutter for web. We went straight to React/Next.js and the results are wonderful.
For mobile? Sure, we're using Flutter (we're planning to switch to native as soon as we gain traction since our apps will be handling video ala tiktok) but other than that, Typescript for everything else.
For mobile? Sure, we're using Flutter (we're planning to switch to native as soon as we gain traction since our apps will be handling video ala tiktok) but other than that, Typescript for everything else.
Flutter Web WASM is set to be out later in 2023 (Google IO?) [1] and should fix the performance issues.
I have build big Flutter Web Apps and Performance was the only real issue, hope it is improved soon. Things like not selectable Text like the Author mentions just show that he does not really know what he is talking about. Just use the SelectableText Widget that is exactly the same as the Text Widget just that is is well, selectable.
[1] https://docs.flutter.dev/platform-integration/web/wasm
I have build big Flutter Web Apps and Performance was the only real issue, hope it is improved soon. Things like not selectable Text like the Author mentions just show that he does not really know what he is talking about. Just use the SelectableText Widget that is exactly the same as the Text Widget just that is is well, selectable.
[1] https://docs.flutter.dev/platform-integration/web/wasm
I absolutely think the team will largely fix the performance issues. And I think Flutter will, after that, go on to be a successful-with-developers but terrible-for-everyone else beast.
The submission early on links the wonderful "HTML is the Web" and this is a huge downgrade in user agency. Flutter does not care one iota that "The Internet is for End Users". [1] They have their own goal to build native like apps & are fine subverting the web. User agency be damned.
[1] https://datatracker.ietf.org/doc/html/rfc8890
The submission early on links the wonderful "HTML is the Web" and this is a huge downgrade in user agency. Flutter does not care one iota that "The Internet is for End Users". [1] They have their own goal to build native like apps & are fine subverting the web. User agency be damned.
[1] https://datatracker.ietf.org/doc/html/rfc8890
I have heard that WASM and potentially some engine upgrades could aid the performance but I think it's still too early to say they'll be a definite fix, I'm looking forward to testing it out though once it lands.
Hopefully it helps out on lower end mobile browsers too as that's where Flutter Web really tends to chug.
Hopefully it helps out on lower end mobile browsers too as that's where Flutter Web really tends to chug.
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.
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.
> webpages are absolutely capable of this
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.
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.
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.
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.
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.
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.
[1] http://www.wall.org/~larry/pm.html
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] 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.
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
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.)
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. :(
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 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.
So worth or not, doesn't matter.
"I haven’t looked at Flutter for other platforms than web so I cannot comment on it other than that the general principle of Flutter is a terrible idea."
The author completely missed the point of Flutter. It is a mobile-first platform positioned as an alternative to ReactNative. Its main goal was to provide a way to build cross-platform iOS/Android mobile apps with a minimal performance trade-off. For example, its code is compiled into native machine code for iOS, Android, and desktop. Its apps tend to be more lightweight and feel snappier. Unlike ReactNative they do their own rendering so that you can have pixel-perfect consistency across platforms.
Flutter's web and desktop support is more of an experiment and a convenience for those who want to port their existing mobile apps to web and desktop.
ReactNative was targeted for web developers who want to port their existing apps to mobile, Flutter's web support is the reverse of that.
The author completely missed the point of Flutter. It is a mobile-first platform positioned as an alternative to ReactNative. Its main goal was to provide a way to build cross-platform iOS/Android mobile apps with a minimal performance trade-off. For example, its code is compiled into native machine code for iOS, Android, and desktop. Its apps tend to be more lightweight and feel snappier. Unlike ReactNative they do their own rendering so that you can have pixel-perfect consistency across platforms.
Flutter's web and desktop support is more of an experiment and a convenience for those who want to port their existing mobile apps to web and desktop.
ReactNative was targeted for web developers who want to port their existing apps to mobile, Flutter's web support is the reverse of that.
> Flutter's web and desktop support is more of an experiment
If you go to the FLutter homepage, Web is given equal amount of coverage as mobile. Nowhere does it say it is "mobile-first".
This kind of line is repeated in big letters throughout the homepage:
"Deploy to multiple devices from a single codebase: mobile, web, desktop, and embedded devices."
If you go to the FLutter homepage, Web is given equal amount of coverage as mobile. Nowhere does it say it is "mobile-first".
This kind of line is repeated in big letters throughout the homepage:
"Deploy to multiple devices from a single codebase: mobile, web, desktop, and embedded devices."
I'm not sure that equal is the best way to describe it. Web has been there longer than desktop and embedded because Dart came with the ability to compile to JS, but web is given nowhere near the same attention by the Flutter team as other platforms.
> Unlike ReactNative they do their own rendering so that you can have pixel-perfect consistency across platforms.
You can make an argument for this, but this is exactly what people are generally objecting to. Most people expect native apps to look and feel like they are native to the platform, that they support accessibility and other platform features consistently and don’t introduce surprising conventions from other platforms.
You can make an argument for this, but this is exactly what people are generally objecting to. Most people expect native apps to look and feel like they are native to the platform, that they support accessibility and other platform features consistently and don’t introduce surprising conventions from other platforms.
To be honest, most people don’t care if an application is consistent with their operating system. They care first and foremost about features.
People do care about usability. When things work as you expect, you find your way around quickly and are less likely to get frustrated.
People get frustrated and still use completely inconsistent softwares. Windows is still the most used operating system on desktop, and is a complete mess of consistency. That never blocked people from doing what they want. Just to say, consistency is great to have, but isn’t really what drives people decision making.
Previously also here, three years ago: https://news.ycombinator.com/item?id=24962504
Unfortunately, the malicious state of Flutter web has not changed.
Unfortunately, the malicious state of Flutter web has not changed.
I can't think of a single framework or software technology that took off after 5 years of unpopularity. Let alone in web where the pace of development is much faster.
Ruby comes to mind - matz wrote it in 1995, but it wasn't until the pickaxe book came out in 2001 that it gained any popularity outside Japan. And it wasn't until Rails came out 3 years later that it really took off. That's almost a full decade from conception to use outside of niche applications.
Wholly dependent on what you mean by "took off" but I'd argue Haskell qualifies. It was a nothing language for two decades before finding its footing and is now used in quite a lot of places (TIOBE puts it near TypeScript).
Dart was really unpopular for years, until Flutter saved it. It has grown tremendously since then.
Flutter Web will be used mostly to develop web applications and not web sites. So I think their approach "can" work as long as they can provide first class accessibility support and make sure that their custom rendering doesn't drain battery.
Though at our company we have adopted Flutter for mobile in a big way, I am still waiting it out for at least 2 years to see where Flutter web goes.
Though at our company we have adopted Flutter for mobile in a big way, I am still waiting it out for at least 2 years to see where Flutter web goes.
I learned my lesson with AngularJS (v1) not to use Google’s frameworks for web dev ever again.
here I am, using lit, dealing with OOP
I am seing a "Fractal of bad design" statement second time in my life, first one was a famous article about PHP [1] (is flagged here but very upvoted on some other resources).
[1] https://news.ycombinator.com/item?id=28085142
[1] https://news.ycombinator.com/item?id=28085142
I assumed that the title was a reference but it doesn't seem to be a good reference. I don't think "fractal" fits well here as really the only mistake discussed was ditching HTML. I do think this is a critical error and makes Flutter sites largely unusable but it is still one big mistake, not a fractal.
The PHP one is the original, as far as I know (it's certainly old enough, at this point). Everything else is a reference to that, kind of like "...considered harmful."
That is an excellent read and a funny critique
This is what happens when the main criteria to hire your devs is stuff like whiteboard coding and encyclopedic knowledge of algorithms. You end up with a bunch of really smart people who don't care about users.
>The semantic structure of a document matters because that’s how machines, not humans, understand the web. A div with an onClick handler doesn’t look like a link or a button to a screen reader, search engine crawler, or accessibility extension, it looks like a div.
>Most importantly, semantic HTML is key for accessibility and other tools that let a user experience the web as they wish.
This! So much this! Web UIs like Flutter increasingly break the ability of extensions to make sites more usable.
But I read later and find the author is having a seemingly less degraded experience than I am with our favorite tool for browsing the web, Vimium:
>I use the browser extension Vimium to navigate the web, it’s an amazingly powerful tool that relies on, you guessed it, semantic HTML. Does it work on pages built with Flutter Web? Fuck no. It doesn’t work because it tries to find things that are semantically clickable, like button or a elements, of which, as we have established, Flutter Web generates none. Vimium works on almost all websites I use because most developers, thankfully, don’t just stick onClick handlers on divs.
I've found that many elements on the web don't get picked up by Vimium, even well outside the Flutter ecosystem. Heck, even HN search (via Algolia[1]), despite the minimalism, doesn't let Vimium detect the option dropdowns as clickable. (The Stories/Popular/All Time UIs.)
[1] https://hn.algolia.com/
>Most importantly, semantic HTML is key for accessibility and other tools that let a user experience the web as they wish.
This! So much this! Web UIs like Flutter increasingly break the ability of extensions to make sites more usable.
But I read later and find the author is having a seemingly less degraded experience than I am with our favorite tool for browsing the web, Vimium:
>I use the browser extension Vimium to navigate the web, it’s an amazingly powerful tool that relies on, you guessed it, semantic HTML. Does it work on pages built with Flutter Web? Fuck no. It doesn’t work because it tries to find things that are semantically clickable, like button or a elements, of which, as we have established, Flutter Web generates none. Vimium works on almost all websites I use because most developers, thankfully, don’t just stick onClick handlers on divs.
I've found that many elements on the web don't get picked up by Vimium, even well outside the Flutter ecosystem. Heck, even HN search (via Algolia[1]), despite the minimalism, doesn't let Vimium detect the option dropdowns as clickable. (The Stories/Popular/All Time UIs.)
[1] https://hn.algolia.com/
Try Vimium C, the dropdown works for me here.
> the general principle of Flutter is a terrible idea.
I think Flutter is a good idea with bad execution. Maybe due to the lack of resources or effort put into it or maybe due to the management, I don't know.
The only thing that is cross-platform right now is the web and it is based on graphics engines (Skia in the case of Chrome). My idea of Flutter is that it is being web (i.e. cross-platform) without being a browser (i.e. overhead of being browser). However, in practice, I couldn't observe a good performance from Flutter when I tried it.
Right now, a lot of apps are developed using Electron (aka Chrome). Flutter is the equivalent of Electron for mobile without the extra layer of having a browser. With the advent of frameworks using WebView (WebGPU is also becoming popular) such as Tauri, we may need less Electron and Flutter.
> Flutter Web in particular is fundamentally flawed and needs to be rebuilt from the ground up if it has any hopes of being viable tech that generates semantic, accessible, and modern web experiences.
I don't know the exact technology of Flutter Web, but I think Flutter Web doesn't makes sense because it is running a renderer (Flutter) inside a renderer (browser).
I think Flutter is a good idea with bad execution. Maybe due to the lack of resources or effort put into it or maybe due to the management, I don't know.
The only thing that is cross-platform right now is the web and it is based on graphics engines (Skia in the case of Chrome). My idea of Flutter is that it is being web (i.e. cross-platform) without being a browser (i.e. overhead of being browser). However, in practice, I couldn't observe a good performance from Flutter when I tried it.
Right now, a lot of apps are developed using Electron (aka Chrome). Flutter is the equivalent of Electron for mobile without the extra layer of having a browser. With the advent of frameworks using WebView (WebGPU is also becoming popular) such as Tauri, we may need less Electron and Flutter.
> Flutter Web in particular is fundamentally flawed and needs to be rebuilt from the ground up if it has any hopes of being viable tech that generates semantic, accessible, and modern web experiences.
I don't know the exact technology of Flutter Web, but I think Flutter Web doesn't makes sense because it is running a renderer (Flutter) inside a renderer (browser).
A few years back I looked around what options exist for building a cross-plattform app. It should support mobile platforms (at least Android and iOS) as well as the web, properly.
The problem with cross-platform frameworks is that they either focus on a good mobile experience, and web becomes an afterthought, or vice versa, meaning mobile basically embeds a browser. Flutter is one of former; back then the web variant was in alpha and basically just a canvas that couldn't even adjust aspect ratio. Since web had priority for our project (accessability, reactive scaling, etc.), this was a no-go.
We ended up going with Ionic (which is basically Cordova with some components on top). The web experience is tweakable to a low level, and the mobile experience is acceptably good, even if not perfect. And we get to cover 3 platforms with the effort of building for ~1.2 apps (there is some platform-specific work involved still).
I'm not even sure if cross-platform is at all solvable in a perfect way, since the UI patterns between mobile and web are just too different.
The problem with cross-platform frameworks is that they either focus on a good mobile experience, and web becomes an afterthought, or vice versa, meaning mobile basically embeds a browser. Flutter is one of former; back then the web variant was in alpha and basically just a canvas that couldn't even adjust aspect ratio. Since web had priority for our project (accessability, reactive scaling, etc.), this was a no-go.
We ended up going with Ionic (which is basically Cordova with some components on top). The web experience is tweakable to a low level, and the mobile experience is acceptably good, even if not perfect. And we get to cover 3 platforms with the effort of building for ~1.2 apps (there is some platform-specific work involved still).
I'm not even sure if cross-platform is at all solvable in a perfect way, since the UI patterns between mobile and web are just too different.
What UI patterns are so different if I may ask?
I have more experience with webdev but I can't seem to think of major differences in mobile.
I have more experience with webdev but I can't seem to think of major differences in mobile.
Well, to have a perfect-ish solution, you'd have to build a framework with UI elements that map to native elements on each platform. Behavior and styling (e.g. positioning of elements) would need to be consistent, so you'd probably have to reduce functionality to the least common denominator for each possible dimension, or take the burden of implementing compatibility for A on platforms B and C. Web has a legacy of document-based components, while mobile is generally more interactive. There are overlaps nowadays, but staying within those boundaries would be a serious restriction.
On top of all that, you'd need a runtime that works on all platforms and is able to interact with native controls. I think React Native does something like that, but back then when I checked they did not have official web platform support (which is somewhat ironic, but I suspect technical difficulties too).
On top of all that, you'd need a runtime that works on all platforms and is able to interact with native controls. I think React Native does something like that, but back then when I checked they did not have official web platform support (which is somewhat ironic, but I suspect technical difficulties too).
Oh ok. So that's layouting that is different? (all else being accounted for)
Well, among other things. Native APIs are another thing that comes to mind, but those can be bridged more easily I suppose.
A the emphasis on Semantic HTML makes me think the author is missing the point of Flutter Web.
The goal of Flutter Web is to make an app that runs in a web browser instead of on a phone or on the desktop. It is not trying to be an html document. iOS and Android and Windows and Mac apps don't have "semantic controls".
The goal of Flutter Web is to make an app that runs in a web browser instead of on a phone or on the desktop. It is not trying to be an html document. iOS and Android and Windows and Mac apps don't have "semantic controls".
> iOS and Android and Windows and Mac apps don't have "semantic controls"
They actually do. Specifically all of those platforms have accessibility APIs that export a semantic representation of the apps UI for use by applications like screen readers. That Flutter for web doesn't do this (and is thus innaccesible to many people) is good reason not to use it.
They actually do. Specifically all of those platforms have accessibility APIs that export a semantic representation of the apps UI for use by applications like screen readers. That Flutter for web doesn't do this (and is thus innaccesible to many people) is good reason not to use it.
I don't care about the semantic web, but I do care about accessibility. Most web sites should be accessible to people with (visual) handicaps. Text should be intuitively selectable. If flutter can't provide that, then it is a bad choice.
If you're going to design an app that you want to run in a browser, not a website but an app, why wouldn't you make use of canvas? Especially if you're designing a language that compiles to native code on as many platforms as possible.
I do get the accessibility issue with it but to me it seems that's been sacrificed for ease of development. A trade-off. Genuine question, is there a way to make canvas accessible or is it designed inaccessible? Or is flutter using it in an unintended way?
I'm certainly a happy user of dart/flutter. I'm not targeting the web. I would never use it for a real website but I definitely would for an app though if I was moving anything into the web.
I do get the accessibility issue with it but to me it seems that's been sacrificed for ease of development. A trade-off. Genuine question, is there a way to make canvas accessible or is it designed inaccessible? Or is flutter using it in an unintended way?
I'm certainly a happy user of dart/flutter. I'm not targeting the web. I would never use it for a real website but I definitely would for an app though if I was moving anything into the web.
Directly from the flutter documentation:
>>> What scenarios are ideal for Flutter on the web? Not every web page makes sense in Flutter, but we think Flutter is particularly suited for app-centric experiences:
Progressive Web Apps Single Page Apps Existing Flutter mobile apps At this time, Flutter is not suitable for static websites with text-rich flow-based content. For example, blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.
>>> What scenarios are ideal for Flutter on the web? Not every web page makes sense in Flutter, but we think Flutter is particularly suited for app-centric experiences:
Progressive Web Apps Single Page Apps Existing Flutter mobile apps At this time, Flutter is not suitable for static websites with text-rich flow-based content. For example, blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.
This doesn't even get into one of the worst parts of Flutter Web, which is that is has to ship its own renderer and Skia, causing Flutter Web apps to require at least a ~2.5Mb download.
Flutter was a much better idea when the project was named Razer and its goal was to create a fast subset of the web that could run in the Razer runtime or on the standard web. Once they ditched documents, JS, and chose graphics primitives that the web couldn't support, the project really painted itself into a corner wrt the web.
I think this would be an awesome goal for Servo these days.
Flutter was a much better idea when the project was named Razer and its goal was to create a fast subset of the web that could run in the Razer runtime or on the standard web. Once they ditched documents, JS, and chose graphics primitives that the web couldn't support, the project really painted itself into a corner wrt the web.
I think this would be an awesome goal for Servo these days.
Flutter was previously Sky. Your description of Razer sounds like Cobalt. https://www.cobalt.dev/
Sky was previously Razer. Cobalt is a YouTube project they use for TVs and such.
The first time I heard of Flutter was as Sky in 2015. I can't find any article or video about Razer. Please provide a source.
Source: I worked next to the team.
Cobalt appears to be exactly what you're looking for. How was Razer different?
Razer was by the Chrome team, subsetting (plus some web-compat polyfillable superset) HTML and CSS consciously by design for performance and code size. It would have been great for Cobalt's target.
Cobalt is mostly whatever YouTube can afford to implement and run on TVs.
Cobalt is mostly whatever YouTube can afford to implement and run on TVs.
>Flutter works by throwing away the native UI toolkits provided by the platform and rendering everything from scratch using OpenGL et al.
Flutter leverages GTK3 heavily on Linux. Isn't that the case for other desktop OSes, like, it calls OpenGL/metal or something on Win and Mac? It seems to me that this statement is true only for web and mobile targets, maybe not even there though.
Flutter leverages GTK3 heavily on Linux. Isn't that the case for other desktop OSes, like, it calls OpenGL/metal or something on Win and Mac? It seems to me that this statement is true only for web and mobile targets, maybe not even there though.
Oh wow. I had thought the claim that they were not producing any semantic web elements was almost certainly exaggerated. That said, for the number of things that are on https://gallery.flutter.dev/#/reply, there are a surprisingly low number of elements. Wow.
It's possible the folks who made this demo – which was created years ago – didn't do an a11y pass. Something things need to be wired up for specific scenarios.
Honestly, I don't recommend Flutter for mobile either. I've heard it joking referred to as "the other F-word" because of the performance and compatibility issues it leads to.
Any source to back this claim?
For performance, take the example of the original native Google Pay and the GPay flutter rewrite. The original had much smoother scrolling than the flutter version (on a Pixel 6). Now Google's decided to bring the original back as "Wallet".
As for compatibility, I don't remember the exact details, but it was something along the lines of "the API we need exists, but is limited to google code only, so we can't use it".
As for compatibility, I don't remember the exact details, but it was something along the lines of "the API we need exists, but is limited to google code only, so we can't use it".
Flutter is a pretty nice framework and has a lot of fans, but the web version indeed has issues. The web wants to be the high level framework and doesn't provide low level APIs, Flutter wants to be the high level framework and tries to do that on top of the wrong abstraction level, the result isn't ideal.
There are a few ways to tackle this:
1. Try to improve Flutter Web.
2. Try to improve browsers, so people can use non-HTML frameworks without compromise.
3. Escape the browser.
It doesn't seem likely that (1) or (2) are going to yield much fruit. Flutter already works well on mobile and has picked up a surprisingly large proportion of mobile apps in the app stores. The obvious path is therefore to do the same on the big screen and distribute as desktop apps. The UX can be better than you'd think, especially as internet connections get faster.
This approach solves a lot of the problems the article complains about. Desktop apps can export proper accessibility trees, do keyboard focus properly, they can start really fast and so on (and flutter apps do start fast).
I talked about this path and why it's getting easier on the It's All Widgets podcast [1]. We've added support for Flutter apps to Conveyor [2] so the packaging and deployment aspect is now much better for people who choose to use it. But there's still work to do, to make all that work really well:
• Flutter Desktop has some native code to start and load the VM, which you're expected to customize and compile. That's a pity because the actual code is all Dart bytecode, so this complicates compilation without much justification. It could be made to work the same way as Electron or the JVM where you have pre-made binaries.
• Signing. Conveyor can sign for any OS from any OS so the technical pain goes away, and you can also do self-signing. But "proper" signing is not ideal.
• Sandboxing.
You could have a browser-like thing that provides sandboxing, caching and so on whilst exposing low level APIs, whilst doing a much better job of being 'semantic' than the web ever did. Actually I wrote up a proposal for such a system [3] and sent it to Ian Hickson who runs Flutter, but as he observed, the problem is incentives. Developers generally don't pay for platforms outside of cloud services and game engines, so, nobody is incentivized to build out the infrastructure to solve those problems. For as long as that's the case, people will try to hack the browser into submission.
[1] https://itsallwidgets.com/podcast/episodes/46/mike-hearn
[2] https://hydraulic.software/blog/10-flutter.html
[3] https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
There are a few ways to tackle this:
1. Try to improve Flutter Web.
2. Try to improve browsers, so people can use non-HTML frameworks without compromise.
3. Escape the browser.
It doesn't seem likely that (1) or (2) are going to yield much fruit. Flutter already works well on mobile and has picked up a surprisingly large proportion of mobile apps in the app stores. The obvious path is therefore to do the same on the big screen and distribute as desktop apps. The UX can be better than you'd think, especially as internet connections get faster.
This approach solves a lot of the problems the article complains about. Desktop apps can export proper accessibility trees, do keyboard focus properly, they can start really fast and so on (and flutter apps do start fast).
I talked about this path and why it's getting easier on the It's All Widgets podcast [1]. We've added support for Flutter apps to Conveyor [2] so the packaging and deployment aspect is now much better for people who choose to use it. But there's still work to do, to make all that work really well:
• Flutter Desktop has some native code to start and load the VM, which you're expected to customize and compile. That's a pity because the actual code is all Dart bytecode, so this complicates compilation without much justification. It could be made to work the same way as Electron or the JVM where you have pre-made binaries.
• Signing. Conveyor can sign for any OS from any OS so the technical pain goes away, and you can also do self-signing. But "proper" signing is not ideal.
• Sandboxing.
You could have a browser-like thing that provides sandboxing, caching and so on whilst exposing low level APIs, whilst doing a much better job of being 'semantic' than the web ever did. Actually I wrote up a proposal for such a system [3] and sent it to Ian Hickson who runs Flutter, but as he observed, the problem is incentives. Developers generally don't pay for platforms outside of cloud services and game engines, so, nobody is incentivized to build out the infrastructure to solve those problems. For as long as that's the case, people will try to hack the browser into submission.
[1] https://itsallwidgets.com/podcast/episodes/46/mike-hearn
[2] https://hydraulic.software/blog/10-flutter.html
[3] https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
At the company I work at we currently target 5 platforms across our internal and user-facing apps, (Android, iOS, Linux, Windows, Web), and Web is the one that consistently seems to cause the most issues. Performance is a big one of them, I've done about 8 years of webdev now and there is a noticable performance difference between using a canvas-drawn UI in Flutter and the usual React-based equivalent.
We've mostly stuck to using it for internal applications, as well as for a small portion of our user-base that prefer to access our user-facing mobile app via a desktop. It also serves as a decent backup deployment target if you need to push a hotfix for some users and can't wait for the App Store review to go through.
It doesn't seem like the Semantic HTML issue will ever be solved too, the Flutter team did mention in the latest conference that they're aiming it more to be used for web apps than websites.
For the other platforms however it works great, and I'd definitely recommend it for anyone looking to make a cross-platform app that doesn't need to rely heavily on working on web.