Is Flutter interesting as a way to create a cross iOS/Android app? I don't know, maybe. But I do know their web experience is atrocious. Terrible performance, no standard OS-level ergonomics, essentially Flash all over again with a single <canvas> tag. Why would anyone ever sign off on shipping something with this on the web except maybe some weird enterprise-y internal app?
It works great for apps, especially ones with lots of interactive or graphics heavy elements. Treat it like Flash, yes, you wouldn't make a game out of DOM interactions. You could, but most people used something like Flash to do so.
I keep hearing good things about Flutter, it's seems like a bit of a quiet hit. We've added support for Flutter Desktop in the next release of Hydraulic Conveyor so it'll get a lot easier to distribute Flutter apps outside the browser soon. There's a demo of how to package Flutter apps built using Github Actions here:
(see the conveyor.conf file, it's a normal Flutter Desktop app other than that). That won't work with the current release but we should get the next one out this week or next.
This should be great for people who want to bring their cross-platform mobile app to laptops and other form factors without exploding costs by needing to write/maintain an HTML version too. That duplication really isn't ideal for a lot of reasons e.g. some users will end up trying to use the web version from mobile so you end up with actually 4x frontend dev costs (iOS, Android, web desktop, web mobile) and for smaller projects it's just hard to justify.
Traditionally desktop deployment was a huge pain and that pushes people towards trying to use Chrome for everything, because it handles updates and uploading a few files to a web server is easy. With Conveyor and easily available multi-platform CI for compiles that's fixed now, the hardest part is buying the signing certificates which is just a bit of paperwork and money. The problem with trying to do everything with WebAssembly and canvas is that you're paying a big perf hit and due to cache partitioning you can't really reduce the size hit of an alternative language and graphics stack by amortizing it across different sites like was once possible. And browsers aren't interested in making it easy for people to do that, they want to control the whole experience, so there's lots of paper cuts and apps written with Flutter are ultimately going to be best experienced outside the browser.
> Reinventing UI frameworks from absolute scratch is always going to be janky and playing catch-up, on every platform.
Why? UI framework build from absolute scratch can be build using same low level APIs as platform's native UI framework. Performance depends on framework's architecture and quality of the implementation.
RN can only be worse or equal as the underlying native UI framework. UI framework build from scratch can be worse, equal or better.
The problem I see with cross platform UI frameworks, at least on desktop, is that often they don’t come with a full compliment of widgets with the dev being told they’re on their own for surprisingly basic things.
A lot of newer UI frameworks have nothing resembling a tableview with sort and columns/rows that can be rearranged with drag and drop for example, which is insane to me. These things have been standard in desktop OS UI frameworks for ages.
This kills my motivation when trying these frameworks out. I don’t want to be hunting down some half baked third party dependencies for various widgets or rolling my own, I want to be writing application code.
The Flutter 3.7 article on The Register[1] had great quotes throughout. Which often sent cold shivers down my spine.
> "Historically, people built for the web using the Document Object Model and HTML," explained Sneath. "And that was kind of the only way to build web apps. Now, over the last couple of years, between Canvas and WebAssembly, we've got these new technologies that enable a different class of web app experience. And so Flutter is unapologetically aiming at that next-generation class."
So, you're saying we will abandon DOM and HTML & use Canvas to push pixels in people's faces? That... does not sound very web like to me. The "different class" that Flutter is "unapologetic" about sounds like VNC or Flash; a completely controlled, locked down, isolated little fief nestled inside the web page. Again, like Flash.
> "We're aiming at this next class of apps that look very much like the kinds of apps that Flutter is designed to solve – high graphical fidelity, offering pixel level of control over apps, having a canvas where you can draw and manage every part of the environment yourself."
Not on Flutters priority list/not supported after the Flutter revolution: user-agency, web extensions, view-source, malleability, standards, interoperability, support from existing accessibility tools.
I actually think Flutter is an interesting set of tech & am glad to see another entrant to building apps. But every-time they open their mouth, it's to badmouth & insult the web, to highlight how their game plan to win is by becoming evil & ruining interoperability & standards as hard & fast as they can.
The priority system here seems deranged & anti-human to me; 'we take the only successful standards based hyper-medium on the planet, and we reduce it to a Canvas renderer that shoves pixels in your face, with 100% control from Google over what those pixels are and how they work.' We forfeit all user control, we give up all ability to read & parse & modify each other's web content. And for what? "Pixel perfect level of control?" "High graphical fidelity"? "Draw and manage every part of the environment yourself?" Bro, your app is not that important. There's other kinds of delight; I think users are waking up to how shallow & controlled & manipulative apps are, and doubling down on "we just need slicker design systems to really really delight our users" (and capture them for good!) is a limited game.
This is a nightmare, one where only a very very few players have control over the technological environment, one where humanity has no say, no stake, no control. What Flutter proposes is the most polarizing end of what Ursala Franklin talks about in technological society, where who can build the environment, who has say, how things form is extremely narrowly controlled. It talks to utterly prescriptivist ends where humankind merely receives technology as it is built from the corporation, and that end is forever & always enough (& all that is possible). The web, to me, has been defined & shaped by being more, by being better, by having a deeper level of engagement, owing to a malleable & open platform that users participate in, every time we install an extension, every time we run a user style sheet; a holism.
When we invited the "intertwingularity" back in the Cluetrain Manifesto days, there was a value system trying to come out, that humanity is empowered when systems are open & out there & when we can explore what is possible. I welcome technological innovation, but the wanton disregard & active badmouthing the Flutter spokespeople have for malleable systems, for standards & interoperation, their willingness to inflate their own importance by insulting & denigrating web extensions, user agency: it's an incredibly poor look for their would be new Flash project, for their attempt to make an impervious, inaccessible, unmodifiable prison of control within the web & atop native. I'd like to see a tone shift, where they talk about how they'll better work with the web, rather than usurp it's bones to build a new monstrous titan of app-dev.
Thankfully this 3.7 release actually has some perhaps possible good news, that maybe/perhaps Flutter can be intermixed somewhat with HTML/DOM on the page. The Register suggests perhaps Flutter's HTML/DOM mode and it's CanvasKit pixel-blaster mode can perhaps interoperate some. It's hard to tell right now how well Flutter might possibly be able to play within the web. But it's hard to recognize even the possibility- to see that the Flutter team really has any empathy what-so-ever for the web & web standards- when their rhetoric so proudly champions things that seem actively bad for the user, when so much of the work still looks like source-free, unmodifiable islands of Flash on the page; it wasn't good then, & it's still harmful now, & it's hard to appreciate the potential gain when it so lopsidedly enhances corporate control. But at least there is some evidence that Flutter is trying to do a little more interweaving than before... although again, it's hard to recognize that when the current rhetoric from the team is so mono-focused on their graphical capabilities above all.
It's a little dispiriting to read a screed like this, because it doesn't represent the work we're doing. I think a slightly deeper evaluation beyond a skim-read of a Register article might be worthwhile before jumping to such strong conclusions.
In our talk, we explicitly say that today's web is the most amazing and pervasive platform ever built. And frameworks like Angular, React and vue.js serve the DOM-based model very well. Probably this will remain the vast majority of the web for the foreseeable future. But there are classes of apps like Rive (https://rive.app), Figma, or Google Sheets for that matter, that are hard to build on the web without using a technology like Canvas. I don't think that's "pushing pixels in people's faces" - it's simply using the right web standards for the job.
Canvas itself is a relatively low-level standard: it's good for drawing pixels. And so it might be useful to have a framework that enables animations and perhaps even some UI primitives here. Flutter's web work is an attempt at solving that problem, because we've already built a portable architecture for these capabilities. If you were building the next Figma or Rive, perhaps you'd see something useful in our open source toolkit. That's it. Nothing so nefarious as to be "deranged and anti-human".
I also can't let the accessibility comment go: that's a top priority for us, and we're very interested in reproducible issues there. It's been one of our biggest areas of investment to date.
Our early prototype demo (https://flutter-forward-demos.web.app) shows some examples of how we hope this will be integrated into a regular web page. (Disclaimer: this is built with our unstable branch, so may have some bugs.)
"one where only a very very few players have control over the technological environment, one where humanity has no say, no stake, no control"
Well, it's worth bearing in mind that what you call a standards based hypermedium is now completely unimplementable by anyone except Google, Apple and companies funded by Google. Insisting that everyone writes web apps doesn't mean software exists in some sort of communitarian utopia, it just means that it's the Chrome team that gets to decide how everything works. Like extensions for example, hence Manifest V3.
There's no really deep reason Flutter or other toolkits can't support more interesting and powerful hackability than what web extensions allow. Look at the JVM - it's not the web, but with tools like JVM agents, JMX, classloaders and so on you can extensively modify apps that run on it even without source code access. That's how the Minecraft mod scene developed and it's why you can so easily write plugins for IntelliJ. After all, web pages aren't actually designed to be modified by extensions. It's usually a giant hack. They come with megabytes of minified JS and attempts to modify them frequently break or require constant maintenance. That's why there are relatively few extensions that see actual usage outside of ad blockers, the cost to keep them going is just too high. And that in turn is partly because web apps usually don't have any kind of plugin architecture comparable to what desktop apps have often provided. At best they might have some sort of Google Docs like store, where the web app developer gets to pick and choose what integrations are allowed, but nothing as open as something like Photoshop plugins or Office OLE objects, where the end user got to install things the original developers had never even imagined.
So I reckon you're being kind of harsh here. HTML is hardly a technological utopia. Why shouldn't people try to do better? There's no reason progress and extension APIs have to be in tension.
Flutter just needs to close up shop - I'm surprised it's still going after the layoffs. The value of a cross-platform SDK just doesn't make sense anymore. If you are a small startup, going iOS only is feasible. If you are a huge company, you'll need native devs anyway, so why add a Google dependency? Makes no sense.
> The value of a cross-platform SDK just doesn't make sense anymore.
It makes perfect sense to the market. Flutter in fact fills a niche that does pay off in many use cases. Is it the perfect fit for everything? No, but for many small dev shops "going iOS only" is not feasible at all, since they need market penetration across platforms; and going native for two platforms is not practical since they don't have the dev resources.
Without Flutter that's the opposite, only the Android app would have existed and I would have gave up on iOS. Flutter is the only reason the iOS app exists at all.
I'm in a market where 95%+ of users are on Android and the lower quality of the dev ecosystem on Apple platforms isn't exactly helping.
We did use flutter to build something like a companion app for our B2B product targeted at enterprises. One dev supported Android and iOS and performance was good (no battery issues, etc for an app that was mostly always running). It was a blessing that we chose a cross platform approach as our users did not decide which the devices they use, corporate does. And it can change its mind.
I do get the fear of the Google dependency, though. I did feel lucky that support did not end before we were done with it.
There's a reason they held their conference in Kenya. Flutter is very popular in Africa & Asia. For American & maybe European startups iOS only is feasible, everywhere else not so much.
[+] [-] jaredcwhite|3 years ago|reply
[+] [-] gman83|3 years ago|reply
[+] [-] satvikpendem|3 years ago|reply
[+] [-] mike_hearn|3 years ago|reply
https://github.com/hydraulic-software/flutter-demo/
(see the conveyor.conf file, it's a normal Flutter Desktop app other than that). That won't work with the current release but we should get the next one out this week or next.
This should be great for people who want to bring their cross-platform mobile app to laptops and other form factors without exploding costs by needing to write/maintain an HTML version too. That duplication really isn't ideal for a lot of reasons e.g. some users will end up trying to use the web version from mobile so you end up with actually 4x frontend dev costs (iOS, Android, web desktop, web mobile) and for smaller projects it's just hard to justify.
Traditionally desktop deployment was a huge pain and that pushes people towards trying to use Chrome for everything, because it handles updates and uploading a few files to a web server is easy. With Conveyor and easily available multi-platform CI for compiles that's fixed now, the hardest part is buying the signing certificates which is just a bit of paperwork and money. The problem with trying to do everything with WebAssembly and canvas is that you're paying a big perf hit and due to cache partitioning you can't really reduce the size hit of an alternative language and graphics stack by amortizing it across different sites like was once possible. And browsers aren't interested in making it easy for people to do that, they want to control the whole experience, so there's lots of paper cuts and apps written with Flutter are ultimately going to be best experienced outside the browser.
[1] https://hydraulic.software/
[+] [-] fnfjfk|3 years ago|reply
At least RN uses normal UIKit controls on iOS that work and feel like normal.
[+] [-] zigzag312|3 years ago|reply
Why? UI framework build from absolute scratch can be build using same low level APIs as platform's native UI framework. Performance depends on framework's architecture and quality of the implementation.
RN can only be worse or equal as the underlying native UI framework. UI framework build from scratch can be worse, equal or better.
[+] [-] kitsunesoba|3 years ago|reply
A lot of newer UI frameworks have nothing resembling a tableview with sort and columns/rows that can be rearranged with drag and drop for example, which is insane to me. These things have been standard in desktop OS UI frameworks for ages.
This kills my motivation when trying these frameworks out. I don’t want to be hunting down some half baked third party dependencies for various widgets or rolling my own, I want to be writing application code.
[+] [-] mike_hearn|3 years ago|reply
[+] [-] bsaul|3 years ago|reply
[+] [-] urbandw311er|3 years ago|reply
[+] [-] rektide|3 years ago|reply
> "Historically, people built for the web using the Document Object Model and HTML," explained Sneath. "And that was kind of the only way to build web apps. Now, over the last couple of years, between Canvas and WebAssembly, we've got these new technologies that enable a different class of web app experience. And so Flutter is unapologetically aiming at that next-generation class."
So, you're saying we will abandon DOM and HTML & use Canvas to push pixels in people's faces? That... does not sound very web like to me. The "different class" that Flutter is "unapologetic" about sounds like VNC or Flash; a completely controlled, locked down, isolated little fief nestled inside the web page. Again, like Flash.
> "We're aiming at this next class of apps that look very much like the kinds of apps that Flutter is designed to solve – high graphical fidelity, offering pixel level of control over apps, having a canvas where you can draw and manage every part of the environment yourself."
Not on Flutters priority list/not supported after the Flutter revolution: user-agency, web extensions, view-source, malleability, standards, interoperability, support from existing accessibility tools.
I actually think Flutter is an interesting set of tech & am glad to see another entrant to building apps. But every-time they open their mouth, it's to badmouth & insult the web, to highlight how their game plan to win is by becoming evil & ruining interoperability & standards as hard & fast as they can.
The priority system here seems deranged & anti-human to me; 'we take the only successful standards based hyper-medium on the planet, and we reduce it to a Canvas renderer that shoves pixels in your face, with 100% control from Google over what those pixels are and how they work.' We forfeit all user control, we give up all ability to read & parse & modify each other's web content. And for what? "Pixel perfect level of control?" "High graphical fidelity"? "Draw and manage every part of the environment yourself?" Bro, your app is not that important. There's other kinds of delight; I think users are waking up to how shallow & controlled & manipulative apps are, and doubling down on "we just need slicker design systems to really really delight our users" (and capture them for good!) is a limited game.
This is a nightmare, one where only a very very few players have control over the technological environment, one where humanity has no say, no stake, no control. What Flutter proposes is the most polarizing end of what Ursala Franklin talks about in technological society, where who can build the environment, who has say, how things form is extremely narrowly controlled. It talks to utterly prescriptivist ends where humankind merely receives technology as it is built from the corporation, and that end is forever & always enough (& all that is possible). The web, to me, has been defined & shaped by being more, by being better, by having a deeper level of engagement, owing to a malleable & open platform that users participate in, every time we install an extension, every time we run a user style sheet; a holism.
When we invited the "intertwingularity" back in the Cluetrain Manifesto days, there was a value system trying to come out, that humanity is empowered when systems are open & out there & when we can explore what is possible. I welcome technological innovation, but the wanton disregard & active badmouthing the Flutter spokespeople have for malleable systems, for standards & interoperation, their willingness to inflate their own importance by insulting & denigrating web extensions, user agency: it's an incredibly poor look for their would be new Flash project, for their attempt to make an impervious, inaccessible, unmodifiable prison of control within the web & atop native. I'd like to see a tone shift, where they talk about how they'll better work with the web, rather than usurp it's bones to build a new monstrous titan of app-dev.
Thankfully this 3.7 release actually has some perhaps possible good news, that maybe/perhaps Flutter can be intermixed somewhat with HTML/DOM on the page. The Register suggests perhaps Flutter's HTML/DOM mode and it's CanvasKit pixel-blaster mode can perhaps interoperate some. It's hard to tell right now how well Flutter might possibly be able to play within the web. But it's hard to recognize even the possibility- to see that the Flutter team really has any empathy what-so-ever for the web & web standards- when their rhetoric so proudly champions things that seem actively bad for the user, when so much of the work still looks like source-free, unmodifiable islands of Flash on the page; it wasn't good then, & it's still harmful now, & it's hard to appreciate the potential gain when it so lopsidedly enhances corporate control. But at least there is some evidence that Flutter is trying to do a little more interweaving than before... although again, it's hard to recognize that when the current rhetoric from the team is so mono-focused on their graphical capabilities above all.
[1] https://www.theregister.com/2023/01/25/flutter_3_7/ https://news.ycombinator.com/item?id=34519279
[2] https://en.wikipedia.org/wiki/Ursula_Franklin#Technological_...
[+] [-] timsneath|3 years ago|reply
In our talk, we explicitly say that today's web is the most amazing and pervasive platform ever built. And frameworks like Angular, React and vue.js serve the DOM-based model very well. Probably this will remain the vast majority of the web for the foreseeable future. But there are classes of apps like Rive (https://rive.app), Figma, or Google Sheets for that matter, that are hard to build on the web without using a technology like Canvas. I don't think that's "pushing pixels in people's faces" - it's simply using the right web standards for the job.
Canvas itself is a relatively low-level standard: it's good for drawing pixels. And so it might be useful to have a framework that enables animations and perhaps even some UI primitives here. Flutter's web work is an attempt at solving that problem, because we've already built a portable architecture for these capabilities. If you were building the next Figma or Rive, perhaps you'd see something useful in our open source toolkit. That's it. Nothing so nefarious as to be "deranged and anti-human".
I also can't let the accessibility comment go: that's a top priority for us, and we're very interested in reproducible issues there. It's been one of our biggest areas of investment to date.
Our early prototype demo (https://flutter-forward-demos.web.app) shows some examples of how we hope this will be integrated into a regular web page. (Disclaimer: this is built with our unstable branch, so may have some bugs.)
Disclosure: I work on Google's Flutter team.
[+] [-] mike_hearn|3 years ago|reply
Well, it's worth bearing in mind that what you call a standards based hypermedium is now completely unimplementable by anyone except Google, Apple and companies funded by Google. Insisting that everyone writes web apps doesn't mean software exists in some sort of communitarian utopia, it just means that it's the Chrome team that gets to decide how everything works. Like extensions for example, hence Manifest V3.
There's no really deep reason Flutter or other toolkits can't support more interesting and powerful hackability than what web extensions allow. Look at the JVM - it's not the web, but with tools like JVM agents, JMX, classloaders and so on you can extensively modify apps that run on it even without source code access. That's how the Minecraft mod scene developed and it's why you can so easily write plugins for IntelliJ. After all, web pages aren't actually designed to be modified by extensions. It's usually a giant hack. They come with megabytes of minified JS and attempts to modify them frequently break or require constant maintenance. That's why there are relatively few extensions that see actual usage outside of ad blockers, the cost to keep them going is just too high. And that in turn is partly because web apps usually don't have any kind of plugin architecture comparable to what desktop apps have often provided. At best they might have some sort of Google Docs like store, where the web app developer gets to pick and choose what integrations are allowed, but nothing as open as something like Photoshop plugins or Office OLE objects, where the end user got to install things the original developers had never even imagined.
So I reckon you're being kind of harsh here. HTML is hardly a technological utopia. Why shouldn't people try to do better? There's no reason progress and extension APIs have to be in tension.
[+] [-] tylerag|3 years ago|reply
https://news.ycombinator.com/item?id=34515277
[+] [-] brnt|3 years ago|reply
[+] [-] matchbok|3 years ago|reply
[+] [-] Aulig|3 years ago|reply
[+] [-] thewizardofaus|3 years ago|reply
My main competitor is iOS only. As I'm the only developer Flutter allowed me to create both iOS and Android apps simultaneously (with some tweaking).
My customer base is approximately 80% iOS / 20% Android.
[+] [-] spenster|3 years ago|reply
It makes perfect sense to the market. Flutter in fact fills a niche that does pay off in many use cases. Is it the perfect fit for everything? No, but for many small dev shops "going iOS only" is not feasible at all, since they need market penetration across platforms; and going native for two platforms is not practical since they don't have the dev resources.
[+] [-] realusername|3 years ago|reply
I'm in a market where 95%+ of users are on Android and the lower quality of the dev ecosystem on Apple platforms isn't exactly helping.
[+] [-] prennert|3 years ago|reply
I do get the fear of the Google dependency, though. I did feel lucky that support did not end before we were done with it.
[+] [-] gman83|3 years ago|reply
[+] [-] thefounder|3 years ago|reply
[+] [-] BaculumMeumEst|3 years ago|reply