It's the best parts of C# plus real dynamics. The Flutter ecosystem is already above and ahead of React Native , a big part of it is it doesn't have the baggage of npm, Babel and JavaScript.
For a friend's side project I've been using Flutter Web and I couldn't be happier with it
Couldn't agree more. For me Dart is basically a better version of js + java. Flutter is also the greatest GUI framework right now and their tooling is excellent. Every time i'm working on a flutter project i feel at home because i can be sure everything is gonna work out of the box. I only care about my code and nothing more.
Absolutely. Sound null safety is very exciting too! Using Dart/Flutter client side with sound null safety and then a few backend API's in Rust, would likely prove to be an extremely reliable system.
A perfect static type checker would distinguish between valid and invalid programs in all cases. In practice, static type checkers are conservative and occasionally reject valid programs. Gradual typing gives you a way out in these situations -- just like how macros in C can provide type-generic functionality.
A sufficiently rich type system (with tuples, union types, traits, generics, higher-kinded types, etc) can lessen the need for a dynamic escape hatch. In the end though, the occasional use of dynamic typing can be easier to reason about.
I took a gamble selecting Flutter overreact for an outsourced app. I basically didn’t know anything about either, but it landed on flutter because at sea developers that looked a lot more familiar to us.
I’m delighted that people who seem to know what they’re talking about also continue to like it.
It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried it.
We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.
How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces
Flutter's Text widget (which is generally the default for most devs when displaying text) doesn't allow for text selection. There's a SelectableText widget that does, though:
While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path.
I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
Huh I never noticed that with gmail. I'm guessing it's because if I wanted to copy some sort of text, you could do it with the email detail page. And most text is selectable there, from the email name, actual emails, document content, etc. In mobile devices, text selection is such a pain so the desire to do it is less.
Does selectable text have a performance penalty? In iOS UILabel is far faster to render than UITextView, but only UITextView is selectable. I wouldn't mind if many of my UILabels were selectable, but I'm forced by performance constraints to not let it happen.
Maybe put forward making SelectableText the default and renamed to Text and Text is renamed to UnselectableText and becomes the non default if there isn't a perf penalty? It would need an automatic migrator for that to happen although.
Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).
I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose
That has been worked on, they do use proper tags instead of a canvas so accessibility now works fine. The next issue is performance / scroll jank though and that will be tough to solve since the rendering model is very different from the web.
For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements.
Another one, basic browser features like backswipe on the trackpad to go back just doens't work.
Custom user agent stylesheets is another accessibility/power user feature that will not work
You cannot select any text as far as I can tell
Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work
You cannot copy or preview link URLs
You cannot copy image URLs
Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)
Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled.
Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too.
Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming.
Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.
Do give `--dart-define=FLUTTER_WEB_USE_SKIA=true` a try (`flutter run` and `flutter build` take this option, which we hopefully will rename to something more reasonable soon). If that doesn't perform well, please file an issue: https://github.com/flutter/flutter/issues/new/choose
It's the best parts of C# plus real dynamics. The Flutter ecosystem is already above and ahead of React Native , a big part of it is it doesn't have the baggage of npm, Babel and JavaScript.
For a friend's side project I've been using Flutter Web and I couldn't be happier with it