Flutter Web: A Fractal of Bad Design(hugotunius.se)
hugotunius.se
Flutter Web: A Fractal of Bad Design
https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-bad-design.html
83 comments
People say stuff like this all the time but the truth is that Google as a company has very little direction at the scale of niche software like this. Google as an organization is not pushing Flutter in any meaningful capacity or trying to convince everyone to start adopting it. As a sibling comment asked, how would you expect a search engine giant to go for something that makes the web less indexable? The truth is that Google is a massive company with hundreds of teams that have 0 shared interest in any of their products and operate almost entirely independently.
Yeah, people are saying this all the time, but the truth is that it's exactly the direction to web is taking. I'm not pretending to know how the decision was made, but I am pointing out that it goes very well with their bigger plans for the web (HTTP3, AMP, etc).
I'm 100% sure Google will find a way to index Flutter based-website. I'm also 100% sure it'll be much harder to block ads, using a custom stylesheet, use reader mode, and practically any extension that manipulates the page.
I'm 100% sure Google will find a way to index Flutter based-website. I'm also 100% sure it'll be much harder to block ads, using a custom stylesheet, use reader mode, and practically any extension that manipulates the page.
Seconding.
And that's why, unlike some other comments, I worry it will gain traction. Publishers of all kind - news companies, streaming companies, social media - will be more than happy to adopt technologies that take away control over the experience from end users. After all, most of the web already looks like glorified print posters and lifestyle magazines. With Flutter, they'll have the ability to make it impossible for end-users to turn on Reader Mode or remove ads, or branding. The site will look exactly the way the UX experts designed them to, simplifying all kinds of data-driven user abuse.
Now of course, they could've done that already without Flutter. But they didn't, because it's too hard. Regular HTML+CSS+JS are the default. It's what has the mindshare, it's what the devs on the market do, it's what works for everyone, ever since Flash died. It's already good enough to control majority of end-users, so there's no marginal benefit in trying to invent an even more restrictive form of content delivery. It's not worth the time spent fixing bugs and cross-device inconsistencies. But now add a player like Google - with money, mass, and clout - pushing such new solution, and it may be enough. God knows, webdev community just embraces everything Google releases.
And that's why, unlike some other comments, I worry it will gain traction. Publishers of all kind - news companies, streaming companies, social media - will be more than happy to adopt technologies that take away control over the experience from end users. After all, most of the web already looks like glorified print posters and lifestyle magazines. With Flutter, they'll have the ability to make it impossible for end-users to turn on Reader Mode or remove ads, or branding. The site will look exactly the way the UX experts designed them to, simplifying all kinds of data-driven user abuse.
Now of course, they could've done that already without Flutter. But they didn't, because it's too hard. Regular HTML+CSS+JS are the default. It's what has the mindshare, it's what the devs on the market do, it's what works for everyone, ever since Flash died. It's already good enough to control majority of end-users, so there's no marginal benefit in trying to invent an even more restrictive form of content delivery. It's not worth the time spent fixing bugs and cross-device inconsistencies. But now add a player like Google - with money, mass, and clout - pushing such new solution, and it may be enough. God knows, webdev community just embraces everything Google releases.
I doubt that's true. It's a minor side thing of a project, it's easily explained as done this way because it's the easiest, it's unclear it actually makes adblocking that much harder. It seems unlikely that this is a targeted strategy, companies that size generally suck at that.
Sorry if I wasn't clear - I'm not saying someone sat at a meeting titled "how to stop uBlock Origin" and it ended with Flutter. But I do think the overall approach of Google is let's make the internet more of a controlled experience, and Flutter fits perfectly in that approach.
Nah, Flutter Web clearly grew out of Flutter for smartphones. If the dream is write-once run-anywhere, extending to web is just the obvious next step.
Did you read the parent comment ?
> Nah, Flutter Web clearly grew out of Flutter for smartphones. If the dream is write-once run-anywhere, extending to web is just the obvious next step.
Ok.
> Sorry if I wasn't clear ... I do think the overall approach of Google is let's make the internet more of a controlled experience, and Flutter fits perfectly in that approach.
> Nah, Flutter Web clearly grew out of Flutter for smartphones. If the dream is write-once run-anywhere, extending to web is just the obvious next step.
Ok.
> Sorry if I wasn't clear ... I do think the overall approach of Google is let's make the internet more of a controlled experience, and Flutter fits perfectly in that approach.
Of course, and suggesting that Google has an “overall approach” and that Flutter for Web is some nefarious manifestation if it is ridiculous.
the whole screen is a big giant canvas.
I don't necessarily think it was a diberate decision, but Fluttercs CanvasKit is one of the most pernicious evil backwards awful things anyone has done to the web and it absolutely will make ads much much much harder to block.
It uses the web like a vnc session to the app. It is an absolutely sickening perversion of the web & oh it so happens such ads will be unblockable, there'll be no imgs nor divs nor anything else to block, just one massive canvas pushing pixels at you. Gobsmackingly horrible regression for the web, & I am so so so glad someone did a proper job writing up this horrorshow.
I don't necessarily think it was a diberate decision, but Fluttercs CanvasKit is one of the most pernicious evil backwards awful things anyone has done to the web and it absolutely will make ads much much much harder to block.
It uses the web like a vnc session to the app. It is an absolutely sickening perversion of the web & oh it so happens such ads will be unblockable, there'll be no imgs nor divs nor anything else to block, just one massive canvas pushing pixels at you. Gobsmackingly horrible regression for the web, & I am so so so glad someone did a proper job writing up this horrorshow.
Oh, fully agreed that it's a terrible idea on many levels that should be reserved for very niche scenarios(I don't think it's totally useless, and would be curious how well it can be expanded to add accessibility features if the developer cooperates). I just think negligence/ignorance/bad priorities are more likely explanations.
(another technical argument: today you seldom see ads being served from the app domain, despite it being not that difficult and an easy way around domain blocks, because the ad industry doesn't trust that model - so even if the rendering is obfuscated, at least for now ads from Google would still be fetched through stoppable network requests for anti-fraud reasons)
(another technical argument: today you seldom see ads being served from the app domain, despite it being not that difficult and an easy way around domain blocks, because the ad industry doesn't trust that model - so even if the rendering is obfuscated, at least for now ads from Google would still be fetched through stoppable network requests for anti-fraud reasons)
I've heard it suggested that you can build an application fully in canvas but also leave behind a semantic and accessible skeleton for screen readers and crawlers
The two are not two different worlds. Screen-readers might be able to function off a semantic skeleton. But, as the author mentions, tools like Vimium are just going to be forever screwed over, totally shot the hell out of the water, by this post-hypertext abomination. CanvasKit!!!!!!!!!!
Sorry to take your example too literally, but I suspect ad blockers still might work, because at the end, it's really just JavaScript. The network panel still shows everything the app does. Plus when I see the source code, it's still just transpiled js, and even uses standard js libraries, like Google analytics, which are not written in dart.
I specialize in runtime code modification ecosystems who happens to work on a (non-Web) Flutter app, and I don't see any intrinsic reason why Flutter will be somehow fundamentally worse for ad blocking than HTML/JavaScript, simply because of its rendering technique: the issue should only come down to how the code is structured and executed and how much of the semantics can be recovered at runtime. So, on such note, I have not examined the output of the Flutter Web compiler to see if it is ridiculously obfuscated... have you? Again, it isn't at all the case that the way it renders matters: it only matters how easy the behavior is to automatically and safely edit. (Frankly, the end game on ads is AI that does its thing on the resulting view: nothing else makes any sense, as it involves people who are incentivized to not help you to choose to help you.)
Oh my goodness. I tried opening that sample app on mobile and it was like interacting with a touchscreen ticket machine from 2005. I don't know if it was just broken on my browser (firefox android), or expects me to have the latest flagship to actually use it.
Regarding the semantic HTML stuff, I don't think that's an issue inherent to the design, since flutter widgets tend to be highly semantic in nature. In fact, I think a platform like this could good for accessibility if it handles it properly instead of leaving it up to fallible developers.
Regarding the semantic HTML stuff, I don't think that's an issue inherent to the design, since flutter widgets tend to be highly semantic in nature. In fact, I think a platform like this could good for accessibility if it handles it properly instead of leaving it up to fallible developers.
> In fact, I think a platform like this could good for accessibility if it handles it properly instead of leaving it up to fallible developers.
Fluttercs CanvasKit will never be good for accessibility because it will never work with the tools user's use on the rest of the web. Tools expect hypertext, expect a dom, & smashing that on the rocks & turning the web into VNCh no matter how hard the team tries- is going to result in the kind of accessibility that matches well & works across the rest of the web.
Fluttercs CanvasKit will never be good for accessibility because it will never work with the tools user's use on the rest of the web. Tools expect hypertext, expect a dom, & smashing that on the rocks & turning the web into VNCh no matter how hard the team tries- is going to result in the kind of accessibility that matches well & works across the rest of the web.
How though? All of the UI is rendered in a canvas element. This would break most existing screen readers and accessibility tools which rely on properly marked up and parseable HTML. I would suppose that the Flutter devs could provide some sort of bridge that would allow this to work (although I'm not sure how, unless the webkit team also steps in), but seems like an incredible amount of work and IMO with Google's history more likely to be abandoned than actually implemented.
Yes, the real criticism of this article should have focused on the hard-to-fix problem of performance because it seemed absolutely abysmal to me -- multiple seconds before the page showed up as anything but black on both Firefox & Chrome.
I feel like if you're trying to make code Just Work on both the web and any other platform, you either end up implementing HTML and CSS for the other platform, or do something that breaks the web.
> Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.
> - Alan Perlis
> Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.
> - Alan Perlis
You won't get it automatically foolproof, but you'll have at least a good chunk of the information you could expose, and have extension places for developers to easily inform a HTML version. I'm not familiar with the accessibility APIs on mobile, but I presume some of this would also be useful for them.
Alas a bunch of absolutely positioned elements wasn't enough. The team went full "the web is now VNC" mode.
I think this article is far too cynical. These demos show an early version of Flutter Web rather than a stable, production-ready system. I'm not sure how the author stumbled across Flutter Web and thought otherwise, but I think they largely missed the point here; in the very page they link to explaining "Flutter Web", all the content is preceded by a large warning stating that this is a beta and the bottom of the page talks all about use cases where Flutter doesn't make sense on the web [1].
It's important to take a step back here and remember that the web did not start as accessible, nor did any of the native desktop UI frameworks. The author suggests that the only way to "fix" Flutter Web is to throw it all away and start over, which is just patently false when comparing to the history of the competition. Not only would it be ridiculously easy to make Flutter generate semantic HTML without changing any of the core functionality or interface, but in fact HTML already features a widely-used solution for exactly the use case the OP focuses on [2].
The author also tries to take a stab at Flutter initially for attempting to replace HTML, but I think this is another misunderstanding of what Flutter is trying to accomplish. The goal is not to replace the web with something else, but instead streamline creating web apps (in much the same way as React, Vue, etc.) With that in mind, many of the criticisms stop making sense -- are people really expecting CSS restyling tricks and Vimium to work in modern web apps like Google Drive or Discord?
To take one (rather sneering) quote out of the authors playbook:
>To end I’d like to leave you with a quote from Dr. Ian Malcolm.
>Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
[1] https://flutter.dev/web [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
It's important to take a step back here and remember that the web did not start as accessible, nor did any of the native desktop UI frameworks. The author suggests that the only way to "fix" Flutter Web is to throw it all away and start over, which is just patently false when comparing to the history of the competition. Not only would it be ridiculously easy to make Flutter generate semantic HTML without changing any of the core functionality or interface, but in fact HTML already features a widely-used solution for exactly the use case the OP focuses on [2].
The author also tries to take a stab at Flutter initially for attempting to replace HTML, but I think this is another misunderstanding of what Flutter is trying to accomplish. The goal is not to replace the web with something else, but instead streamline creating web apps (in much the same way as React, Vue, etc.) With that in mind, many of the criticisms stop making sense -- are people really expecting CSS restyling tricks and Vimium to work in modern web apps like Google Drive or Discord?
To take one (rather sneering) quote out of the authors playbook:
>To end I’d like to leave you with a quote from Dr. Ian Malcolm.
>Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
[1] https://flutter.dev/web [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Author here, I'll try and write a response to your points.
Yes the post is cynical, I'm the first to admit that. The topic makes me angry because I think we should expect better of frameworks for the web. As a whole Flutter Web moves us in the wrong direction, towards a less open, less standardised, and less transparent web. On the point of accessibility, yes the web didn't start out accessible and in fact we are still struggling with this to this day. As such, a new technology that is a regression in terms of accessibility is a step backwards in 2020 and solid accessiiblity support should be a basic goal of any such technology.
Regarding aria roles, it might be possible to improve Flutter Web by using it but ironically the HTML it generates is so inscrutable that I find it hard to understand if that's a simple fix or a complete overhaul. The general idea of Flutter, to ship an exact pixel by pixel replication of the UI across all platforms, seems incompatible with the open and flexible nature of the web.
> are people really expecting CSS restyling tricks and Vimium to work in modern web apps like Google Drive or Discord?
Yes, that's the beauty of the web as an open and standardised platform after all. The fact the people can experience it in a way that best suites their needs, for accessibility reasons or otherwise, is amazing. Flutter Web is a clear regression in this regard.
> (...)is preceded by a large warning stating that this is a beta and(...)
I mentioned this quite early in the piece, but I am unsure if the issues with Flutter are so fundamental that it would be hard to fix without a complete overhaul or if in fact it would be possible at all. If Flutter Web leaves beta generating semantic and accessible HTML I'll be the first to applaud it, but it doesn't seem likely.
Yes the post is cynical, I'm the first to admit that. The topic makes me angry because I think we should expect better of frameworks for the web. As a whole Flutter Web moves us in the wrong direction, towards a less open, less standardised, and less transparent web. On the point of accessibility, yes the web didn't start out accessible and in fact we are still struggling with this to this day. As such, a new technology that is a regression in terms of accessibility is a step backwards in 2020 and solid accessiiblity support should be a basic goal of any such technology.
Regarding aria roles, it might be possible to improve Flutter Web by using it but ironically the HTML it generates is so inscrutable that I find it hard to understand if that's a simple fix or a complete overhaul. The general idea of Flutter, to ship an exact pixel by pixel replication of the UI across all platforms, seems incompatible with the open and flexible nature of the web.
> are people really expecting CSS restyling tricks and Vimium to work in modern web apps like Google Drive or Discord?
Yes, that's the beauty of the web as an open and standardised platform after all. The fact the people can experience it in a way that best suites their needs, for accessibility reasons or otherwise, is amazing. Flutter Web is a clear regression in this regard.
> (...)is preceded by a large warning stating that this is a beta and(...)
I mentioned this quite early in the piece, but I am unsure if the issues with Flutter are so fundamental that it would be hard to fix without a complete overhaul or if in fact it would be possible at all. If Flutter Web leaves beta generating semantic and accessible HTML I'll be the first to applaud it, but it doesn't seem likely.
Thank you. Unbelievable how many people would rather no one try anything new at all.
This article and the responses show the worst of HN -- bad faith attacks, no attempt to give the benefit of the doubt, no engagement with the underlying vision, unwarranted pessimism.
Why not ask what niche this tech excels in, or what impact a refined version could have? Most projects fail -- that's obvious -- but how might this one succeed?
In short, why so much negativity? The more you default to these views, the likelier it is you and everyone around you will never accomplish anything.
This is the poison that is destroying Hacker News and likewise many startups before they have even been imagined.
This article and the responses show the worst of HN -- bad faith attacks, no attempt to give the benefit of the doubt, no engagement with the underlying vision, unwarranted pessimism.
Why not ask what niche this tech excels in, or what impact a refined version could have? Most projects fail -- that's obvious -- but how might this one succeed?
In short, why so much negativity? The more you default to these views, the likelier it is you and everyone around you will never accomplish anything.
This is the poison that is destroying Hacker News and likewise many startups before they have even been imagined.
> are people really expecting CSS restyling tricks and Vimium to work in modern web apps like Google Drive or Discord
What's the problem? Modern web browsers are already dumbed down, now you want web pages to be dumbed down too?
What's the problem? Modern web browsers are already dumbed down, now you want web pages to be dumbed down too?
I don't think any person, even remotely, concerned about the open web / accessibility / building decent user experiences ever considered Flutter Web as a viable option for developing web apps.
The only people I've EVER heard talk positively about this is Google & other Flutter Developers that don't seem too concerned about web standards.
The only people I've EVER heard talk positively about this is Google & other Flutter Developers that don't seem too concerned about web standards.
Also let's be honest I'm not sure flutter web really matters.
Flutter is a cross-paltform app framework. If you have a app on all platforms you (the company) care about the web app would often become just a seconds class citizen which you (the company) only have as some users are hesitant to install apps and some few users have some exotic platform or need access during holidays after their laptop was stolen etc. Anyway from a business POV a second/third class citizen you don't want to spend much money on. So flutter web would be good enough (once it's out of beta, at which point text selection likely will somewhat work).
But if you ever have a web app as first class target you probably would never go for flutter anyway.
My prediction:
- Flutter will long term be come the new default native way to write apps on google phones. Dart will very slowly replace java.
- Flutter will become a serious way to write the UI of apps on Linux, through maybe not as big as Qt/Gtk. But likely a common choice companies which target Linux as 2nd/3rd class citizen.
- Companies mainly targeting Android will use flutter for their iOs, Windows, Linux, Web apps to save cost.
- Google pushes some new Web API's around accessibility to provide a better flutter on web experience. Making it again harder for non chrome browsers, through in this case not intentionally.
Flutter is a cross-paltform app framework. If you have a app on all platforms you (the company) care about the web app would often become just a seconds class citizen which you (the company) only have as some users are hesitant to install apps and some few users have some exotic platform or need access during holidays after their laptop was stolen etc. Anyway from a business POV a second/third class citizen you don't want to spend much money on. So flutter web would be good enough (once it's out of beta, at which point text selection likely will somewhat work).
But if you ever have a web app as first class target you probably would never go for flutter anyway.
My prediction:
- Flutter will long term be come the new default native way to write apps on google phones. Dart will very slowly replace java.
- Flutter will become a serious way to write the UI of apps on Linux, through maybe not as big as Qt/Gtk. But likely a common choice companies which target Linux as 2nd/3rd class citizen.
- Companies mainly targeting Android will use flutter for their iOs, Windows, Linux, Web apps to save cost.
- Google pushes some new Web API's around accessibility to provide a better flutter on web experience. Making it again harder for non chrome browsers, through in this case not intentionally.
Yea to me I honestly think Google is throwing stuff at a wall and seeing what sticks. Personally I hope Flutter remains primarily on mobile.
I really doubt that Flutter/Dart will displace Android/Jetpack Compose/Kotlin. Kotlin already very quickly replaced Java for new Android code at many places, and it offers big productivity advantages without any downsides. So, on Android there’s a strengthening incumbent.
I think Flutter could evolve an interesting platform for “line of business” or “rapid application development” projects, similar to Lazarus/Delphi. In that respect, I agree that we could see growth for flutter for low-cost cross-platform projects, and on Linux.
But, after the failures of React Native, none of the mobile developers I talk to have any interest in these non-native, layered-on-top frameworks that need a plugins ecosystem to call into native code or native APIs. Your productivity is basically held hostage by the runtime to an even greater degree than it already is on a mobile OS.
I also don’t thing Google needs any new web APIs to make Flutter accessible. They can position some invisible divs with the right spots with the right WARIA attributes.
I think Flutter could evolve an interesting platform for “line of business” or “rapid application development” projects, similar to Lazarus/Delphi. In that respect, I agree that we could see growth for flutter for low-cost cross-platform projects, and on Linux.
But, after the failures of React Native, none of the mobile developers I talk to have any interest in these non-native, layered-on-top frameworks that need a plugins ecosystem to call into native code or native APIs. Your productivity is basically held hostage by the runtime to an even greater degree than it already is on a mobile OS.
I also don’t thing Google needs any new web APIs to make Flutter accessible. They can position some invisible divs with the right spots with the right WARIA attributes.
The major downside of Dart is no threading. Once they decide to fix that, there's not much standing in the way from completely replacing all the java bits.
React Native has issues from how it bridges all the things from React to native. Flutter shims in the native APIs, but uses it's own components to avoid the bridge issue.
In 2 years, most Android phones are no longer getting updates. Since the flutter app carries along most of its own dependencies, it can continue to provide up-to-date software long after the manufacturers have abandoned users.
Flutter's canvas approach is literally Macromedia Flash all over again. I don't care if it's possible to shim in A11Y into flutter, it's bad for the web and bad for users. They need to rethink how to convert their renderer into DOM elements.
React Native has issues from how it bridges all the things from React to native. Flutter shims in the native APIs, but uses it's own components to avoid the bridge issue.
In 2 years, most Android phones are no longer getting updates. Since the flutter app carries along most of its own dependencies, it can continue to provide up-to-date software long after the manufacturers have abandoned users.
Flutter's canvas approach is literally Macromedia Flash all over again. I don't care if it's possible to shim in A11Y into flutter, it's bad for the web and bad for users. They need to rethink how to convert their renderer into DOM elements.
But the issue is that people are considering flutter for mobile to build decent user experiences, which it cannot achieve being flash player like
Considering or are? 2 very different things. How do you mean "Flash player like"?
Flutter is riddled with correctness bugs, missing features (e.g no true svg support) , critical performance issues (https://github.com/flutter/flutter/issues/31138) and an uncanny valley of UX behavior.
100%.
I'm a Flutter developer and I believe that you can create very good apps with it for Android and iOS already and it has great potential on the desktop.
The Flutter developer and user experience on the web is, however, not great. As a dev, you don't see the HTML elements you are used to, and as a user, some things will behave strangely or not work at all. I can spot a Flutter web app in about 3 seconds (I have a web developer background).
In my opinion, Flutter for web makes sense when you already have mobile apps and you want to offer your services on the web quickly. You can build your existing mobile apps for the web in a matter of hours in most cases. However, if your company realizes that the web platform is important for the customers, it makes sense to invest time to migrate off of Flutter web to React/Vue/Angular, or if you want to share code or you just like Dart, you can also use AngularDart.
Flutter for web might be overhyped, but for some purposes, it makes sense as a temporary solution, as a quick win.
It's also important to keep in mind that the web offering of Flutter is not yet stable, so the team is very much aware that it's "not there yet".
The Flutter developer and user experience on the web is, however, not great. As a dev, you don't see the HTML elements you are used to, and as a user, some things will behave strangely or not work at all. I can spot a Flutter web app in about 3 seconds (I have a web developer background).
In my opinion, Flutter for web makes sense when you already have mobile apps and you want to offer your services on the web quickly. You can build your existing mobile apps for the web in a matter of hours in most cases. However, if your company realizes that the web platform is important for the customers, it makes sense to invest time to migrate off of Flutter web to React/Vue/Angular, or if you want to share code or you just like Dart, you can also use AngularDart.
Flutter for web might be overhyped, but for some purposes, it makes sense as a temporary solution, as a quick win.
It's also important to keep in mind that the web offering of Flutter is not yet stable, so the team is very much aware that it's "not there yet".
This reminds me of Adobe's early attempts to get Flash on the iPhone. You could publish a Flash project to target iOS with their AIR runtime, which converted everything into OpenGL. Tons of people made apps with it, but the performance was terrible and all the UI controls were non-native and thus had no voiceover support. This is just Google reinventing or should I say rediscovering past techniques of app building.
I don't think so.
A major difference is that as far as I can tell flutter is long term meant to be the main way to write native Android apps.
Flutter on web has this kind of problem due to how they handle text differently then a HTML does and HTML provides no way to customize it to the way they need it.
Flutter on Android, iOs, Linux, etc. won't have this problem.
Most modern UI's render with a graphics API like OpenGl (ES), Firefox does so for HTML.
A major difference is that as far as I can tell flutter is long term meant to be the main way to write native Android apps.
Flutter on web has this kind of problem due to how they handle text differently then a HTML does and HTML provides no way to customize it to the way they need it.
Flutter on Android, iOs, Linux, etc. won't have this problem.
Most modern UI's render with a graphics API like OpenGl (ES), Firefox does so for HTML.
Flutter has not been designated as the long term means of writing Android applications.
Given that the underlying Android system heavily relies on the JVM, the heavy emphasis on Kotlin support and the 3rd party nature of Flutter (you need to build bridges to use it) it is simply yet another x-platform tool to build mobile applications.
Given that the underlying Android system heavily relies on the JVM, the heavy emphasis on Kotlin support and the 3rd party nature of Flutter (you need to build bridges to use it) it is simply yet another x-platform tool to build mobile applications.
> 3rd party nature of Flutter
Currently yes, but I believe long term this will change.
Currently yes, but I believe long term this will change.
It could become the go to way in the future. Google is definitely gauging the enthusiasm of their developer base to see where they move to. It is what happened with Kotlin in the first place.
And they aren't putting all of their eggs in the same basket as Jetpack Compose is now in active development and will, once ready, rival SwiftUI in functionality and power.
I hope there will be flexibility and support for both in the future. Flutter has its positives and negatives as everything else. Same can be said about native development.
And they aren't putting all of their eggs in the same basket as Jetpack Compose is now in active development and will, once ready, rival SwiftUI in functionality and power.
I hope there will be flexibility and support for both in the future. Flutter has its positives and negatives as everything else. Same can be said about native development.
The main value is to target multiple platforms at once.
Otherwise there's no point in choosing Flutter to develop for the web.
Otherwise there's no point in choosing Flutter to develop for the web.
[deleted]
As someone who shipped an app in Flutter on Android and iOS, there is practically 0 code re-usability between web and mobile. Regardless of platform, mobile apps feel the same - they both have navbars, tab bars, lists and table views, etc. Even if I could use an iOS navbar on web, it would look so out of place it's not worth considering.
Okay, so you can't reuse UI components, surely you can reuse the Dart code that makes up the guts of the webapp? And, sure, you could, but why would you when you can spend maybe 10 minutes to translate it to native JS (the two languages are practically identical) and ship it without the Flutter Web dependency?
I actually feel like it'd be easier for me to convert some of my Flutter components into React ones, than to try and learn Flutter Web and set up its whole toolchain. I think it's a cool idea, but it's not meant for widespread use (speculation): it's meant specifically for Google's Fuchsia, where they are probably planning on shipping Web applications pretending to be native desktop apps along with the full Chrome experience much like they did for Chromebook.
Okay, so you can't reuse UI components, surely you can reuse the Dart code that makes up the guts of the webapp? And, sure, you could, but why would you when you can spend maybe 10 minutes to translate it to native JS (the two languages are practically identical) and ship it without the Flutter Web dependency?
I actually feel like it'd be easier for me to convert some of my Flutter components into React ones, than to try and learn Flutter Web and set up its whole toolchain. I think it's a cool idea, but it's not meant for widespread use (speculation): it's meant specifically for Google's Fuchsia, where they are probably planning on shipping Web applications pretending to be native desktop apps along with the full Chrome experience much like they did for Chromebook.
Just reminds me of flash in general. It was effectively a reliable cross-browser 'vector canvas' that was a dream for developers but a completely inaccessible, closed system to everyone else. No doubt they will get there with performance on flutter, but the decade-old concerns per flash's demise will be harder to address.
I'm starting a new project in flutter and have a decent chunk of experience with frontend tech.
Here's my thoughts on it so far, starting with the good:
- Rendering performance is really good
- Live reload is the best I've seen on any platform
- Layout/rendering engine is powerful and the widgets are high-quality - building your own widgets for a cross platform UI framework is the right way to go because building abstractions between cross platform stuff (like Xamarin.Forms) winds up giving you the lowest common denominator
The bad :
- Dart language while functional is very tedious and pointlessly rigid - you can see the language is designed by VM engineers - it makes silly UX choices for the sake of implementation performance - TypeScript is a much better language despite it's legacy JS constraints
- tooling works (which is a nice surprise in the npm era) but can be spotty (eg. IDE/analysis engine craps out hard on invalid code it brings my 32GB ram/6 core i9 to a crawl at times)
- the framework itself is also designed in the spirit of the language - a lot of effort towards implementation and performance convenience and very little effort on developer usability for the APIs - the new Navigator 2.0/Router is an excellent example - the worst router implementation I've seen to date. Also their documentation leaves a lot to be desired
- Flutter framework architecture seems immature - it lacks tools for efficient design patterns from both OO and FP worlds, their BLoC state management is a complicated mess that offers very little value - Redux is far superior in this regard but the language is so limited that using Redux approach is just too verbose
I agree with authors objections but I disagree with the conclusion - I think web apps need to move away from DOM as the UI rendering engine - DOM was built for documents not applications - the semantic information he's crying about is a result of patchwork of repurposed tools.
Flutter has really good accessibility tech and IMO the Flutter Web problem is IMO that they are not taking the DOM out of the equation far enough - ideally it would just be a WebGL canvas rendering the UI and it would integrate with accessibility tech in other ways. The practical problem with that is that WebGL is a sandboxed version of native GL API so the performance of building Skia on WebGL could be significantly worse than native.
Here's my thoughts on it so far, starting with the good:
- Rendering performance is really good
- Live reload is the best I've seen on any platform
- Layout/rendering engine is powerful and the widgets are high-quality - building your own widgets for a cross platform UI framework is the right way to go because building abstractions between cross platform stuff (like Xamarin.Forms) winds up giving you the lowest common denominator
The bad :
- Dart language while functional is very tedious and pointlessly rigid - you can see the language is designed by VM engineers - it makes silly UX choices for the sake of implementation performance - TypeScript is a much better language despite it's legacy JS constraints
- tooling works (which is a nice surprise in the npm era) but can be spotty (eg. IDE/analysis engine craps out hard on invalid code it brings my 32GB ram/6 core i9 to a crawl at times)
- the framework itself is also designed in the spirit of the language - a lot of effort towards implementation and performance convenience and very little effort on developer usability for the APIs - the new Navigator 2.0/Router is an excellent example - the worst router implementation I've seen to date. Also their documentation leaves a lot to be desired
- Flutter framework architecture seems immature - it lacks tools for efficient design patterns from both OO and FP worlds, their BLoC state management is a complicated mess that offers very little value - Redux is far superior in this regard but the language is so limited that using Redux approach is just too verbose
I agree with authors objections but I disagree with the conclusion - I think web apps need to move away from DOM as the UI rendering engine - DOM was built for documents not applications - the semantic information he's crying about is a result of patchwork of repurposed tools.
Flutter has really good accessibility tech and IMO the Flutter Web problem is IMO that they are not taking the DOM out of the equation far enough - ideally it would just be a WebGL canvas rendering the UI and it would integrate with accessibility tech in other ways. The practical problem with that is that WebGL is a sandboxed version of native GL API so the performance of building Skia on WebGL could be significantly worse than native.
There is no sane way of running automated acceptance tests for any of these canvas thingies. All existing test automation tools rely on proper DOM with even somewhat semantic HTML. If everything is just canvas, we are back to image recignition and clicking by coordinates. And that is always extremely slow and brittle approach; one color change requires updates to many many reference images. Resolution/scaling/window size/window position changes coordinates. Etc etc.
In practice there is no way of testing pages done using Flutter Web.
In practice there is no way of testing pages done using Flutter Web.
Anecdotally, we currently have one mobile app (500k-ish users) and one web app (2500-ish users) both in Flutter. Even though there is still a lot that needs to improve in Flutter web, our frontend team promised the web app in 3 months and ended up delivering (in 3.5 months) web and mobile version of the small (2500-ish users) app. Users seems to love it, business stakeholders were thrilled and the frontend team enjoyed working with the framework.
Inspect Element doesn't even work on the Demo App they linked to. It's covered by this glass pane so you can't get past.
In Clutter's CanvasKit there is just a canvas, pushing pixels in your face. Be glad you got a hard to use DOM, that's better than the abomination that is coming.
You seem you have a hate boner for CanvasKit. It's just a Skia project that Flutter uses as one of its render targets. It's main use is to provide a better Canvas painting API than what browsers offer natively.
I do quite dislike those who substitute out the HyperText Markup Language for big giant moving pictures, yes. Having my rich media replaced by extremely dumb media that I cannot deploy extensions against is, imo, a colossal downgrade & deeply deeply injurious to civilization, a severe & critical regression against information's usability & utility.
Anybody else get flashbacks to the days of Adobe Flash with regards to Flutter Web? About the only positive difference I see is that it uses the browser sandbox vs the Flash player and is thus arguably more secure, but otherwise it feels it has most of the same drawbacks.
I've got 2 issues with that blog post:
1- it seems concerned with accessibility, and accessibility only, and accessibility from standard 3rd party tools only. Leaping from accessibility issues in alpha software to "fractal of bad" seems a bit rushed
2- It's entirely negative. Cross-platform aside (which is a huge win if it ends up working), HTML/js has issues, and Flutter has solutions. Certainly not universal and perfect, but I'm sure useful at least in some cases ?
Can maybe Google get flutter to compile down to semantic html hence addressing writers concerns
This is what the author was addressing with "It’s worth noting that Flutter for Web is currently in beta and the problems I am about to detail could be addressed. However, I believe these issues are fundamental to Flutter’s design choices so I feel confident in my criticism."
I agree, this is a fundamental problem they are probably unable to fix.
I agree, this is a fundamental problem they are probably unable to fix.
For me it looked like that, too. I.e. flutter will never work friction less with the current web, at least for screen
readers etc.
But I think what google will try to do in one or two years is to add extensions to the web to make flutter work well again (from their POV).
But I think what google will try to do in one or two years is to add extensions to the web to make flutter work well again (from their POV).
It was always my impression that rendering to a canvas was the quick n dirty way to get something running on the web, not the long term plan for flutter
The article is missing the point of flutter. It's designed to build apps, not semantic web.
No way flutter apps will be indexable. I believe one of the web rendering backends(there are 2) is using webgl and compiles to webassembly, so there goes your divs...
But I must say as an app programming platform, flutter is brilliant. The ability to pass around statically typed classes representing everything from widget to text style to animation is so fast and logical, that it actually made me enjoy frontend programming. No need to mess around with html+js+css+some macro language to glue it together.
Did I mention i run the same flutter app on android, ios, web and linux box? I just wish they would use something like kotlin instead of dart, but still, it's well worth it.
But I must say as an app programming platform, flutter is brilliant. The ability to pass around statically typed classes representing everything from widget to text style to animation is so fast and logical, that it actually made me enjoy frontend programming. No need to mess around with html+js+css+some macro language to glue it together.
Did I mention i run the same flutter app on android, ios, web and linux box? I just wish they would use something like kotlin instead of dart, but still, it's well worth it.
It is a generic accessibility problem with any UI toolkit that goes beyond the "native toolchain". However, customizing everything from drawing layer is the only way to achieve any kind of UI consistency, especially on mobile. You can go very far with React Native approach (using native widgets), but there are limits.
There are many failed attempts to draw UI oneself. But ultimately, it is because development cost (you need to implement a lot of widgets, supporting new OS capabilities in on-going basis). If Google can support these development cost, it can be done.
Accessibility issues can be solved for these toolkits. OS often exposed some kind of the API to achieve that. For web, you certainly can have hidden elements to support accessibility. Again, it is just a matter of development cost.
As you said, nobody should seriously mistake Flutter app with semantic web. Most of the SPA online will break if you style CSS differently or disable Javascript, this is just the world we live in. The missing of semantic information for Flutter app should be treated as the generic accessibility problem, not some resistance to the semantic web vision.
There are many failed attempts to draw UI oneself. But ultimately, it is because development cost (you need to implement a lot of widgets, supporting new OS capabilities in on-going basis). If Google can support these development cost, it can be done.
Accessibility issues can be solved for these toolkits. OS often exposed some kind of the API to achieve that. For web, you certainly can have hidden elements to support accessibility. Again, it is just a matter of development cost.
As you said, nobody should seriously mistake Flutter app with semantic web. Most of the SPA online will break if you style CSS differently or disable Javascript, this is just the world we live in. The missing of semantic information for Flutter app should be treated as the generic accessibility problem, not some resistance to the semantic web vision.
If you want a linked network of documents, HTML / semantic web is great. Problem is, sometimes you want interactive elements in your document (like navigation menus), and sometimes you want a layout that is precise but is also responsive to the browser width, and sometimes you really want a native application that works on all platforms that people don't have to download (and update) something special. HTML and semantic web get less and less useful as you go down that list. Flutter is trying to solve the cross-platform application problem. If your problem is well-addressed by a document, then you don't have the same problem that Flutter is solving, so yeah, you probably won't like it.
A uninformative rant about a software beta. Personally I am tired of these sort of posts that scream about how everything new is terrible because it doesn't have X feature that is super important for "accessibility".
No not every application framework needs to be the same so that your vim extension can work properly.
No not every application framework needs to be the same so that your vim extension can work properly.
It's not at all about vim extensions.
It's about people with visual or motoric impairments using the web.
It's about people with visual or motoric impairments using the web.
Beta version of software often ignore users that may have visual or motoric impairment. Plus much of the web is hositle to disabled folks already (like youtube not having closed captions on many popular videos) it's not a good argument against flutter imo.
I think you're missing a lot when you start comparing the web to vim extensions, IMO of course.
I didn't know flutter for web was do abysmal
I've got to issues with that blog post:
1- it seems concerned with accessibility, and accessibility only
[deleted]
> How did anyone look at this and say “yeah nah, selecting text isn’t an important use case on the web”?
If you firstly target mobile. Many users will hardly ever select text and will be used to it not working sometimes.
So while it's horrible bad it's also not at the top of the priority list and "can be done later".
If you firstly target mobile. Many users will hardly ever select text and will be used to it not working sometimes.
So while it's horrible bad it's also not at the top of the priority list and "can be done later".
Yes, mobile users will never try to highlight and select text to "search with Google" or copy to paste into another application. That's a pretty huge design flaw. I highlight text all the time mate. Pretty common feature for some of us who read on our fondle-slabs.
Sure you do,
but look at non tech-savvy people.
I have meet more then one or two people which wouldn't even be sure you can copy past text if you ask them now.
but look at non tech-savvy people.
I have meet more then one or two people which wouldn't even be sure you can copy past text if you ask them now.
My elderly family members copy and paste recipes for cooking on their kitchen tablets into notes on their devices so they can edit them. I think the barrier for copy/paste is pretty low.
Developers, resist. One the Web is built with Flutter it'll not be the Web anymore. It's be like TV.