Last time I tested a Flutter-built app on an iPhone X (perhaps a year ago) there was still obvious jank in transitions/animations.
I assume most of the showcases mentioned here (WeChat, Grab, Yandex Go, Nubank, Sonos, Fastic, Betterment and realtor.com) are Flutter-based on Android only?
Is there a well-built Flutter-based iOS app without jank now?
I replied above as well. My team has also not been satisfied with the performance of the GPay app on all devices. We've been working with the GPay team since release and made many improvements in both Flutter and the GPay app. I expect there will be an updated GPay app soon, with still more performance improvements in the pipeline.
Maybe publish a Flutter showcase app on both appstores? With Apple's store you'll probably have to jump through some hoops to provide some useful functionality, but it should be doable.
The app works fine although as of today it's still tagged Beta in the Google Play store, which may give some people pause.
NFC on the other hand is so unreliable as to moot the use of Google Pay, which is unfortunate. I really prefer tap-to-pay over anything else, but not at the expense of making people in line behind me wait as I try various workarounds like toggling NFC. I realize there's nothing you can do about it - my grumbling is more a warning to folks who (like me) may have used it previously on the Pixel 2 and loved it. It's problematic in the Pixel 4. :shrug:
0 - Remove any skins / bumpers / cases from the device.
1 - Lock and unlock the device.
2 - Toggle NFC mode.
3 - Reboot the phone.
I've seen some speculation that on the Pixel 4 it could also be due to some flexing in the case. During a two week period where I couldn't find my wallet I spent a lot of time trying to make it work because of Chase's allowing tap-to-authenticate on their ATMs. Out of 100+ tries using those work arounds and several different ATMs (in case that was the issue) it worked once.
I ordered a tile for my wallet since I can no longer rely on my Pixel 4 as a replacement credit card.
According to AppAnnie, most of these are using Flutter on iOS too: WeChat, Alibaba, Grab, Nubank, Sonos all show up on their list of Flutter-powered apps on the Apple appstore. We don't capture analytics on apps, so our sources here are external sites like AppAnnie (or occasionally, direct connections with the development team).
I tried the Sonos app since it looked very similar on both platforms. It's a lot smoother than my experience from a year ago. (Hard to really tell in the limited set of screens before hardware pairing.)
Edit: If the signup screen in the Grab iOS app is written in Flutter I'm very impressed. I want to believe.
Edit 2: Nubank: I only evaluated the sign-in screen(s), but it has enough animations at what seems like a very solid 60 fps on my iPhone X to convince me that Flutter on iOS is actually a real thing now. Very nice.
Edit 3: Maybe I jumped the gun here. Quote from that post: "We’re also facing hard prioritization decisions, especially in flows and screens that work very well in their current state (native Objective-C, Swift, Java, Kotlin, or React Native) for which there are no near-future update plans."
Interesting you mention it. I've actually been working on a fairly fully featured app in flutter, and was shocked at how well it performed on iOS. Coming from the React Native world its miles ahead in terms of perf, at least in our case.
Shameless plug, the app is https://droppod.gg, an app to find time to play video games with your friends!
I tried it - there's some jank here and there, but the general experience is smooth. Image loading while scrolling through your game feed seems to cause skipped frames, but that's not necessarily the toolkit's fault.
I like the idea so I just installed it. In the sign up screen I can swipe back and get to a second sign up screen, then swipe back again and I go to a loading screen forever.
I don't know if that's flutter or you, but it doesn't fill me with confidence.
Does this mean all desktop integrations have now migrated from alpha and are available on stable releases?
The post isn't 100% clear on this.
I tried out Flutter a while ago, and it's really promising as the only really viable alternative to the JS/browser stack for cross platform GUIs.
Dart is not terribly inspiring and lacks the appeal of other new languages like Kotlin or Swift, but it's fine; as in: boring/easy to pick up and good enough for frontend, although somewhat sluggish.
ps: I personally don't see the design of Flutter Web as viable for production apps, so if you need Browser support, a JS stack will remain the only solution, at least for a few years.
Doubt it. More likely this is Google half-assing something else. I doubt Flutter 2 is worth it, since they were just beginning expanding the Flutter team 2 weeks back
I'm a developer who uses Flutter and the thing I love the most about Flutter is the Dart language.
It's such an easy language to pick up, and if you know TypeScript/Java/JavaScript, it feels immediately "home", you just know how to do things.
Regarding Swift and Kotlin, yes, they have more features, but that makes those languages also harder to learn and more difficult to master. I think Go demonstrated that more simplicity is also important and more features does not automatically mean you'll be more productive (that's not to say that Swift or Kotlin is bad, I just want to express that Dart feels great).
Extensions, null-safety are already here, and data classes are being worked on, so I think the Dart teams listens to the feedback from the community and prioritizes well.
Seems like you've been around long enough to have read In Search of Stupidity. Lots of great stories in there, including one about a super famous tech person who once said the browser is too slow and will not ever be a viable place for apps. :)
A bit later that famous dude literally wrote: "whoever can make HTML sing will win the API wars". About 5 years before people understood what he meant.
Flutter for Web feels like such a wild step backwards in terms of functionality that I'm not sure the benefits it brings are worth it. I just tried a few samples, and basic interactions like selecting text, saving images, and opening links in new tabs don't work. This is the result of rendering everything to a <canvas> element. I'm much more interested in a React Native style approach, which seems to provide a consistent set of components that work the same on mobile, desktop, and web.
There's no difference between CanvasKit and HTML as far as interactions are concerned. The differences are in pixels and performance. If there are issues with interactions, we'd like to hear about them. Please file issues on Github.
Yeah, I haven’t been following Flutter, but I’m surprised their approach to the web is just shipping their entire custom layout/drawing code in WebAssembly and drawing everything with canvas. I would have expected them to actually port their native UI components (buttons, links, text, etc.) to their corresponding native components on the web, and maybe ship a custom layout engine if CSS layouts aren’t flexible enough.
We actually have two distinct approaches: the CanvasKit/WebAssembly approach you mention for high-intensity graphics, and an HTML-based renderer for other apps. This article has more details: https://medium.com/flutter/flutter-web-support-hits-the-stab...
You're right -- we do render the controls, so that existing Flutter code (that might itself include custom styling or matrix transforms) just runs without change or surprise, but we integrate with the underlying browser support for things like text autofill and accessibility.
We actually did try that as our first approach, but it really didn't give you the flexibility that Flutter developers expect.
As the erstwhile editor of the HTML standard for ~10 years and the now TL of Flutter I must admit that it's weird to be creating a web framework that completely ignores all the HTML stuff I worked on before. :-)
That said, Flutter is different from Flash in some important ways. Flash used the NPAPI to "break out" of the web and was basically "native" code you could escape to, whereas Flutter really is using web APIs, like Wasm, ARIA, WebGL, JS, WebComponents, and so on, to create true web apps that just happen to not use much of the control set that HTML exposes.
I suspect that even outside of Flutter, the web in general is going to move towards this kind of framework in the coming years. It just gives you so much more control. It's basically how every other platform works -- pick your language, compile to machine code, don't need to be limited to what HTML and CSS (etc) enable.
Really not fair to compare against flash in this way when wasm wasn’t available and npapi was the only option. That is additionally an implementation detail, Adobe could (theoretically) revive and port flash to wasm today without breaking the majority of applications.
Not really. They were not portable. NPAPI was not a web standard in any meaningful sense (hint: the first N stood for Netscape).
> That's why there has never been a UI toolkit as successful as the web.
The web's success in terms of active users and in terms of deployed content is astounding, certainly. I think I'm relatively well placed to understand why, and I don't think it's because the web restricted developers to one scripting language or one set of controls. I think it is very much _despite_ that.
It's painting stuff in a canvas and not using the standard web controls.
It's the web in the sense that almost every UI toolkit also offers a canvas (for example Tk does this) and you can reimplement every control using it. That doesn't make your new toolkit in a toolkit Tk.
But why would an app that writes to a WebGL canvas be any harder to maintain than an app that uses HTML controls? If anything, it'd be likely to be easier to maintain -- we (the web standards community) are much more likely to change how a particular element is supposed to work than to change WebGL in an incompatible way.
But the framework? That will have to be updated when each OS the framework runs on changes.
The HTML controls are used by a ton of stuff, so they're quite likely to be updated. Your framework? I have to really, really trust you that you'll update them.
Look at how Motif or GTK or AWT or Swing or Tk widgets look on modern OSes. There's an entire graveyard of cross platform UI libraries out there.
So this is already a pretty toasty section of comments so let me put this to you. If you've already answered this elsewhere, please let me know.
I would be surprised if someone heavily involved in the Web's development process for a long time didn't have some really sore spots about it.
That aside:
--
What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
Fairly loaded questions I guess, but realistic ones too, not just philosophical.
> What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages.
I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we sailed past the point where view source stopped being useful years ago. Everything now is minified, and sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
> How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
> Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
I have not. A lot of people do like extensions though.
Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
> Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using HTML/CSS/JS, even if not perfect.
Perhaps if Flutter became mainstream enough that there's theoretically nothing stopping this from eventually happening for it as well. That's an interesting thought.
--
I suppose that leaves my last question, and it leans away from what might be a practical view from your position: Do you think flutter pushing for major market share while also trying to replace the core part of the web (HTML/CSS/JS -> Canvas renderer/wasm) is a good thing for the web's health and future?
(That's a good bit more philosophical, but I hope in #CURRENTYEAR we're starting to see value asking long-term questions like that, especially from inside of the giant companies. I'll stick to one of those kinds of questions)
--
> I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
That is interesting, thanks for sharing that.
> I have not. A lot of people do like extensions though.
Also interesting, fair enough.
> Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
Perhaps a good new question is what kind of tooling is available or planned for users to interact with Flutter applications? Such as what Devtools provide, or an expansion to them directly.
As a developer, the Devtools are absolutely critical to my workflow and ability to learn from and often fix issues I have with other sites.
(It could be pointed out that native applications don't tend to have that functionality, so it shouldn't be expected.. but in this context we're talking about effectively removing it from the Web, which does)
I mean, I try to use Devtools on other sites, but I haven't really had any real success with that for years. I don't know how many of the rest of the web's ~4 billion users try to use DevTools but I can't imagine it's anything close to a majority. Or even a large minority.
FWIW Flutter isn't trying to replace the web. We're trying to offer a way of writing web apps that aren't really possible today. For example, something like the Flutter Folio demo, which works on multiple platforms including web, was written in a few weeks. I cannot fathom how I would do that without Flutter.
> Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I got into web design/programming in the 90s, and the answer is basically no. Sure you could poke around a bit, but I never found it to be a revelation. I still had to buy books, read blogs, and do a ton of trial and error. Also, it was a never-ending game of trying to testing to see what each new browser release added or broke.
The example spinner ( hhttps://flutter.dev/#dartpad-landing-page ) also looks pretty choppy on my Macbook Pro 16. I haven't tried on lower-specced devices, but it doesn't inspire a lot of confidence.
Yeah, that's running in development mode, since it's a scratchpad for live coding. Try something like https://flutterplasma.dev for an example of Flutter's web support when compiled in release mode.
Thanks for the link. To confirm the point of copying text being broken: try doing that at https://flutterplasma.dev/ -- it kind of works, but not really, no.
Ah fuck me. This is awful. You have to be precisely on the text to select it. I frequently offset my mouse a little to the left of the element to ensure I select the whole text. Even a little bit off to the left and nothing.
I love the idea, but this sounds like it's going to be unpleasant for me. Hopefully they figure out these UX things.
Yeah, tiny differences that would nag the hell out of me. For example double clicking for selecting word is implemented, but triple clicking to select whole line is not implemented ;(
I don't think that shows off Flutter's web support. There are no interactive widgets or user interfaces (Flutter's primary purpose?), and the animations are less impressive than demos in DOS from ~30 years ago, e.g. https://en.wikipedia.org/wiki/Second_Reality
As timsneath mentioned above, Dartpad is the dev environment. That means we ship the full Dart and Flutter SDK ahead of time as you can type/change anything in the code box. We also ship debug metadata to give better errors.
In production mode, we do a much more expensive compile to remove the parts of Dart, Flutter, and packages you don't use and to optimize/minify the rest.
It is working in Safari for me, but we've definitely appreciate bug reports if it's breaking for you (https://github.com/dart-lang/dart-pad in this case).
I guess it's just the two ways of approaching a problem. Make native look like web or make web look like native. Both are kinda bad.
The labyrinthine rats nest of absolute hot garbage to beat a document rendering engine into a windowing toolkit with widgets is horrible. It's a testament to front-end devs that with enough effort you really can squeeze water from a stone.
And then imagine being so comfortable navigating that maze that you want your windowing toolkits to behave more like document rendering engines pretending to be windowing toolkits.
And you're like "why not just have a windowing toolkit for the web and sites can choose their rendering engine basically so all the SPAs get all the nice features of stack-based GUIs and document people get documents. Surely that would be less work!" And I think you're right but I doubt anyone would agree on a single toolkit so now you can just bundle your own compiled to wasm and rendered to canvas. Woooo.
Annoyingly yes. If flutter web behaved like a true web(whether that be through building html elements or through canvas), it would have been a breath of fresh air and for once not a cluttered codebase of 8000 npm modules, html templates and a ditch full of css and no idea of figuring out which is which and which comes from where. I can kind of see a market for it in a sense that I don't want to install a separate app to track my shipment from a specific courier and have a web which is easily accessible on my phone but those are very narrow niches and honestly I can't think of a business that would invest into something like that for nothing more than accessibility. Aside from that I strongly stand by the statement that flutter is the best option for cross-platform mobile apps by a very long shot.
Things changed a lot, I observed the same symptoms as late as late 2020, I can't reproduce these issues now
In general Flutter for Web is _amazing_ if you want to deploy an app.
after seeing this thread, pretty clear to me its almost a perfect nerdsnipe - makes perfect sense if you're already building a Flutter codebase, sounds bonkers if you build web apps.
Check out Flutter Folio [1], built in partnership with Google. Right-click is actually disabled, so you can't even open the "Create account" link in a new tab, nor can I right click an input to autofill with my password manager. You can't inspect any image rendered to the canvas element. Furthermore, you also can't blur the form input (although that's probably application specific rather than Flutter's fault).
The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.
We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.
> Perhaps it's fixable via education and platform-specific guidelines.
I think this is right, but I also think it should be clear to everyone (i.e. in the first tutorial) that not using a Link widget will make this work wrong for all sorts of accessibility and UX reasons. And the Link widget should work across platforms and implement the equivalent of page history correctly.
Maybe it's worth writing down somewhere what the equivalent of each tag from HTML is; what is the canonical way to create an h2, input, textarea, button, a, img, etc.
> You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer
This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms.
Instead of a cross-platform development environment doing that for you.
I have to be honest, not trolling at all, genuinely curious to me: I have the same opinion for the completely opposite reason! _without_ "Skia everywhere", Flutter for Web was annoying, because then there was this autogenerated CSS/JS and it might be _close_ to other Flutter platforms, but it often couldn't be 100% of what it was
I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_
Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.
Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides
dstaley just said that those issues happen now. " I just tried a few samples, and ..."
I just tried the demos over at https://flutter.github.io/samples/#?platform=web and I concur, Flutter is utterly horrible for everything the web stands for. So not amazing and seems to actively make everything worse.
We certainly don't think Flutter should replace HTML or other frameworks. We hope Flutter will work well for many use-cases, but the web is huge. There's room for multiple approaches. If it's not working for your use-case it's totally fine with us if you use something else. We welcome constructive feedback on what's not working so we know where to focus our efforts.
Thanks! A great first step would be to have a "web-native" renderer for your web version. Meaning that it'll use DOM elements that the browser to handle the rendering of. Would fix many of the current issues with your implementation.
I have a large Flutter codebase and flutter web is still alpha quality in my opinion, there's way too much jank to make it work properly on a web platform.
Which mostly died from JVM startup time (Think 30 + seconds). There was other issues as well (security and UI issues mostly) but if you knew what you were doing, Java applets were not bad for the time IF the JVM as already loaded.
> This is the result of rendering everything to a <canvas> element.
If the accessibility story isn't rock-solid, frankly this is a non-starter for a lot of applications. Web apps suck in a lot of ways but regular HTML has pretty great accessibility properties.
Accessibility is actually a really big deal here on Flutter (Ian Hickson and I both worked on Accessibility in browsers for years). AX is something I feel we've done pretty well with on iOS and Android. Web is still pretty early days, but many AX features should work already. We have more AX work to do on web yet. We've not yet taken any Flutter Web apps through Google's accessibility testing processes similar to how we've done on the mobile side, but I expect we will soon.
Yep, I’ve been really impressed with react native on the web so far. Our current code base deploys across Android, iOS, web and windows with minimal effort.
I recently discovered Flutter and I love it for making mobile apps. The multiplatform by default with good API and stability is a winning combination. Lots of modern language features from Dart and built in support for two way binding makes GUI programming much easier. I much prefer it to React Native.
What is the API story like now? When I first looked before version 1 was stamped you had to search for 3rd party plugins for features like accessing the camera and such.
Congrats to the Flutter and Dart teams! This is a huge accomplishment.
However, I worry about accessibility story for Flutter applications. Am I naïve? Should screen-reader support be a concern for the kind of complex visual applications that Flutter is built for?
Screen reader should always be a concern! But we built accessibility as a core feature of Flutter from the start. You can read about our support for screen readers here: https://flutter.dev/docs/development/accessibility-and-local... including a session where a developer who is blind shows how to make an app accessible.
Flutter 2 also supports accessibility for web apps, and you can use Windows Narrator, VoiceOver, TalkBack, or ChromeVox screen readers to navigate a Flutter web app.
Eh, it's a little murky. I was playing with dart a little. It can in fact create a single binary, but it looks like it's just putting the interpreter with the code.
I say that because if you strip or pack the binary, instead of working it shows the output of running dart with no arguments.
It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.
`dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code.
The approach is not pretty but was chosen as an implementation shortcut.
That's why `strip` does not actually do good things to the binary.
There is no reason to run `strip` on such binaries - because they don't contain anything strippable.
We are planning to fix it some time in the future, we really only expected moderate usage of `dart2native` and only on Linux. Turns out that there is demand for using it all over the place, which includes Mac and Windows and requires things like signing support... And to make executable signable we need to make them real Mach-O / PE executables and not weird concatenations of bytes.
IIRC Flutter compiles your Dart source code to a native platform binary and uses Skia to render the UI. I assume the Flutter Desktop API provides abstractions for creating windows.
I long for the day when software development steps out of its infancy and we have one programming language that targets all platforms and frameworks.
Kotlin is pretty great - so you're in this situation where you can either learn Flutter or JavaScript - at least with JavaScript you can also target the web (I'm aware that Flutter 2 also can target the web, but it's not the same thing).
edit: I must clarify - I'm not saying software development must necessarily have only one language, but rather that there exists a single language that can target all environments natively. C was close, but then the web and mobile happened. Java was also close, but no dice. We're getting there, I think.
I don't understand - Math is a great example because the notation is bounded across all disciplines of math. Can you imagine if Physics used different "math" and "notation" compared to Chemistry or Computer Science? You don't have to learn a different math to understand different disciplines in the same way you have to learn different programming languages to understand different programs.
Notation is highly variable in math. Take a look at penrose notation [1] as example of just how different they can be. Most mathematics books will have a definition section in the front stating their notation choices because things are so fragmented. Good luck trying to read something like Russell's PM without a notation guide open alongside it.
Even Microsoft realize that Xamarin is not a tool for serious mobile or desktop development. Sure, you can get apps that work but they are 2.5x larger than if you had written them in Java or Kotlin and offer no more features than if you had done a hybrid mobile app with Ionic instead. Everyone thought Microsoft acquired Xamarin for the mobile dev tooling? No: it was the only way they could get the brain trust and the core Mono team at Xamarin to come work for them.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
I don't know how they can claim this. The new Google Pay on Android was noticeably laggier the moment it was released. It continues to be so, and I still hate using it. Now I know the cause.
As long as the old Google Pay app still does NFC payments, I'll keep using it.
I was also pretty salty that the new Google Pay app was marked as "early release" so you couldn't leave a review on the Google Play Store. That's fixed now though.
I don't auto-update any Google app anymore. The amount of bloat keeps piling up with each new update. Google's Product Managers, as great as they are, need to seriously slowdown a bit.
The initial GPay Flutter release definitely had some performance rough spots. We've learned a lot from working with that team since release and have made resulting changes in both Flutter and the app code.
GPay hasn't released since December last I checked, but I expect the next release should perform better on both iOS and Android and we will be continuing to work with them closely over the coming months.
What are you talking about Flutter runs butter smooth on most smartphones at 60fps, far better than what react-native and other half assed solutions on the market.
go ahead and take time to downvote my comments. do you boo
I just wanted to commend you guys on Flutter. I've put off Android/React Native for almost a decade because of how clunky it was and I feel like Flutter finally gets the pieces right.
It is refreshing to be able to start development quickly without worrying about tooling (react-native), CI, etc.
Also I feel like Dart is perfect. It's a joy to use, I feel like this is the future. It's not es6 and it's not Java either.
I had wondered what had happened to this app to make it so slow. It takes around 10 seconds to get past the loading screen and show me anything useful on an S9.
Those seconds are excruciating when I'm at a checkout trying to actually use the app, with a large line behind me and a checkout person staring at me.
Stadia has not been cancelled, they just shuttered the internal development studios. The service itself is still alive and getting new games frequently.
If you'd have any clue of the games industry, you wouldn't be saying this.
AAA publishers are pushing heavily for this since it makes piracy and hacking obsolete and they always get what they want - there's no way that this is not the future of "popular" gaming.
The idea sounds very appealing, especially to an indie developer: being able to ship your app on multiple platforms from a single codebase is kind of the holy grail. Unfortunately, the result is....
I tested this Flutter example[1], on a 16" MBP with and i7, and it is janky as it can get, it feels like I'm using a 15 year old computer. From the code it looks like the whole thing is... rendered on canvas? I'll pass.
Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested.
https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.
Yes, we consider accessibility a must-have feature. On the web, we have a second DOM tree called the SemanticsNode tree, which is generated in parallel to the RenderObject DOM tree. The SemanticsNode tree translates the flags, actions, labels, and other semantic properties into ARIA attributes. We've been testing Windows Narrator, VoiceOver, TalkBack, and ChromeVox screen readers to navigate a Flutter web app.
So why is FlutterPlasma.dev completely unusable with a screen reader even after pressing the "turn on accessibility" button? I understand that the actual demo presentation might not be accessible, but the intro screen should be fully readable, and it's not.
Edit: You may want to add the NVDA open-source screen reader for Windows to your list. And when you test with a screen reader, make sure you use it the way an actual user would when browsing the web, e.g. using NVDA's browse mode with the arrow keys to move through the page.
Why are you guys here on HN still using Chrome? There is literally not a single reason I can think of to be supporting this behemoth that is killing the open web. Firefox is excellent actually and Firebug IMO is far superior to Chrome's offering. I understand non-techies using it like they used Explorer, but come on guys.
On my iPhone 12 mini the demo took 13 seconds to show me something besides a blank screen. On my desktop it was around 3 seconds and cpu usage went through the roof.
No, I won't help you. The OP post is about how great flutter is and you're in the comments telling everyone it will actually be useable soon and asking us to test it for you on common browsers.
Sorry but the plasmadev demo doesn't pass muster compared to 60fps animations we were able to do years ago with html+js. Something about the renderer approach is causing hiccups in the animation.
"Buttery smooth animations and scrolling" will be a great selling point for flutter ..if it actually works.
The plasma demo you linked runs at a stuttery 40fps on Firefox (ubuntu 20.10) on a quad core Ryzen 5 laptop. The fans immediately spin to max speed. I'm not impressed...
Here's a hard question, why is this surprising to you? What are you missing in development--is this a gap in testing? Are you hamstrung without support internally to bake this as long as it needs? Rather than double-down on extolling the virtues here, it's time to double-down on fixing the team and the product.
FWIW the plasma demo runs at something like 50fps in Chrome on my 3yr old Samsung Galaxy S9, and only a bit worse in Firefox (perhaps 40fps) - so they are not buttery smooth experiences, but neither are they terrible.
Oooff, the edges in that demo look terrible - particularly the grey boxes in perspective. The demo boasts that it isn't a video, but the interpolation looks as bad as one.
I hate to be critical - I'm sure a lot of work has gone into this - but there's still lots of room for improvement too.
As usual for Google products, this works fine in Chrome on a decently powerful desktop.
Not up to the speed of well-written Javascript, but definitely viable.
In contrast, this is completely unusable on other browsers or on lower powered devices.
On Firefox desktop, initial loading brings a "This page seems to be stuck" prompt. Once it finally loads, clicking the play button just does nothing.
Please note that for 80+% of websites/apps, Firefox is faster or on par with Chrome for me. Google products and some other exceptions are the only ones that are consistently slow on Firefox. Whether that's intentional or just a lack of testing, I can't say.
Similarly unusable on Safari.
On lower powered devices this just freezes Chrome for me.
As I mentioned in other comments, I like Flutter, but Flutter Web is not anywhere close to being viable for production use.
flutterplasma.dev just shows a blank screen for me on iOS safari. Every few refreshes I can can get the content to show for a split second before it goes back to white...
Another data point is the new flutter Google Pay app vs the old version. On my iPhone 11 Pro, the former is incredibly laggy. The latter is as smooth as you’d expect given the hardware.
Is that a counterpoint? To me that tells me performance is going to vary between users computers, possibly due to something other than resources. That means the experience I'd be delivering won't be consistent and I probably won't be able to fix it, or even replicate it, reliably. Something that's janky everywhere can be profiled, debugged and possibly fixed. Something that has an unknown problem that only affects some users is far more problematic.
That isn't a counterpoint to say the language might be worth considering. That's an additional data point to give me reasons to not use it yet.
Just tested https://gallery.flutter.dev/#/crane in Chrome and Safari on Mac and if I go to another tab and then back to the fly tab it just shows a gray screen. Does not inspire confidence.
It is very janky, and worse, totally unaccessible, rendering it useless (or frustrating at best) for huge numbers of the population. And why? It's just yet another shiny web framework. We've known how to build websites for decades now.
Agreed... How can they be proud to release such an extreme regression in usability and accessibility? It is entirely 100% inaccessible for anyone not using a visual user agent. And this somehow isn't considered a non-starter?
If it's running on canvas, normally you would see "unpkg.com/canvaskit-wasm" - and even then it may not be the latest (supposedly more optimized) version. For example, my simple Super Tic Tac Toe app - uses it - https://malkia.github.io/tictactoe/#/ - but the gallery was compiled to use HTML, instead of canvas - which would be slower (IMHO). I think there is even mixed mode - where it can choose one or another ("fat" binary on the web ;)).
I just tried it on an iPad Pro with Safari. Clicking the tiles does not work, scrolling does not work with the touchpad, and overall it feels very janky. They probably didn‘t care to optimize / make it usable with Safari.
Trying it on Windows 10 with Firefox. Scrolling is incredibly slow, in every possible way. The scroll wheel barely moves the content, so I have to spin the wheel ten or more times to get any reasonable distance down the page, and the animation is janky and stuttery.
I remember getting accurate values from the scroll wheel being the worst in Firefox and basically impossible. You could only get the scroll direction, but not the correct extent (bascially everything just looked like one detent). So you either get incredibly fast scrolling, or incrediby slow scrolling, depending on how you work with the value and whether you still do the oft-needed division by 120. This can also make some touch pads that generate mouse wheel events very unusable for zooming or scrolling.
The scaling there works with very different speeds in Firefox and Chrome because both disagree on what value the delta should have. Scrolling up once yields -100 in Edgeium for me and -3 in Firefox.
Wow, this is some of the worst scrolling I’ve experienced on the web in a long time. Incredibly weird and not smooth at all on both a newer iPhone and Mac. Can’t copy text either.
Interestingly I've tried it on Brave on a M1, and it is very smooth. I also tried their Plasma demo and it was very smooth (https://flutterplasma.dev/) but that might say more about the M1 than Flutter.
> and it is janky as it can get, it feels like I'm using a 15 year old computer.
Ironically computers 15-20 years ago with native software ran much, much much faster and snappier. KDE3, XFCE, even Windows 98SE and XP were much faster. They were crippled by disk I/O, true, but once the software loaded, the feedback was inmediate.
Just as a bit of counterpoint, I'm still running the same hardware right now as I was 12 to 15 years ago with KDE3, nowadays KDE5 is so much faster than KDE3 ever was. Yes I need to upgrade badly, yes I was planning to just a few months ago, but prices seem a bit crazy now, so I'm still continuing with my ancient but somehow still operational hardware.
I'm seriously considering looking at something like https://heaps.io/ for cross platform utilities rather than flutter etc. i suppose accessability is likely to still be an issue, as well as ciustom (not native) widgets -but at least the resource usage and interaction is likely to work?
note that heap+haxe is pretty much "the same" as flutter/dart - a language, a compiler and a runtime + a rendering engine..
This is definitely interesting; I'm so tempted to try this.
But the question that comes to mind with this kind of the technology from Google: is there any mandatory Google services that I'd have to use? Just as an example: Do I have to use Google's ad platform or I can use any other service?
I don’t think Flutter offers enough value over Electron to justify learning Dart and leaving behind the vibrant tooling and package ecosystem that JavaScript has.
The real news is buried a little towards the bottom:
> Today we’re announcing the beta release of Google Mobile Ads for Flutter, a new SDK that works with AdMob and AdManager to offer a variety of ad formats, including banner, interstitial, native, and rewarded video ads. We’ve been piloting this SDK with several key customers, such as Sua Música, the largest music platform for independent artists in Latin America, and we’re now ready to open the Google Mobile Ads for Flutter SDK for broader adoption.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality. By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.
from pay.google.com
> Starting April 5, you won't be able to use pay.google.com to send and receive money from other people. To send and receive money, use the new Google Pay app.
The new Google Pay app on iOS is incredibly sluggish -- animations stutter, switching pages has hesitations. I'm not sure what they mean by "quality" in this case.
We were also not satisfied with the performance of the initial GPay release. We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app. Hopefully the next release of GPay will be out soon and others will be able to see the progress we're continuing to make with the team.
Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress.
And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply no alternate universe where a third-party team gets the level of access the way you described the Google Pay team did.
Of course, it helps that the stakeholders are in the same company, but my point is, shouldn't there be a Flutter Foundation where every developer can feel at home on equal footing with other Googlers? Flutter is so promising, and yet, at the same time, I don't want to end up being slave to its complexities with no way out as a third-party small development shop.
Despite that, I'm 99% porting my cross-platform app to Flutter after strong reviews from other developers I know.
At least with iOS you know it will take three years for something to come out of beta but then it's pretty solid. It's just Xcode that never gets fixed.
I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)
We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.
We are using Flutter at our company and it's far from a black box if you get stuck.
For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.
For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.
Flutter used to be such a great experience, but something happened ~6 months ago that totally derailed it.
It brings my late 2016 MBP to a crawl if I am building on iOS simulator.
After reading online about it being related to Metal, and needing to switch flutter channels, trying that, and still seeing no success... I just gave up on Flutter (for now).
> We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app
So seriously, how can you reassure any indie dev not getting VIP support to optimize their app for laggyness, that they can easily produce a decently performant app?
Many of the lessons we learn with GPay directly fed into improvements in the framework, improvements in our tooling to make this kind of debugging much easier, and better documentation to try to scale the knowledge to the whole community. Some of these have already shipped (see e.g. new features in our DevTools) and much more will continue to deploy over the coming months.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
And then, the reality:
> We were also not satisfied with the performance of the initial GPay release.
Ah, the classic false advertisement.
Let me re-write the ad for you:
> Thanks to several-months-long involvement of Flutter's development we could finally fix some of the issues plaguing our app that we re-wrote in Flutter. We're still not close to the release, and we only hope it will be better.
Hi, I audited the performance of the GPay app. Almost all of the performance issues in GPay are related to its use of vector graphics libraries which make Skia spawn many new shaders that have to get compiled. The suggestion was given to move to raster graphics but since GPay ships in many locations that are sensitive to app size, like India, they made the tradeoff to keep raster graphics.
That said there are some longer term initiatives to address this problem on Flutter's side and Skia's side since the problem can show up outside of vector graphics, it's just more unlikely.
It was buggy as well. I was locked out of receiving and sending payments for about a month. After some updates, had to relink my bank account and the app created a new UPI ID by appending a -1 ie. myname-1@okhdfc! It's like creating a new email ID to resolve the issue.
It's not clear what you're arguing for or against. Google Pay is a product with multiple features and one of them is being phased out. What's that to do with the benefits they're claiming from the rewrite of the mobile app?
Yes, exactly, it doesn't follow. You've just re-written your app using a framework that allows you to run one codebase in multiple places, including the web, and instead of doing that, you decide that you no longer want to support the web at all.
The web version isn't shut down, but losing crucial functionality. If Flutter let's you run the same code across multiple platforms, then what reasoning is there for one platform getting less functionality after switching to a framework that, if anything, should increase cross platform feature match.
I want to love Flutter. But once looking at it, it's a no go. It's the new flash. Really, you cannot copy the text anymore. React native is my goto solution now.
Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions...
I can see it being useful for games and similar where there isn't really any UI but even then I would want dialogs and similar to use regular text that I can copy.
I am definitely not looking forward to flutter on the web. I foresee a lot of websites that I will need to avoid.
But do you really need that as a requirement across the boars for all apps? How many times have you wanted to save an image or copy text from a UI element in a native app? (eg. a save icon and “Save” on a button) How many times have you been frustrated in a web app that when you search using the browser you are getting results from UI elements or “app chrome” instead of the actual content that the web app is displaying? Isn’t it enough to have some fields with content a user actually would want to copy/search, which would be set based on the component type you are using and can be overridden per element if needed?
The only thing I do get is that you’d want open in new tab and copyable links. However, that’s hard from a developer perspective as you have to make sure you create links that store all data needed to rebuild the same UI in the same “conceptual” context but a different underlying data context (logged in user may be different, data may have changed so some saved context has become stale). You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar or a link by another user 2 days before, that may have been the result of that second user clicking through 10 levels deep in your app with all sorts of filters and options based on the state of data at that exact time two days before the first user clicks the link. Obviously you can’t show them the data from two days ago, but what if the data is still there but the path to get there is different? Does it conceptually still make sense to show the data and perhaps some breadcrumbs showing the new path? Or should you just say sorry that data isn’t here anymore? That depends entirely on what the data is and what you’re users are trying to do, so you can’t build one-size-fits-all technical solutions for this (if that were even possible). How are you ever going to reliably rebuild the UI and context that the first user intended to share by copying the link without spending huge amounts of time? That requires actual business logic and functional design.
For a lot of apps, it may make more sense to just have a share button in some places where you actually and intentionally support this (and where it will be actually used by a substantial number of users). Less time spent on developing things that are hugely complex and very little used (on average per state for ALL your different UI states that you have links to somewhere in the app, even if it’s a typical line-of-business master-detail form with some filters for the master list and a details segment with a dialog box or expanded element showing additional details of a certain property).
> But do you really need that as a requirement across the boars for all apps?
No, there are a few exceptions, but mostly yes. And I'm sure more than just the exceptions will use Flutter which is why I'm not looking forward to it.
> How many times have you wanted to save an image or copy text from a UI element in a native app?
Often. I mean not necessarily from a UI element but a lot of the time I want to get an image from a native app and can't.
> How many times have you been frustrated in a web app that when you search using the browser you are getting results from UI elements or “app chrome” instead of the actual content that the web app is displaying?
Almost never. There are rarely many extra results. In fact I already am bothered far more often when websites hijack Ctrl-F (I do not understand why browsers allow this) and fail to search the entire page. With flutter this will become the norm and I am not looking forward to it.
> Isn’t it enough to have some fields with content a user actually would want to copy/search
No, it isn't. I regularly copy things that people didn't expect. If it is just to send someone instructions how to use the app. In fact Android has automatic copy based on OCR from the app switcher and I use that a couple of times a day. There is already too much uncopyable text around. For example all messaging apps on android appear to only support copying the full message. This is what happens when you let people mess with standard UX patterns, they break them!
> You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar
Good! I love apps with great links. It makes them so much easier to use. I don't need to go through their custom navigation to get to my favourite pages. I can use the browser navigation that I already know and love. Also I can share links to my friends! Maybe I can help people use the app better!
You just described a bunch of problems that I already have! Especially on mobile devices. This is why I hope that Flutter on web doesn't take off. We will be making all of those annoyances more common! You seem to think that you can predict all of my use cases and provide the share button manually right when I need it. However product developers on a time crunch often miss or skip use cases so it is much better to have supported by default (like text find/copy that can be disabled) than hope that a developer will think, and find time, to implement them. And if URLs encourage people to make it possible to save and share the state of their app then I think that is a good thing!
You (and your team) would be surprised at how performant and well designed dart is https://dart.dev/samples.
Not to mention the ability to use flutter and target multiple platforms.
Flutter team member here. In Flutter, the developer consciously decides which text should be selectable (and thus copy/paste'able), so while it's true that text is not inherently selectable in a Flutter app, text that the app developer decided to make selectable will be.
This sounds awful. Like some sort of bullshit DRM in a way.
Now I'm thinking of all the ways I could get screwed here.
* Not being able to copy transactions from my bank account
* Not being able to easily send text to a read-later service (not sure if this necessarily depends on selectable text, but who knows, maybe selectable means the text isn't visible to these services now)
* Not being able to easily copy something that needs entering into another page
This reminds of sites that try really hard to NOT allow password managers, or even allowing pasting of text into form fields.
It takes work to make it non-selectable. In Flutter, it defaults to non-selectable.
Most of the time a dev isn't thinking "I'd better make this selectable," because they simply aren't going to think of all the reasons someone might select text. They'll think of the obvious-to-them cases, and leave all the other text as unselectable.
OK, but the Flutter gallery has zero selectable text, as far as I can see. Seems like a great case of where developer decided "doesn't need selection, let's let the user drag to scroll with their mouse instead".
Why even make it a 50/50 choice? I hate apps without selectable text and they're everywhere. Translating something becomes a nightmare and that hurts useability.
It's like if you made spoiler 50/50. Do you want to see this without clicking?
I think we really overlook the thought that had gone into making js, and other open tech.
Exactly. And I didn't even realize how often I subconsciously select text while I read until I saw the relevant xkcd. [1]
I truly think my random clicking on paragraphs that I'm approaching isn't just ADHD but a way of helping my eyes stay on track. It's very disconcerting when the text doesn't select. (As, clearly, all these comments noticed as well -- why were we all trying to select the text? To check if it's Flash-ish, of course, but also we just like things to grab onto while we read.)
Try putting their demo website in Google Translate or even try to select the text on an email in their demo webmail app to copy paste it in google translate ....
Yes but on the web you can use a user-agent that doesn't care about what the site says should be selectable, or at least an extension that overrides the CSS in question.
I'm not happy about "user-select" not having an easy override. But at least it can be overridden by a user CSS file or a browser extension, which isn't so bad. This is much worse.
I use the select text -> web search feature in Chrome all the time to quickly look up definitions of words. Breaking this will be really annoying to anyone reading webpages in a 2nd language than their own.
Why can't the default be always selectable? Let the developer choose which ones they don't want to be selectable. Also, what is the use case for non selectable behavior?
In the context of the web, this seems like it should be a non-starter. Why should the developer be able to tell the user what can and cannot be selected?
They already can, CSS has a property called "user-select" that can be set to "none". It's pretty common to disable user selection on label text that isn't expected to be copied.
This is annoying, but is at least trivial to get around with browser debugging tools. The web developer is not the person whose expectations matter. Selecting label text is almost essential for being to explain to someone else how to do things, or communicate about the interface with the site developer.
Depends on the label, it's not essential for plenty of things. I don't, for example, need to copy "Cancel" in my browser before I am capable of talking about the cancel button in the UI. You're right, user expectations are what matter, and users do not expect most buttons and controls to be text-selectable. It was never an expectation in native apps while users find it frustrating when control labels unexpectedly seep into blocks of text they are dragging to select.
Most users don't open devtools to workaround this (Safari doesn't even enable devtools by default). While it's annoying when developers get it wrong (put "user-select: none" on things that should be selectable), this changes very little for the vast majority of web users.
Sure but presumably many developers who are deciding whether to adopt Flutter aren't only targeting a population of you and other people in this thread. The fact remains that this is not a significant issue for most users and rational developers will weigh it as such against potential benefits that Flutter provides.
I guess but... I don't think that changes anything about the complaints that people have about this. What you're saying is a fact, but I don't think it's a relevant fact.
I'm looking over this thread, nobody has said that they're in a majority. We're just saying that Flutter's default behavior is bad for us, and that it encourages developers to make bad choices about text, and that it's pretty demonstrable that the average Flutter app has less selectable text than the average web app in general.
The fact that many companies will not care about this when weighing the technology is exactly why we're complaining. Because we don't want the web to suddenly become unusable for us just because we're in a minority of users.
It still doesn't make me feel any better or make me any less likely to complain to hear that my problems don't affect everyone else. It's not addressing the criticism, or explaining why I shouldn't be upset about Flutter's decision, or explaining why the current situation on the web is equivalent. It's just a polite way of saying, "yes this will affect you, but we don't care because we don't think you can do anything about it."
And yeah, it's probably true that this issue in specific is not going to cause Flutter to fail (there are plenty of other problems with Flutter on the web that will do that), but does that fact change anything about whether or not widespread Flutter adoption would make my web experience worse?
I think you overlook that, at least to me, it's an accessibility thing and as such, is not just the population of people here in this thread but is an issue for anyone who is disabled and takes advantage of those features of the web, and now will not be able to in Flutter apps.
I know Flutter is working on accessibility, but they have already made choices that are counter to the default expectations web users have. And are having to work to fix the accessibility issues they introduced by not adhering to web standards and/or best practices to begin with.
I am aware, and I would argue against any spec that told me to implement that also for the same reasons I don't think its a good idea for Flutter. Not that I haven't had to do it for reasons, but I'd make the case against it when I can.
Don't want to restart the entire thread that already existed, but I rarely check comments and just saw this.
As a user I don't want the developer to need to anticipate which text ought to be selectable as they will inevitably fail to consider some use cases it ought to be the default.
If `Text` and `SelectableText` exist, I would call that an opt-in. The default is "Text" (not selectable) and a modifier can be applied to opt into using "SelectableText". It would be different if they were called "UnselectableText" and "SelectableText".
Seems like every dev using Flutter for more than a few days would know that both `Text` and `SelectableText` exist and pick the one that's relevant to whatever kind of text they're adding. At that point, it's the dev's fault for making a conscious decision to make text selectable or not (if they choose wrong); not really the language's.
I get that user-select was already a thing in CSS, but why is so much of the text in the demos at https://gallery.flutter.dev/ not-selectable? It's a real bad look.
Not only is this making it easy for app developers to do the wrong thing ("I will just put some text here and make it unselectable, that is going to be great UX") but even worse, it is the default?
There are going to be some unintended consequences here, I suspect.
This reminds me of those websites that use javascript to preventing pasting into password fields "because security", thus breaking everyone's password managers, and making everyone less secure in the process ("if I have to type in that password every time, I'd better choose something simple I can remember...").
So, what about accessibility? If the text is not accessible, how are screen readers going to work?Vision impaired people are just going to have to ... do what, exactly? Will they have to apply OCR to access the content of a Flutter app?
This really reminds me of what was so sucky about Flash. I guess we'll get lots of little walled gardens that make basic interaction via text deliberately difficult. This feels like the opposite of the open web.
Come on. Isn't this only happening because the initial text widget did not have text selection, the one with text selection came later and now we are in this bad situation? Just enable text selection for both/all text widgets when targeting the web. You could couple that with a major version increase...
This feedback you get here will only get worse with time, and it will block adoption.
Is the goal to get full parity with native text selection? I went to the plasma demo and tried to double/triple click on text and it didn't match what text selection is supposed to do, at least on macOS. Which makes it a bit jarring. Right now it seems to be a bit "uncanny valley".
(Disclaimer: I work for Google but not related to Flutter.)
I think the selection some improvement improvements needed reach a native-feel. For example, interactions like triple-click to select a line.
However I think the decision to make text selection opt-in makes sense from the context of an application that targets web.
For example, if you open up your mail app or Slack, you will find that a lot of text on the screen isn't selectable. For example, you can't select the text of the tabs on your browser.
If all text was selectable by default for an app, it may cause unexpected results rather than having the develop opt-in to deciding what is selectable. We have many widgets in our app that we wouldn't want selectable for UX reasons.
In practice, it hasn't been much effort for us to make things selectable. Just need to replace a Text widget with a SelectableText widget.
Isn't this a feature? Having text easy to copy and paste is a copyright problem for many sites. Same with being able to save full-resolution images. It's pretty common to see a copy/paste in forum comments to get around a paywall.
IMO either this or some other webassembly view is the future, simply because it's great DRM. Sure, you can circumvent it, but most people cannot.
I do think it's the norm, and very much dislike this trend.
I should make my position more clear: I hate this stuff with a passion. But, big business wants better content protection, and big money always gets what it wants - very few exceptions there. I wish we could do something as technologists who want to keep these features of the web; but against trillion dollar companies I know who I'd bet for...
I would expect you to have come from a react background then? When evaluating technologies 1.5 years ago for the company I work at, I took a good look at comparing both react native, as well as flutter, and we decided on flutter.
Now, out of the many considerations we had, in this process, "cannot copy the text" is... well, I have no idea what you are talking about. Are you referring to not being able to do this in a EditableText widget, and if so, have to tried a `TextField` with `enableInteractiveSelection: true`?
I mean, there should be hugely more important development concerns when evaluating these things, than... a brief rejection based on something as trivial as that. Then again, I won't presume to know your situation or the criteria you had. But it does strike me as a bit... shallow reasoning.
I can say, that for our case, the dependency hell that you more easily get with React Native was what put me off completely.
Looks like a very developer/product-owner-sided opinion, not being able to select text and other "trivial" things are what makes software tolerable and actually usable, as listed by sibling post by kevincox, I'll quote:
> Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions...
Throwing away all platform conventions is a very heavy-handed and user-unfriendly way of bringing about portability.
Another triviality, for example is the behaviour of scroll chaining as compared to my browser: In Flutter, as soon as the inner scrollable hits its boundary, the outer scrollable takes over, while the expected behaviour for me would be for the outer scroll to not move until I reposition the mouse.
It's exactly the same as Microsoft's Windows 8 fiasco, by unifying the experience across platforms every one of them felt broken and contrived, and this effect is even more notable if your application deals with a more diverse user-platform ecosystem. Your app will be the odd one out that works strangely compared to everything else in every system.
I do appreciate your point of view on this, and I hope I did not come across as dismissive of your choice. If it was a thorough evaluation of the capabilities, and it did not seem able to provide the user interactions you needed, I'm sure that is then a reasonable enough basis. My knee-jerk reaction however, was to think this might have been made without properly evaluating the capabilities of the platform. If I head over to https://gallery.flutter.dev/#/crane, I am annoyed by how "app-like" it feels. I'm in a browser, I should be able to select tings. Clicking and dragging isn't supposed to scroll, it's supposed to select. It feels all wrong. But then again, this was mostly when coming at it from a "this is a website" approach. If the use case is to develop an app, then the conventions used have not felt weird to me.
Fair enough, and sorry if I seemed a bit combative too.
However, I believe "this is a website" or "this is an app" is a perspective the user will take, despite what our intentions as creators were, and so, the safest bet would always be assume what is the norm for the platform, since the user would never be "disappointed" by that even if they expected an app-like feel. On the Web, (at least some, in my anecdata most) people expect to see Websites, even if highly interactive ones.
I have not tested Flutter in a mobile application so I wouldn't be able to tell if it feels par to the course with other mobile applications, so it might be viable if you only need "Android<>iOS" portability.
I'm glad we can be nice, stalking and all :D. I think those are very valid points, and I think Flutter has a much more natural place as a framework for mobile apps, or desktop software. The gallery showcase feels like a half-assed attempt at creating web-site like pages, that as you pointed out, all feel wrong. So using flutter to develop something like that, I think I'd have agreed with you. However, from just the app side, I do feel flutter developers have made the UX very much in line with that of apps. I rarely know if an app is made using flutter, or pure android (as for iOS, I have no clue. The cupertino stuff looks like iOS to me, but I also have no clue).
I'm also not entirely convince that native apps with flutter is a good thing, especially considering that I'll be just another attempt at providing an opinionated UX stack that is completely different from that of the native experience.
So, maybe we agreed more than we thought. I also believe that a native experience, one that matches the otherwise existing UI interactions should be king. Throwing App UX paradigms into website or desktop app bound to feel terrible. Maybe it can be made more enjoyable to use with better configurations more in line with the respective platforms.
Breaking common user affordances (e.g. the back button, bookmarks, text selection, copy and paste) is indeed a big concern in the apps we make at my workplace and I would hope that's the case anywhere that values a positive user experience.
Would adblockers work on these kind of webapps? Adblocker typically look for specific piece of js files and DOM nodes to block ads, but Flutter web doesn't really work like that, no?
I haven't really looked, apart from glancing, into flutter yet. Now with desktops and mobile, premise seems interesting. How and does it compare to Qt?
My perspective is that Flutter is positioned dead on against Qt's QML. I develop mobile and desktop QML applications and this seems to be trying to be very competitive with it.
Qt also has a WebAssembly build for QML apps on the web but in my experience it has suffered from some of the same issues reported here about the Flutter WebAssembly runtime.
Edit: One key difference is Flutter seems to do everything with procedural code. QML is based on a declarative DSL plus Javascript.
I'm not sure, but I think that you have to use Dart language to use Flutter.
Incidentally, I was pretty sure that Dart was dead. Turns out it's alive. I'm not sure what it is currently, now that it's statically typed, null safe and all. What are Dart's killer features?
It's not clear to me that killer features are really a thing for most languages. Sure Haskell has laziness/purity and Rust has ownership.
But what is C++'s "killer feature"? C interop? It used to be OOP but it's not that any more and yet C++ is still massively successful. What is Java's killer feature? GC? C#'s?
I think most languages don't have killer features, they have killer platforms and frameworks. For C, it was Unix. For Java, it was servers and the broad set of libraries. For C# it was WinForms and now Unity. For JS, obviously, the web.
I've been using flutter for a while and it has been great. The developer experience is awesome, and the community has released and maintained some very useful libraries. Dart is a bit strange but they've made some good improvements.
Flutter web last I checked was a bit strange, especially how text selection didn't really work. That was a showstopper for me so I didn't continue, but I'd definitely be interested in trying it again.
Pretty sure I'm the only person on this thread who loves flutter. We use flutter web and Firebase for our hobbyist project, and the results have been simply amazing.
Dart makes Typescript look like a joke. The build system alone makes flutter better than React Native !
I'm confident in being able to build any CRUD app in dart
Edit, in fact how many of you have actually built a project in flutter .I can't believe anyone would want to go back to react native after trying it
All of the complaints about flutter I see here are based on people using apps built with flutter, and not about the development experience. "Have you actually build a project in flutter?" is a total non-sequitor response to complaints about how even the official demo is miserable to use.
Would you not buy a screwdriver because some people with that screwdriver don't build chairs correctly ?
Like with Unity, the power of cross-platform development leads many to just assume apps work across platforms automatically. This is absolutely not the case, you need to properly QA any code you write and code it to accommodate each platform's quirks.
I would not buy a screwdriver if a salesperson walked up to me, said "look how great this screwdriver is" and then the chair they were holding as an example immediately fell apart in their hands. There's a difference between a dev community building apps that perform badly and the actual platform advocates showing off apps that can't perform.
Exactly! I always think of the official demos as "this is as good as it gets". Look at how Unreal Engine advertises. Beautiful! Will your game look like that? Probably not, but it potentially could!
All the Flutter demos I've seen today are saying "Do you want your app to, at best, take a long time or even fail to load, feel like scrolling through molasses, break when you click a button, and spin text around at 25 fps like a 2005 Flash animation? Well, have we got a framework for you!"
You're not the only person. After using two decades of improvements to JavaScript, Dart comes out swinging and wins without a contest. I don't want to spend all my time playing with build systems and and Flutter just works, plus even though JS is better these days, Dart in IntelliJ (Android Studio version) is so straightforward you can be productive from day one without having ever written Dart before.
We built our mobile app in Flutter, and it was pretty amazing. I would absolutely never suggest we create a web version of that mobile app and would strongly fight against it if someone else suggested it.
I strongly disagree re: Dart vs. TS, but then, I was a JS dev before I worked with Dart/Flutter, so probably a bit biased. But I think that is a very subjective statement, not objective.
Can you share any example of Flutter Web that isn't a extremely basic Todo app, doesn't completely break regular browser UX and works without being slow as molasses?
I haven't seen one.
I like Flutter, but I don't think the Flutter Web design is very viable for production apps. It renders everything in canvas. Dart is already sluggish on native, and cross compiled to JS it's usually unusable.
I think Flutter will be a good choice for mobile and Desktop soon-ish, but for web ... maybe in a few years. Maybe.
https://rive.app/ is built with Flutter. I use it a lot works very well for me. It's a good example imo of the kind of website that Flutter is a good fit for.
What is your main use case for type unions? I don't know typescript, but I haven't felt the dart language was not feature complete for all my uses. Is this something you cannot solve with a combination of abstract classes, and or/extension? https://dart.dev/guides/language/extension-methods
You could create an abstract class for the base response, then implement this abstract class for the two cases one where it has a list member, and one where it contains the object. Then, using the return value with something like `if (response is listLike) { }` the IDE already knows that you are scoped to having only the list like properties, and you'd get the full help of the language. Something like that, I suppose.
Yes, union types are really nice for data like that.
But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types).
In a language that is built more strongly on objects and static types, it's less common to see APIs that "return one of these, or one of these, or on Sunday one of these things". So there is relatively less use for union types.
In other words, because people express unions at runtime less frequently in Dart (and other languages like Java and C#), there's less value in supporting them statically. Still some, definitely, but I don't think it's as critical of an omission as you might expect coming from TS/JS.
People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goes wonderfully well with them, allowing for exhaustiveness checks and all that.
The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.
I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature.
The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?
> The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check.
The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great.
Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style.
Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.
- Scala has the whole OOP stuff
- F# as well
- SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works.
- OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully.
- Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that.
So I'd say it might not be as ergonomic, but the capability is still 100% there.
(Small excerpt from a game we're developing at $dayjob)
You can switch on that and the compiler will know what variant you're talking about, and it will apply exhaustiveness checks (ensures your code will handle all possible states)
Haha. That's alright. That looks super neat though, I must admit. The only equivalent that comes to mind would be using an abstract class. I still might fail to fully understand what that code example does, but, would this be somewhat similar?
abstract class AppState {}
class AppLoading extends AppState {
final int progress;
}
class AppSelectingLevel extends AppState {}
class AppPlaying extends AppState {
final Level level;
}
...
Certainly not as neat, but also, not that far off either. Then where you use this app state, you could switch over its `runtimeType`, and in each clause, the IDE will understand which implementation you are dealing with, and actually give you context sensitive help related to that particular state.
If you instead only cared about one case, you would be able to do:
if (appState is AppPlaying) {
doSomething(appState.level);
}
Would this be somewhat analogous to the functionality you get with unions in typescript?
Indeed, that is basically what you get from unions, except the exhaustiveness check.
Unless I'm mistaken, if one were to later implement a new class that extends AppState, all existing code would compile, but possibly fail or misbehave at runtime, unless you meticulously checked every place that tries to determine something based on those derived types.
In TypeScript, adding a new case for an union and not handling it everywhere is a compilation error on every incomplete usage site.
I have to say, the default diagnostic isn't brilliant, but some tooling will give a better error and actually point out the missing arms, instead of complaining about the return type.
I suppose. In practice, I haven't experienced this to be a problem. Since you already check which implementation you are dealing with, any code that relied on any state, should still work without any issue. This is the same as with typescript unions. Any code that somehow needs to handle a new state hm... I suppose getting a compile time error is nice to immediately see all places where it is used... but, I mean, so would a "find all uses" search. It's also not all that different from the linting warning error you'd get from iterating over runtime types without handling all cases.
All in all, sufficiently analogous to not consider unions a missing feature of the dart language? Seems nice to have, but, maybe not very necessary. Especially if the only difference is whether it is considered an error by the syntax, or a warning by the linter.
The proper analog to union types in Dart (as in Java) is enums and / or church-encoding [I think that's the term] generalized algebraic data types (GADTs). E. g. something like this: https://gist.github.com/jbgi/208a1733f15cdcf78eb5
Scala 2 also had `sealed` classes that could be used in places where you needed enums parameterized by runtime values and that's been generalized in Scala 3 IIRC.
I'm certainly confused now whether or not we are talking about the same thing. Without delving to much on the use of the word "union", how would you solve the use case presented in the typescript examples using enums?
The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.
Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)
I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.
> Have you considered not going full-on structural-typing but still providing some sort of union?
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
No time frame, sorry. We generally don't make promises about future dates because schedules tend to be flexible and picking dates just sets people up for disappointment.
Yea I have used Flutter for hybrid apps and love the dev experience. The apps have come out great, and are smoother than my native Android work.
I am really hopeful for it and am going to keep using on it for hybrid apps.
I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.
You are not the only one -- I've been developing in Flutter for the past couple of months and overall I'm very satisfied how easy it is to develop in it compared to native Android and iOS. Being native Android dev, I truly believe that there is a future in Flutter. Till now I was rejecting all the other cross-platform frameworks.
Big part of it is thanks to the community which is providing all the handy packages to add some native stuff easier (such as permission, localization etc.)
I agree with other comments that Flutter Web is not ready yet I've tried to build web version for wish list sharing based on Flutter and I was struggling, so in the end I've switched to Tailwind + Vue. Some issues I had was that website didn't behave like website. For example I couldn't select text with my mouse. It felt and behaved more like a mobile app through the browser.
For mobile though it works (almost) perfectly, my example of the mobile iOS and android app build with Flutter: https://wishpy.com/
Although it loads a bit long at the beginning and I still need to figure out how to show images and icons without an uncomfortable glitch at the screen start.
This is DOA..... fine for some generic/basic app, but I wouldn't touch it with a ten foot pole if you are building a serious app.
This is another attempt from javascript/web front end developers trying to unseat native apps.... with the naive promise that is truly build once, run everywhere...
It hasn't worked since 1995.... as these frameworks get decent, native apps push the envelope and user expectations just increase over time, and apps created by these framework just look outdated or as toys.
We have used Ionic to build once deploy on mobile and web for years. It works really well for us now. (I am not sure it would work for all usecase but my guess is 99% of non-game apps would be fine).
Flutter for mobile apps, cross-platform across Android and iOS is pretty amazing. I do not like what they are doing with Flutter Web, but that doesn't change that it is a pretty amazing framework for cross-platform mobile development.
Also, it isn't FE web devs driving Flutter. I know a lot of mobile cetric devs who really love it.
779 comments
[ 3.4 ms ] story [ 376 ms ] threadI assume most of the showcases mentioned here (WeChat, Grab, Yandex Go, Nubank, Sonos, Fastic, Betterment and realtor.com) are Flutter-based on Android only?
Is there a well-built Flutter-based iOS app without jank now?
The (new) google Pay app on iOS[0] and Android[1] are flutter based. I'm on Android, so I don't know it's behavior on iOS.
[0] https://apps.apple.com/us/app/google-pay-save-pay-manage/id1...
[1] https://play.google.com/store/apps/details?id=com.google.and...
I replied above as well. My team has also not been satisfied with the performance of the GPay app on all devices. We've been working with the GPay team since release and made many improvements in both Flutter and the GPay app. I expect there will be an updated GPay app soon, with still more performance improvements in the pipeline.
NFC on the other hand is so unreliable as to moot the use of Google Pay, which is unfortunate. I really prefer tap-to-pay over anything else, but not at the expense of making people in line behind me wait as I try various workarounds like toggling NFC. I realize there's nothing you can do about it - my grumbling is more a warning to folks who (like me) may have used it previously on the Pixel 2 and loved it. It's problematic in the Pixel 4. :shrug:
https://www.androidpolice.com/2020/10/26/tap-to-pay-issues-w...
The work arounds seem to be:
0 - Remove any skins / bumpers / cases from the device.
1 - Lock and unlock the device.
2 - Toggle NFC mode.
3 - Reboot the phone.
I've seen some speculation that on the Pixel 4 it could also be due to some flexing in the case. During a two week period where I couldn't find my wallet I spent a lot of time trying to make it work because of Chase's allowing tap-to-authenticate on their ATMs. Out of 100+ tries using those work arounds and several different ATMs (in case that was the issue) it worked once.
I ordered a tile for my wallet since I can no longer rely on my Pixel 4 as a replacement credit card.
According to AppAnnie, most of these are using Flutter on iOS too: WeChat, Alibaba, Grab, Nubank, Sonos all show up on their list of Flutter-powered apps on the Apple appstore. We don't capture analytics on apps, so our sources here are external sites like AppAnnie (or occasionally, direct connections with the development team).
Edit: If the signup screen in the Grab iOS app is written in Flutter I'm very impressed. I want to believe.
Edit 2: Nubank: I only evaluated the sign-in screen(s), but it has enough animations at what seems like a very solid 60 fps on my iPhone X to convince me that Flutter on iOS is actually a real thing now. Very nice.
They write about their development effort here: https://building.nubank.com.br/scaling-with-flutter/
Edit 3: Maybe I jumped the gun here. Quote from that post: "We’re also facing hard prioritization decisions, especially in flows and screens that work very well in their current state (native Objective-C, Swift, Java, Kotlin, or React Native) for which there are no near-future update plans."
Shameless plug, the app is https://droppod.gg, an app to find time to play video games with your friends!
I don't know if that's flutter or you, but it doesn't fill me with confidence.
The post isn't 100% clear on this.
I tried out Flutter a while ago, and it's really promising as the only really viable alternative to the JS/browser stack for cross platform GUIs.
Dart is not terribly inspiring and lacks the appeal of other new languages like Kotlin or Swift, but it's fine; as in: boring/easy to pick up and good enough for frontend, although somewhat sluggish.
ps: I personally don't see the design of Flutter Web as viable for production apps, so if you need Browser support, a JS stack will remain the only solution, at least for a few years.
It's such an easy language to pick up, and if you know TypeScript/Java/JavaScript, it feels immediately "home", you just know how to do things.
Regarding Swift and Kotlin, yes, they have more features, but that makes those languages also harder to learn and more difficult to master. I think Go demonstrated that more simplicity is also important and more features does not automatically mean you'll be more productive (that's not to say that Swift or Kotlin is bad, I just want to express that Dart feels great).
Extensions, null-safety are already here, and data classes are being worked on, so I think the Dart teams listens to the feedback from the community and prioritizes well.
a.) Google fixes Flutter Web and all of its idiosyncrasies
b.) Google removes the jank in iOS apps.
There's no difference between CanvasKit and HTML as far as interactions are concerned. The differences are in pixels and performance. If there are issues with interactions, we'd like to hear about them. Please file issues on Github.
But yeah it's not grabbing market share that's for sure.
You're right -- we do render the controls, so that existing Flutter code (that might itself include custom styling or matrix transforms) just runs without change or surprise, but we integrate with the underlying browser support for things like text autofill and accessibility.
As the erstwhile editor of the HTML standard for ~10 years and the now TL of Flutter I must admit that it's weird to be creating a web framework that completely ignores all the HTML stuff I worked on before. :-)
That said, Flutter is different from Flash in some important ways. Flash used the NPAPI to "break out" of the web and was basically "native" code you could escape to, whereas Flutter really is using web APIs, like Wasm, ARIA, WebGL, JS, WebComponents, and so on, to create true web apps that just happen to not use much of the control set that HTML exposes.
I suspect that even outside of Flutter, the web in general is going to move towards this kind of framework in the coming years. It just gives you so much more control. It's basically how every other platform works -- pick your language, compile to machine code, don't need to be limited to what HTML and CSS (etc) enable.
That is exactly defeating the point. Flash apps were also "true web apps" that only happen to use the "limited control set" of just <embed>.
> It's basically how every other platform works
That's why there has never been a UI toolkit as successful as the web.
Not really. They were not portable. NPAPI was not a web standard in any meaningful sense (hint: the first N stood for Netscape).
> That's why there has never been a UI toolkit as successful as the web.
The web's success in terms of active users and in terms of deployed content is astounding, certainly. I think I'm relatively well placed to understand why, and I don't think it's because the web restricted developers to one scripting language or one set of controls. I think it is very much _despite_ that.
It's the web in the sense that almost every UI toolkit also offers a canvas (for example Tk does this) and you can reimplement every control using it. That doesn't make your new toolkit in a toolkit Tk.
But the framework? That will have to be updated when each OS the framework runs on changes.
The HTML controls are used by a ton of stuff, so they're quite likely to be updated. Your framework? I have to really, really trust you that you'll update them.
Look at how Motif or GTK or AWT or Swing or Tk widgets look on modern OSes. There's an entire graveyard of cross platform UI libraries out there.
I would be surprised if someone heavily involved in the Web's development process for a long time didn't have some really sore spots about it.
That aside:
--
What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
Fairly loaded questions I guess, but realistic ones too, not just philosophical.
Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages.
I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we sailed past the point where view source stopped being useful years ago. Everything now is minified, and sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
> How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
> Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
I have not. A lot of people do like extensions though.
Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
> Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using HTML/CSS/JS, even if not perfect.
Perhaps if Flutter became mainstream enough that there's theoretically nothing stopping this from eventually happening for it as well. That's an interesting thought.
--
I suppose that leaves my last question, and it leans away from what might be a practical view from your position: Do you think flutter pushing for major market share while also trying to replace the core part of the web (HTML/CSS/JS -> Canvas renderer/wasm) is a good thing for the web's health and future?
(That's a good bit more philosophical, but I hope in #CURRENTYEAR we're starting to see value asking long-term questions like that, especially from inside of the giant companies. I'll stick to one of those kinds of questions)
--
> I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
That is interesting, thanks for sharing that.
> I have not. A lot of people do like extensions though.
Also interesting, fair enough.
> Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
Perhaps a good new question is what kind of tooling is available or planned for users to interact with Flutter applications? Such as what Devtools provide, or an expansion to them directly.
As a developer, the Devtools are absolutely critical to my workflow and ability to learn from and often fix issues I have with other sites.
(It could be pointed out that native applications don't tend to have that functionality, so it shouldn't be expected.. but in this context we're talking about effectively removing it from the Web, which does)
FWIW Flutter isn't trying to replace the web. We're trying to offer a way of writing web apps that aren't really possible today. For example, something like the Flutter Folio demo, which works on multiple platforms including web, was written in a few weeks. I cannot fathom how I would do that without Flutter.
I got into web design/programming in the 90s, and the answer is basically no. Sure you could poke around a bit, but I never found it to be a revelation. I still had to buy books, read blogs, and do a ton of trial and error. Also, it was a never-ending game of trying to testing to see what each new browser release added or broke.
We are in infinitely better position today thanks to open source. The "View Source" of today is GitHub. Want to write a high-performance dynamically typed language VM? Here: https://github.com/v8/v8 Build an operating system? OK: https://github.com/torvalds/linux Build a database? Here you go: https://github.com/postgres/postgres
I love the idea, but this sounds like it's going to be unpleasant for me. Hopefully they figure out these UX things.
* The page takes about 20s to load.
* After pressing Run, nothing happens for 10s, then Click me! text appears.
* On clicking the text, nothing happens.
* On clicking it a few times, the page crashes and reloads.
As timsneath mentioned above, Dartpad is the dev environment. That means we ship the full Dart and Flutter SDK ahead of time as you can type/change anything in the code box. We also ship debug metadata to give better errors.
In production mode, we do a much more expensive compile to remove the parts of Dart, Flutter, and packages you don't use and to optimize/minify the rest.
It is working in Safari for me, but we've definitely appreciate bug reports if it's breaking for you (https://github.com/dart-lang/dart-pad in this case).
The labyrinthine rats nest of absolute hot garbage to beat a document rendering engine into a windowing toolkit with widgets is horrible. It's a testament to front-end devs that with enough effort you really can squeeze water from a stone.
And then imagine being so comfortable navigating that maze that you want your windowing toolkits to behave more like document rendering engines pretending to be windowing toolkits.
And you're like "why not just have a windowing toolkit for the web and sites can choose their rendering engine basically so all the SPAs get all the nice features of stack-based GUIs and document people get documents. Surely that would be less work!" And I think you're right but I doubt anyone would agree on a single toolkit so now you can just bundle your own compiled to wasm and rendered to canvas. Woooo.
In general Flutter for Web is _amazing_ if you want to deploy an app.
after seeing this thread, pretty clear to me its almost a perfect nerdsnipe - makes perfect sense if you're already building a Flutter codebase, sounds bonkers if you build web apps.
[1] https://www.flutterfolio.com/#/?
The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.
We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.
I think this is right, but I also think it should be clear to everyone (i.e. in the first tutorial) that not using a Link widget will make this work wrong for all sorts of accessibility and UX reasons. And the Link widget should work across platforms and implement the equivalent of page history correctly.
Maybe it's worth writing down somewhere what the equivalent of each tag from HTML is; what is the canonical way to create an h2, input, textarea, button, a, img, etc.
This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms.
Instead of a cross-platform development environment doing that for you.
I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_
Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.
Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides
dstaley just said that those issues happen now. " I just tried a few samples, and ..."
I just tried the demos over at https://flutter.github.io/samples/#?platform=web and I concur, Flutter is utterly horrible for everything the web stands for. So not amazing and seems to actively make everything worse.
We certainly don't think Flutter should replace HTML or other frameworks. We hope Flutter will work well for many use-cases, but the web is huge. There's room for multiple approaches. If it's not working for your use-case it's totally fine with us if you use something else. We welcome constructive feedback on what's not working so we know where to focus our efforts.
If you're trying to create a classical website, it's not the right tool. Use html and css. If you're trying to make a rich app, I'd bet on Flutter.
I'd be interested in seeing it become easier to make a combination of the two -- flutter apps embedded in classical websites.
Sounds like Java applets.
If the accessibility story isn't rock-solid, frankly this is a non-starter for a lot of applications. Web apps suck in a lot of ways but regular HTML has pretty great accessibility properties.
Accessibility is actually a really big deal here on Flutter (Ian Hickson and I both worked on Accessibility in browsers for years). AX is something I feel we've done pretty well with on iOS and Android. Web is still pretty early days, but many AX features should work already. We have more AX work to do on web yet. We've not yet taken any Flutter Web apps through Google's accessibility testing processes similar to how we've done on the mobile side, but I expect we will soon.
[1] https://flutter.dev/docs/cookbook/plugins/picture-using-came... [2] https://pub.dev/packages/geolocator
However, I worry about accessibility story for Flutter applications. Am I naïve? Should screen-reader support be a concern for the kind of complex visual applications that Flutter is built for?
Flutter 2 also supports accessibility for web apps, and you can use Windows Narrator, VoiceOver, TalkBack, or ChromeVox screen readers to navigate a Flutter web app.
I say that because if you strip or pack the binary, instead of working it shows the output of running dart with no arguments.
It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.
https://github.com/dart-lang/sdk/issues/45197
It is AOT though. If you time `dart a.dart` vs `./a.exe` (pre strip :-), the latter should be considerably faster.
`dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code.
The approach is not pretty but was chosen as an implementation shortcut.
That's why `strip` does not actually do good things to the binary.
There is no reason to run `strip` on such binaries - because they don't contain anything strippable.
I didn't inspect the binaries, just try to see how/if they compress.
0 - https://flutter.dev/docs/resources/architectural-overview
1 - https://github.com/flutter/flutter/wiki/Custom-Flutter-Engin...
Kotlin is pretty great - so you're in this situation where you can either learn Flutter or JavaScript - at least with JavaScript you can also target the web (I'm aware that Flutter 2 also can target the web, but it's not the same thing).
edit: I must clarify - I'm not saying software development must necessarily have only one language, but rather that there exists a single language that can target all environments natively. C was close, but then the web and mobile happened. Java was also close, but no dice. We're getting there, I think.
Perhaps I'm misunderstanding you.
French 0,5 x 3 000 = 1 500
The period thing is very tricky, I often parse big numbers in English are super small ones.
[1] https://en.wikipedia.org/wiki/Penrose_graphical_notation
I know 3-4 options just for C#.
A modern UI, crossplatform, AOT compiler UI toolkit, that includes phones, web, and desktop
Not even dotnet could achieve this
Even if i'm not interested in that kind of development, let's hope people pick this instead of the atrocity that is electron
I said provide, not "goal"
you have to use the Amplify library from AWS
- MFC
- WinForms
- Windows Presentation Foundation
- Xamarin & Xamarin Forms
- Universal Windows Apps
- WinUI 2 & 3
- React Native fork for Windows (based on WinUI 2 migrating to WinUI 3)
- React Native fork for Mac (based on AppKit)
And now they also contribute to Flutter, wow.
I don't know how they can claim this. The new Google Pay on Android was noticeably laggier the moment it was released. It continues to be so, and I still hate using it. Now I know the cause.
I was also pretty salty that the new Google Pay app was marked as "early release" so you couldn't leave a review on the Google Play Store. That's fixed now though.
The initial GPay Flutter release definitely had some performance rough spots. We've learned a lot from working with that team since release and have made resulting changes in both Flutter and the app code.
GPay hasn't released since December last I checked, but I expect the next release should perform better on both iOS and Android and we will be continuing to work with them closely over the coming months.
go ahead and take time to downvote my comments. do you boo
iow, maybe they dont have access to all the internal implementations that give the native toolkit higher performance...
can anyone clarify that?
It is refreshing to be able to start development quickly without worrying about tooling (react-native), CI, etc.
Also I feel like Dart is perfect. It's a joy to use, I feel like this is the future. It's not es6 and it's not Java either.
Those seconds are excruciating when I'm at a checkout trying to actually use the app, with a large line behind me and a checkout person staring at me.
AAA publishers are pushing heavily for this since it makes piracy and hacking obsolete and they always get what they want - there's no way that this is not the future of "popular" gaming.
I tested this Flutter example[1], on a 16" MBP with and i7, and it is janky as it can get, it feels like I'm using a 15 year old computer. From the code it looks like the whole thing is... rendered on canvas? I'll pass.
[1]: https://gallery.flutter.dev/#/
The whole thing feels like Adobe Flex in 2010. It solves a great deal of problems that the web had but introduced a plethora of others.
Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested.
https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.
Edit: You may want to add the NVDA open-source screen reader for Windows to your list. And when you test with a screen reader, make sure you use it the way an actual user would when browsing the web, e.g. using NVDA's browse mode with the arrow keys to move through the page.
Spoken like a true product evangelist. Good palm off with the "create a ticket" too.
They're completely unusable in Firefox. For example, it only scrolls 3 pixels per rotation of the scroll wheel on Windows 10
Which year is this ?
"Buttery smooth animations and scrolling" will be a great selling point for flutter ..if it actually works.
(Firefox)
Here's a hard question, why is this surprising to you? What are you missing in development--is this a gap in testing? Are you hamstrung without support internally to bake this as long as it needs? Rather than double-down on extolling the virtues here, it's time to double-down on fixing the team and the product.
It's... It's very easy to learn more for yourself.
- Ask your company to provide you with a MacBook Air (not the M1, a regular one) or a mid-tier PC
- Use any browser other than Chrome (and other thank Blink-based browsers)
- Go and use the very same demos you so proudly present
Boom. Learning.
I hate to be critical - I'm sure a lot of work has gone into this - but there's still lots of room for improvement too.
Not up to the speed of well-written Javascript, but definitely viable.
In contrast, this is completely unusable on other browsers or on lower powered devices.
On Firefox desktop, initial loading brings a "This page seems to be stuck" prompt. Once it finally loads, clicking the play button just does nothing.
Please note that for 80+% of websites/apps, Firefox is faster or on par with Chrome for me. Google products and some other exceptions are the only ones that are consistently slow on Firefox. Whether that's intentional or just a lack of testing, I can't say.
Similarly unusable on Safari.
On lower powered devices this just freezes Chrome for me.
As I mentioned in other comments, I like Flutter, but Flutter Web is not anywhere close to being viable for production use.
> production ready
Pick one.
That isn't a counterpoint to say the language might be worth considering. That's an additional data point to give me reasons to not use it yet.
Please look at the Source (in chrome) to compare.
Works great in Chrome though, what a surprise!
You can see the difference in the example on MDN as well: https://developer.mozilla.org/en-US/docs/Web/API/Element/whe...
The scaling there works with very different speeds in Firefox and Chrome because both disagree on what value the delta should have. Scrolling up once yields -100 in Edgeium for me and -3 in Firefox.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I don’t think it’s an issue with Safari.
Ironically computers 15-20 years ago with native software ran much, much much faster and snappier. KDE3, XFCE, even Windows 98SE and XP were much faster. They were crippled by disk I/O, true, but once the software loaded, the feedback was inmediate.
note that heap+haxe is pretty much "the same" as flutter/dart - a language, a compiler and a runtime + a rendering engine..
But the question that comes to mind with this kind of the technology from Google: is there any mandatory Google services that I'd have to use? Just as an example: Do I have to use Google's ad platform or I can use any other service?
> Today we’re announcing the beta release of Google Mobile Ads for Flutter, a new SDK that works with AdMob and AdManager to offer a variety of ad formats, including banner, interstitial, native, and rewarded video ads. We’ve been piloting this SDK with several key customers, such as Sua Música, the largest music platform for independent artists in Latin America, and we’re now ready to open the Google Mobile Ads for Flutter SDK for broader adoption.
from pay.google.com
> Starting April 5, you won't be able to use pay.google.com to send and receive money from other people. To send and receive money, use the new Google Pay app.
We were also not satisfied with the performance of the initial GPay release. We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app. Hopefully the next release of GPay will be out soon and others will be able to see the progress we're continuing to make with the team.
But still, you don't care that the Google blog post lie by telling the opposite of the real dev experience and the application user feedbacks?
Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress.
And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply no alternate universe where a third-party team gets the level of access the way you described the Google Pay team did.
Of course, it helps that the stakeholders are in the same company, but my point is, shouldn't there be a Flutter Foundation where every developer can feel at home on equal footing with other Googlers? Flutter is so promising, and yet, at the same time, I don't want to end up being slave to its complexities with no way out as a third-party small development shop.
Despite that, I'm 99% porting my cross-platform app to Flutter after strong reviews from other developers I know.
We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.
For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.
For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.
It had to do with their Invalidation tracker (a table, I believe, which is a living log of ordered updates that need to be delivered to observers).
https://www.reddit.com/r/FlutterDev/comments/jwmepu/very_poo...
https://thomasmiddel.medium.com/flutter-its-poor-ios-perform...
It brings my late 2016 MBP to a crawl if I am building on iOS simulator.
After reading online about it being related to Metal, and needing to switch flutter channels, trying that, and still seeing no success... I just gave up on Flutter (for now).
Maybe Flutter 2 has resolved this?
I would love to learn more about your experience. Would you be willing to file an issue and either post it here or CC me on it?
flutter.dev/support
FWIW, I was also using Rive animations in my app.
https://github.com/flutter/flutter/issues/21445
So seriously, how can you reassure any indie dev not getting VIP support to optimize their app for laggyness, that they can easily produce a decently performant app?
Could you elaborate on some types of applications which wouldn't or would be a good fit for Flutter at the moment?
There's a lot of comments and links to applications both working and non-working; but I don't really have a good gauge as to what works and doesn't.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
And then, the reality:
> We were also not satisfied with the performance of the initial GPay release.
Ah, the classic false advertisement.
Let me re-write the ad for you:
> Thanks to several-months-long involvement of Flutter's development we could finally fix some of the issues plaguing our app that we re-wrote in Flutter. We're still not close to the release, and we only hope it will be better.
Hi, I audited the performance of the GPay app. Almost all of the performance issues in GPay are related to its use of vector graphics libraries which make Skia spawn many new shaders that have to get compiled. The suggestion was given to move to raster graphics but since GPay ships in many locations that are sensitive to app size, like India, they made the tradeoff to keep raster graphics.
That said there are some longer term initiatives to address this problem on Flutter's side and Skia's side since the problem can show up outside of vector graphics, it's just more unlikely.
> Flutter 2 supports web now!
> We've re-written GPay in Flutter 2!
> We're dropping support for using GPay on the web...
"Didn't you simply delete the website?"
"Yeah, what of it?"
After April 5, I will have to use the app so that I can get back functionality that I once had on the web.
I can see it being useful for games and similar where there isn't really any UI but even then I would want dialogs and similar to use regular text that I can copy.
I am definitely not looking forward to flutter on the web. I foresee a lot of websites that I will need to avoid.
The only thing I do get is that you’d want open in new tab and copyable links. However, that’s hard from a developer perspective as you have to make sure you create links that store all data needed to rebuild the same UI in the same “conceptual” context but a different underlying data context (logged in user may be different, data may have changed so some saved context has become stale). You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar or a link by another user 2 days before, that may have been the result of that second user clicking through 10 levels deep in your app with all sorts of filters and options based on the state of data at that exact time two days before the first user clicks the link. Obviously you can’t show them the data from two days ago, but what if the data is still there but the path to get there is different? Does it conceptually still make sense to show the data and perhaps some breadcrumbs showing the new path? Or should you just say sorry that data isn’t here anymore? That depends entirely on what the data is and what you’re users are trying to do, so you can’t build one-size-fits-all technical solutions for this (if that were even possible). How are you ever going to reliably rebuild the UI and context that the first user intended to share by copying the link without spending huge amounts of time? That requires actual business logic and functional design.
For a lot of apps, it may make more sense to just have a share button in some places where you actually and intentionally support this (and where it will be actually used by a substantial number of users). Less time spent on developing things that are hugely complex and very little used (on average per state for ALL your different UI states that you have links to somewhere in the app, even if it’s a typical line-of-business master-detail form with some filters for the master list and a details segment with a dialog box or expanded element showing additional details of a certain property).
No, there are a few exceptions, but mostly yes. And I'm sure more than just the exceptions will use Flutter which is why I'm not looking forward to it.
> How many times have you wanted to save an image or copy text from a UI element in a native app?
Often. I mean not necessarily from a UI element but a lot of the time I want to get an image from a native app and can't.
> How many times have you been frustrated in a web app that when you search using the browser you are getting results from UI elements or “app chrome” instead of the actual content that the web app is displaying?
Almost never. There are rarely many extra results. In fact I already am bothered far more often when websites hijack Ctrl-F (I do not understand why browsers allow this) and fail to search the entire page. With flutter this will become the norm and I am not looking forward to it.
> Isn’t it enough to have some fields with content a user actually would want to copy/search
No, it isn't. I regularly copy things that people didn't expect. If it is just to send someone instructions how to use the app. In fact Android has automatic copy based on OCR from the app switcher and I use that a couple of times a day. There is already too much uncopyable text around. For example all messaging apps on android appear to only support copying the full message. This is what happens when you let people mess with standard UX patterns, they break them!
> You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar
Good! I love apps with great links. It makes them so much easier to use. I don't need to go through their custom navigation to get to my favourite pages. I can use the browser navigation that I already know and love. Also I can share links to my friends! Maybe I can help people use the app better!
You just described a bunch of problems that I already have! Especially on mobile devices. This is why I hope that Flutter on web doesn't take off. We will be making all of those annoyances more common! You seem to think that you can predict all of my use cases and provide the share button manually right when I need it. However product developers on a time crunch often miss or skip use cases so it is much better to have supported by default (like text find/copy that can be disabled) than hope that a developer will think, and find time, to implement them. And if URLs encourage people to make it possible to save and share the state of their app then I think that is a good thing!
Now I'm thinking of all the ways I could get screwed here.
* Not being able to copy transactions from my bank account
* Not being able to easily send text to a read-later service (not sure if this necessarily depends on selectable text, but who knows, maybe selectable means the text isn't visible to these services now)
* Not being able to easily copy something that needs entering into another page
This reminds of sites that try really hard to NOT allow password managers, or even allowing pasting of text into form fields.
Pass.
Web: defaults to selectable
Flutter on Web: defaults to Flutter, not Web
Most of the time a dev isn't thinking "I'd better make this selectable," because they simply aren't going to think of all the reasons someone might select text. They'll think of the obvious-to-them cases, and leave all the other text as unselectable.
It's like if you made spoiler 50/50. Do you want to see this without clicking?
I think we really overlook the thought that had gone into making js, and other open tech.
I truly think my random clicking on paragraphs that I'm approaching isn't just ADHD but a way of helping my eyes stay on track. It's very disconcerting when the text doesn't select. (As, clearly, all these comments noticed as well -- why were we all trying to select the text? To check if it's Flash-ish, of course, but also we just like things to grab onto while we read.)
1. https://xkcd.com/1271/
Or even translating...
Try putting their demo website in Google Translate or even try to select the text on an email in their demo webmail app to copy paste it in google translate ....
Most users don't open devtools to workaround this (Safari doesn't even enable devtools by default). While it's annoying when developers get it wrong (put "user-select: none" on things that should be selectable), this changes very little for the vast majority of web users.
"This thing that will noticeably make your web experience worse won't affect John over there, so why are you complaining" is not the best response.
I like to be able to override developer decisions about what text is and isn't selectable, and Flutter basically makes that impossible.
I'm looking over this thread, nobody has said that they're in a majority. We're just saying that Flutter's default behavior is bad for us, and that it encourages developers to make bad choices about text, and that it's pretty demonstrable that the average Flutter app has less selectable text than the average web app in general.
The fact that many companies will not care about this when weighing the technology is exactly why we're complaining. Because we don't want the web to suddenly become unusable for us just because we're in a minority of users.
It still doesn't make me feel any better or make me any less likely to complain to hear that my problems don't affect everyone else. It's not addressing the criticism, or explaining why I shouldn't be upset about Flutter's decision, or explaining why the current situation on the web is equivalent. It's just a polite way of saying, "yes this will affect you, but we don't care because we don't think you can do anything about it."
And yeah, it's probably true that this issue in specific is not going to cause Flutter to fail (there are plenty of other problems with Flutter on the web that will do that), but does that fact change anything about whether or not widespread Flutter adoption would make my web experience worse?
I know Flutter is working on accessibility, but they have already made choices that are counter to the default expectations web users have. And are having to work to fix the accessibility issues they introduced by not adhering to web standards and/or best practices to begin with.
Don't want to restart the entire thread that already existed, but I rarely check comments and just saw this.
https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
https://api.flutter.dev/flutter/material/SelectableText-clas...
Seems like every dev using Flutter for more than a few days would know that both `Text` and `SelectableText` exist and pick the one that's relevant to whatever kind of text they're adding. At that point, it's the dev's fault for making a conscious decision to make text selectable or not (if they choose wrong); not really the language's.
Not only is this making it easy for app developers to do the wrong thing ("I will just put some text here and make it unselectable, that is going to be great UX") but even worse, it is the default?
There are going to be some unintended consequences here, I suspect.
This reminds me of those websites that use javascript to preventing pasting into password fields "because security", thus breaking everyone's password managers, and making everyone less secure in the process ("if I have to type in that password every time, I'd better choose something simple I can remember...").
So, what about accessibility? If the text is not accessible, how are screen readers going to work?Vision impaired people are just going to have to ... do what, exactly? Will they have to apply OCR to access the content of a Flutter app?
This really reminds me of what was so sucky about Flash. I guess we'll get lots of little walled gardens that make basic interaction via text deliberately difficult. This feels like the opposite of the open web.
This feedback you get here will only get worse with time, and it will block adoption.
If the goal of the environment is to provide a new standard for cross-platform development, your default behaviors are extremely important decisions.
(Disclaimer: I work for Google but not related to Flutter.)
However I think the decision to make text selection opt-in makes sense from the context of an application that targets web.
For example, if you open up your mail app or Slack, you will find that a lot of text on the screen isn't selectable. For example, you can't select the text of the tabs on your browser.
If all text was selectable by default for an app, it may cause unexpected results rather than having the develop opt-in to deciding what is selectable. We have many widgets in our app that we wouldn't want selectable for UX reasons.
In practice, it hasn't been much effort for us to make things selectable. Just need to replace a Text widget with a SelectableText widget.
Isn't this a feature? Having text easy to copy and paste is a copyright problem for many sites. Same with being able to save full-resolution images. It's pretty common to see a copy/paste in forum comments to get around a paywall.
IMO either this or some other webassembly view is the future, simply because it's great DRM. Sure, you can circumvent it, but most people cannot.
I should make my position more clear: I hate this stuff with a passion. But, big business wants better content protection, and big money always gets what it wants - very few exceptions there. I wish we could do something as technologists who want to keep these features of the web; but against trillion dollar companies I know who I'd bet for...
Now, out of the many considerations we had, in this process, "cannot copy the text" is... well, I have no idea what you are talking about. Are you referring to not being able to do this in a EditableText widget, and if so, have to tried a `TextField` with `enableInteractiveSelection: true`?
I mean, there should be hugely more important development concerns when evaluating these things, than... a brief rejection based on something as trivial as that. Then again, I won't presume to know your situation or the criteria you had. But it does strike me as a bit... shallow reasoning.
I can say, that for our case, the dependency hell that you more easily get with React Native was what put me off completely.
> Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions...
Throwing away all platform conventions is a very heavy-handed and user-unfriendly way of bringing about portability.
Another triviality, for example is the behaviour of scroll chaining as compared to my browser: In Flutter, as soon as the inner scrollable hits its boundary, the outer scrollable takes over, while the expected behaviour for me would be for the outer scroll to not move until I reposition the mouse.
It's exactly the same as Microsoft's Windows 8 fiasco, by unifying the experience across platforms every one of them felt broken and contrived, and this effect is even more notable if your application deals with a more diverse user-platform ecosystem. Your app will be the odd one out that works strangely compared to everything else in every system.
However, I believe "this is a website" or "this is an app" is a perspective the user will take, despite what our intentions as creators were, and so, the safest bet would always be assume what is the norm for the platform, since the user would never be "disappointed" by that even if they expected an app-like feel. On the Web, (at least some, in my anecdata most) people expect to see Websites, even if highly interactive ones.
I have not tested Flutter in a mobile application so I wouldn't be able to tell if it feels par to the course with other mobile applications, so it might be viable if you only need "Android<>iOS" portability.
I'm also not entirely convince that native apps with flutter is a good thing, especially considering that I'll be just another attempt at providing an opinionated UX stack that is completely different from that of the native experience.
So, maybe we agreed more than we thought. I also believe that a native experience, one that matches the otherwise existing UI interactions should be king. Throwing App UX paradigms into website or desktop app bound to feel terrible. Maybe it can be made more enjoyable to use with better configurations more in line with the respective platforms.
It's not trivial.
Qt also has a WebAssembly build for QML apps on the web but in my experience it has suffered from some of the same issues reported here about the Flutter WebAssembly runtime.
Edit: One key difference is Flutter seems to do everything with procedural code. QML is based on a declarative DSL plus Javascript.
Incidentally, I was pretty sure that Dart was dead. Turns out it's alive. I'm not sure what it is currently, now that it's statically typed, null safe and all. What are Dart's killer features?
Looks like we're discussing one - flutter?
It's not clear to me that killer features are really a thing for most languages. Sure Haskell has laziness/purity and Rust has ownership.
But what is C++'s "killer feature"? C interop? It used to be OOP but it's not that any more and yet C++ is still massively successful. What is Java's killer feature? GC? C#'s?
I think most languages don't have killer features, they have killer platforms and frameworks. For C, it was Unix. For Java, it was servers and the broad set of libraries. For C# it was WinForms and now Unity. For JS, obviously, the web.
Flutter web last I checked was a bit strange, especially how text selection didn't really work. That was a showstopper for me so I didn't continue, but I'd definitely be interested in trying it again.
Overall very excited to see this release.
Dart makes Typescript look like a joke. The build system alone makes flutter better than React Native !
I'm confident in being able to build any CRUD app in dart
Edit, in fact how many of you have actually built a project in flutter .I can't believe anyone would want to go back to react native after trying it
Like with Unity, the power of cross-platform development leads many to just assume apps work across platforms automatically. This is absolutely not the case, you need to properly QA any code you write and code it to accommodate each platform's quirks.
I would not buy a screwdriver if a salesperson walked up to me, said "look how great this screwdriver is" and then the chair they were holding as an example immediately fell apart in their hands. There's a difference between a dev community building apps that perform badly and the actual platform advocates showing off apps that can't perform.
All the Flutter demos I've seen today are saying "Do you want your app to, at best, take a long time or even fail to load, feel like scrolling through molasses, break when you click a button, and spin text around at 25 fps like a 2005 Flash animation? Well, have we got a framework for you!"
I strongly disagree re: Dart vs. TS, but then, I was a JS dev before I worked with Dart/Flutter, so probably a bit biased. But I think that is a very subjective statement, not objective.
I haven't seen one.
I like Flutter, but I don't think the Flutter Web design is very viable for production apps. It renders everything in canvas. Dart is already sluggish on native, and cross compiled to JS it's usually unusable.
I think Flutter will be a good choice for mobile and Desktop soon-ish, but for web ... maybe in a few years. Maybe.
ps: for me the Gallery is extremely laggy in Firefox, but works decently well on Chrome. Maybe wasm is enabled on Chrome only.
Dart still does not even have union types, probably the best feature of TS. I would hold off on that claim for now..
my_type = my_list | my_object
?
You can see why this is better :-)
But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types).
In a language that is built more strongly on objects and static types, it's less common to see APIs that "return one of these, or one of these, or on Sunday one of these things". So there is relatively less use for union types.
In other words, because people express unions at runtime less frequently in Dart (and other languages like Java and C#), there's less value in supporting them statically. Still some, definitely, but I don't think it's as critical of an omission as you might expect coming from TS/JS.
The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.
I think you're confusing union types and sum types, which are very distinct features. SML, Haskell, and Rust don't have union types.
OOP languages can model sum types already. It's mostly a question of how much the surface syntax encourages that style.
I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature.
The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?
The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great.
Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style.
Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.
- Scala has the whole OOP stuff - F# as well - SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works. - OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully. - Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that.
So I'd say it might not be as ergonomic, but the capability is still 100% there.
But for me the main use for TS union types is to make discriminated unions, which is very useful wherever you have some form of a state-machine:
(Small excerpt from a game we're developing at $dayjob)You can switch on that and the compiler will know what variant you're talking about, and it will apply exhaustiveness checks (ensures your code will handle all possible states)
If you instead only cared about one case, you would be able to do:
Would this be somewhat analogous to the functionality you get with unions in typescript?Unless I'm mistaken, if one were to later implement a new class that extends AppState, all existing code would compile, but possibly fail or misbehave at runtime, unless you meticulously checked every place that tries to determine something based on those derived types.
In TypeScript, adding a new case for an union and not handling it everywhere is a compilation error on every incomplete usage site.
For example, try deleting one of the arms of the switch in this playground: https://www.typescriptlang.org/play?ts=4.2.2#code/C4TwDgpgBA...
I have to say, the default diagnostic isn't brilliant, but some tooling will give a better error and actually point out the missing arms, instead of complaining about the return type.
All in all, sufficiently analogous to not consider unions a missing feature of the dart language? Seems nice to have, but, maybe not very necessary. Especially if the only difference is whether it is considered an error by the syntax, or a warning by the linter.
Scala 2 also had `sealed` classes that could be used in places where you needed enums parameterized by runtime values and that's been generalized in Scala 3 IIRC.
The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.
Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)
I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
https://github.com/dart-lang/language/blob/master/working/05...
I am really hopeful for it and am going to keep using on it for hybrid apps.
I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.
Big part of it is thanks to the community which is providing all the handy packages to add some native stuff easier (such as permission, localization etc.)
I agree with other comments that Flutter Web is not ready yet I've tried to build web version for wish list sharing based on Flutter and I was struggling, so in the end I've switched to Tailwind + Vue. Some issues I had was that website didn't behave like website. For example I couldn't select text with my mouse. It felt and behaved more like a mobile app through the browser.
For mobile though it works (almost) perfectly, my example of the mobile iOS and android app build with Flutter: https://wishpy.com/
Although it loads a bit long at the beginning and I still need to figure out how to show images and icons without an uncomfortable glitch at the screen start.
This is another attempt from javascript/web front end developers trying to unseat native apps.... with the naive promise that is truly build once, run everywhere...
It hasn't worked since 1995.... as these frameworks get decent, native apps push the envelope and user expectations just increase over time, and apps created by these framework just look outdated or as toys.
If you can render swipes, fades, blurs and transforms you can create premium experiences without being native.
Also, it isn't FE web devs driving Flutter. I know a lot of mobile cetric devs who really love it.