[HN Gopher] Flutter 3
___________________________________________________________________
Flutter 3
Author : tosh
Score : 242 points
Date : 2022-05-11 19:50 UTC (3 hours ago)
(HTM) web link (docs.flutter.dev)
(TXT) w3m dump (docs.flutter.dev)
| 5cott0 wrote:
| Figure out JSON de/serialization yet?
| tylergetsay wrote:
| Just make a class and generate helper methods /s
| LocalPCGuy wrote:
| I know this was sarcasm, but sadly, it is one of the better
| ways to handle this.
| [deleted]
| mekkkkkk wrote:
| What do you mean? Dart has decent support for encoding/decoding
| JSON, with revivers or to Maps.
| strongpigeon wrote:
| In case any Flutter engineer/PM is watching this thread, any
| update on when the Material 3 components will be released?
|
| I have an iOS Flutter app that's getting pretty popular in its
| niche, but I'm waiting on the Material 3 components to be there
| to release an Android version.
| [deleted]
| mhoad wrote:
| That was part of the release today I believe.
| sfshaza wrote:
| This works for me: https://docs.flutter.dev/development/packages-
| and-plugins/ha...
| scrame wrote:
| croes wrote:
| https://en.m.wikipedia.org/wiki/Flutter_(software)
| mike10921 wrote:
| Cross-platform mobile dev language that uses native widgets as
| opposed to react-native that uses a wrapper around JS.
| Klonoar wrote:
| Errr... hang on there. Last I checked Flutter draws their own
| controls, they're no different than React Native in this
| context.
| dabeeeenster wrote:
| React native controls are native to the mobile platform
| they are running on.
| Klonoar wrote:
| IIRC this doesn't hold true for everything - e.g, List
| View types aren't backed by a UITableView or
| UICollectionView, so they're subtly different.
|
| Otherwise, yeah, I think you're right. It's been a bit
| since I dug around in RN internals.
| potatoman22 wrote:
| Platform-agnostic applications built with Dart. Kinda like
| Xarmin
| sfshaza wrote:
| Where is that bad link? I'll fix it.
| sfshaza wrote:
| The link is fixed. Thanks
| lazypenguin wrote:
| I have an irrational annoyance when projects claim to support
| "desktop UI" but then only have the most trivial of widgets
| commonly used in desktop applications. Where is my tree view?
| Data grid view? Charts? Native file dialog window?
|
| From my perspective, while I'm sure Flutter is wonderful, it fits
| squarely in the "mobile" UI toolkit and "basic" desktop
| application category.
| liquidise wrote:
| With limited resources you have to choose. If flutter focused
| on UI elements before Mac OS + Linux stability, the top comment
| would be "Flutter is a solid option for Windows but without
| Linux or Mac support it is useless."
|
| The flutter team has proven generally capable of developing UI
| elements on mobile across iOS/Android. Getting platform
| stability is a welcome step and i trust them to continue to
| build out the desktop element set.
|
| Flutter has been my go-to for mobile app dev for years and i
| haven't considered returning to react native, pure native or
| cordova since i swapped.
|
| All that being said, i have spent my afternoon debugging an
| issue with Flutter's first-party camera plugin, so it isn't all
| roses.
| kitsunesoba wrote:
| This is a big gripe I have with WinUI. How on earth do you
| create a desktop UI framework that lacks something as basic as
| a tableview/data grid... it's only slightly less bad than a UI
| framework not having a button widget. One should not need to
| import a third party dependency or write your own for something
| so basic.
| gman83 wrote:
| Well I think all of these widgets are available on pub.dev. For
| example, I'm using the charts_flutter plugin:
| https://google.github.io/charts/flutter/gallery.html
| cbracken wrote:
| Hey there! I work on Flutter for desktop. I'm happy to provide
| a little background.
|
| We made a decision early on to focus where those of us who work
| on Flutter could deliver the most value, and for Desktop that
| meant getting the runtimes and platform integration for each of
| the desktop OSes in good shape (international text input,
| accessibility support, rendering performance, etc.) as well as
| core integrations like the menu bar, file chooser dialogs, etc.
| These are things that need to land in the runtime itself and
| are significantly more painful for the community to contribute,
| or author and publish on pub.dev.
|
| We're working on filling in the gaps for widgets that are part
| of the Material spec, and I expect the community to make and
| publish widgets on pub.dev that continue to surprise me; I'm
| blown away time and time again at the beautiful widgets and the
| community continues to produce either in packages or as pull
| requests. You should be able to find community-authored
| packages for treeview, datagrid, and charting on pub.dev today
| in the meantime.
| pavlov wrote:
| I'd love to see a "Back to the Future" desktop UI toolkit that
| has roughly the capabilities of AppKit circa 2003 but in a
| modern language, clean unified API, cross-platform, with
| seamless native UI integration, and of course not carrying
| hundreds of megabytes of Chromium gunk in each app like
| Electron does.
| kitsunesoba wrote:
| That would be wonderful. AppKit is the closest to perfect
| I've found in desktop UI frameworks. If it took some of the
| improvements found in UIKit and was cross platform I'd never
| use anything else.
| SemanticStrengh wrote:
| not carrying hundreds of megabytes of Chromium gunk in each
| app like Electron does. this problem has been solved multiple
| times, see e.g. Tauri
| [deleted]
| nickstinemates wrote:
| who builds desktop applications anymore? it feels weird to say
| but i am starting to like them again after transitioning to
| basically 100% thin client/cloud services for the past 15
| years.
| danans wrote:
| What qualifies as a "desktop application" these days?
|
| Is it any application designed primarily to work on a laptop
| or desktop form factor? A web application like SketchUp would
| qualify.
|
| Is it an application whose code is only stored locally, even
| if they don't work well with a laptop/desktop form factor?
| Any number of native mobile apps would qualify.
|
| What about a PWA that is cached locally but initially loaded
| via a URL?
| bowsamic wrote:
| I'm confused, do you not use desktop apps?
| TillE wrote:
| How many _new_ desktop apps do you use (first released in
| the past ~5 years or so), and how many of them aren 't
| Electron?
|
| Desktop GUI software is a pretty small niche. The web has
| eaten nearly everything, and games don't use native UI
| stuff.
| SemanticStrengh wrote:
| yes, the only market for new apps would be CLI, games and
| scientific computing/technical niches
| edko wrote:
| I think a tree view was promised (listed on a presentation)
| when Flutter 2.0 was released, but no details were provided,
| and I haven't heard of it ever since.
| cbracken wrote:
| You might be thinking of this package, authored by Google,
| mostly by people on the Flutter team but it's not an official
| Flutter project (as far as I know):
| https://pub.dev/packages/flutter_simple_treeview
|
| (Disclaimer: I work on the Flutter team.)
| Austin_Conlon wrote:
| Even Apple's own declarative SwiftUI framework looks like it
| trails far behind covering rich, comprehensive AppKit apps: htt
| ps://developer.apple.com/documentation/swiftui/building_a....
| rahkiin wrote:
| You can integrate appkit components into a swiftui app
| though.
| the_duke wrote:
| Despite many maturity issues in practice Flutter is the only
| realistic option for true cross platform UIs that run everywhere.
| Apart from Qt , but the licensing issue is a hindrance. And yes,
| the web backend isn't ideal, but it will improve over time.
|
| I just wish Google had built Flutter on a low level core that
| isn't tied to Dart, so it would be usable from other languages.
|
| Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript, and I don't
| really enjoy using it.
|
| The only reason to use Dart is Flutter, which really hurts
| ecosystem health / library availability and prevents code sharing
| with the backend.
| LocalPCGuy wrote:
| I still maintain that Flutter Web is not production ready. It
| could have a nice niche, like games. But for real apps, it's
| just not as good as web. They are still re-implementing things
| that have existed in the web for ages, and are not going to be
| able to keep up. It's basically good for an applet style usage
| IMO. I'll keep trying it out, I think Flutter is pretty great
| for mobile, even desktop, but every time I use a web app
| example I find issues and just shake my head at what they did.
| mekkkkkk wrote:
| The way it atleast used to be framed is that web is a
| fallback target. Meaning if the target device isn't running
| Linux, Windows, macOS, iOS or Android (unlikely), then hey,
| you can atleast build a _passable_ version that will run in a
| browser.
|
| I don't know if this has changed, but I know only a mad man
| would try to build a proper website in Flutter. It's not the
| tool for the job.
| LocalPCGuy wrote:
| No, it is 100% being framed as "You can build your app once
| and deploy it everywhere" with everywhere including web.
| It's sorta maddening, IMO. There are certain types of apps
| I could see using Flutter for (basically, ones that would
| lean heavily on canvas anyways, games, drawing, etc.)
| mekkkkkk wrote:
| It's hard to quantify exactly what "everywhere" means,
| but for the vast majority of end-user devices, you'll
| have a more efficient Flutter build target than web.
|
| You're probably right in that they are pushing the "first
| class web target" narrative a bit far, though.
| mhoad wrote:
| FWIW I kind of agree and I'm a big fan of both Flutter and
| the web in general.
|
| There are a couple of web platform technologies that I think
| are going to take Flutter web from ok to great in the next
| year or two including.
|
| WASM Garbage Collection is going to allow them to move from
| compiling to JS to WASM. They have already built a WASM
| compiler ready to go when it lands.
|
| WebGPU is another obvious one. Flutter is by definition a
| canvas optimised framework rather than strictly DOM based
| (although they support that too as a target). But they should
| be able to get blazing fast canvas rendering with those two
| technologies alone.
|
| The other big one that I think will help them is going to be
| AOM. Lots of the built in browser accessibility stuff was
| built for a DOM based world, the web platform needs better
| primitives to support canvas frameworks too.
| SemanticStrengh wrote:
| > Flutter is by definition a canvas optimised framework Not
| really, flutter has not the resources to develop their own
| 2D renderer so they use the chromium renderer for drawing.
| (Skia). It is canvas-like, everything is canvas-like at low
| level. But flutter like browsers implement retained mode
| rendering which is necessary for being jank free and have
| low energy consumption. Flutter on web canvas cannot
| properly do retained mode rendering.
|
| spoiler, flutter non-web is generally slower than Ionic
| LocalPCGuy wrote:
| Yah, this is a pretty solid list of things that, if they
| all hit and work as we hope they do, it could enable
| building things with tech like Flutter and having it work
| well. I think that's why I generally say FlutterWeb isn't
| production ready and not that it'll never be. I don't care
| for the path they took originally, it feels like a bandaid
| and has a lot of issues. They may get there eventually, and
| I'll be happy to adjust my position when/if they do.
| jonahx wrote:
| > Despite many maturity issues in practice Flutter is the only
| realistic option for true cross platform UIs that run
| everywhere.
|
| What are your thoughts on flutter vs react native?
|
| (assuming you're only targeting phones)
| mhoad wrote:
| One anecdote that I find compelling here is looking at how
| each of the parent companies think of them.
|
| The majority of Google's revenue is directly tied to their
| Ads platform.
|
| Their mobile app is written in Flutter and the web interface
| is written in Dart (not flutter as flutter web support is
| like around a year old).
|
| Facebook uses React on the web and abandoned react native on
| mobile.
|
| Both are responsible for billions of dollars but only one
| passed the test.
| hunterb123 wrote:
| > Facebook uses React on the web and abandoned react native
| on mobile.
|
| That's not true, FB very much still uses RN on mobile.
| mhoad wrote:
| The Facebook app is not written in React Native. They
| tried it and famously abandoned it no?
| hunterb123 wrote:
| Not GP but my comparison is here:
|
| https://news.ycombinator.com/item?id=31346887
| criddell wrote:
| > Flutter is the only realistic option for true cross platform
| UIs that run everywhere.
|
| Do you really want cross platform _everywhere_? You might want
| it but what you inevitably get is something that is huge and
| just okay everywhere instead of something truly great anywhere.
| Is that a trade off you are happy with as a user?
|
| That said, I do happily use a couple of cross platform
| applications. PyCharm and SublimeText which are great and
| Fusion 360 which is powerful but awful to use.
| SergeAx wrote:
| We really want cross platform on Android and iOS. Windows and
| MacOS are nice to have, why not?
| mattsolle wrote:
| I thought I would hate Dart since it seems like such a bland
| language but after working in it for a year and a half its
| easily one of my favorites. Its straightforward and tailored
| directly for Flutter's use-cases. It feels like it doesn't come
| with a lot of the baggage you get with other, longer-lived
| languages. It is also incredibly readable without hiding how it
| works behind decades of syntactic sugar. All that to say, I
| definitely see how it can be disliked and I also disliked it
| when I started working with it but it definitely grew on me.
| KronisLV wrote:
| > It feels like it doesn't come with a lot of the baggage you
| get with other, longer-lived languages.
|
| Doesn't this mean that you are currently simply in the sweet
| spot where the language is usable but also not bloated yet?
| As in, it could all change in a decade and therefore isn't an
| intrinsic quality of the language itself, but merely the
| passage of time.
|
| I recall this blog post exploring the possible correlation
| between the age of any programming language and the
| developers' disposition towards it:
| https://earthly.dev/blog/brown-green-language/
| mhoad wrote:
| This might not be obvious in anyway if you're not pretty
| deep in the Dart ecosystem but I've never seen anyone pay
| as much attention about building a good long term language
| as that team.
|
| They put crazy amounts of thought and effort into how they
| evolve it.
|
| Their entire strategy as far as I know was to intentionally
| aim for "boring and predictable" so that no matter how
| large or complicated your application got that you would
| never outgrow it.
|
| Then they built a bunch of really nice tooling and DX on
| top of it.
|
| It's genuinely a pleasure to work with in my experience.
| clumsysmurf wrote:
| I was enjoying the frog book (The Dart Programming Language,
| Gilad Bracha & Erik Meiker) but that was 2015, and now very
| out of date. Its strange to see there is no up to date book
| from major publisher, like the Rust book at https://doc.rust-
| lang.org/book/
| jackosdev wrote:
| I've had to bounce around from Mac, Windows and Linux for work,
| the main programs I use everyday are all Electron based
| (Postman, VS Code, Spotify etc), they all behave basically the
| same just everything is slower in Windows on my laptop. Egui
| (immediate mode GUI) and Tauri (like Electron but Rust backend)
| have worked well cross platform just messing around with them,
| but I haven't used any big apps yet to know for sure.
| folkhack wrote:
| > Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript, and I don't
| enjoy using it.
|
| All anecdotal:
|
| I've only met one person who was excited to work with Dart,
| huge Google fanatic/fanboy. Otherwise it's sorta seen as a
| unique language choice that makes other devs go, "oh..."
|
| The Java/ECMA ergonomics are weird, it's hard to find devs who
| have experience with the lang, and due to the language
| popularity there's a lot less community/3rd party deps
| available.
|
| I really tried hard to give it a fair shake back in the day but
| I just ended up sticking with Node (and now +Deno), Typescript,
| or Go if I need performance/types. There are way better
| ecosystems around these and I find the tooling/ergonomics much
| less awkward. Also, if/when I need to hire devs onto my teams I
| will have a _much_ easier time.
|
| Also, I can actually write a serverless function in these tools
| (GCP Functions, AWS Lambda) - as far as I know there's nothing
| like this available for Dart.
|
| ---
|
| EDIT: It's worth mentioning I've only had Dart jammed down my
| throat on the backend (API's, data transforms, jobservers,
| etc). It may be a fine tool in regards with Flutter, but it
| felt like a _really_ awkward tool for where it 's come up in my
| career.
| mhoad wrote:
| Here's one from Google
| https://pub.dev/packages/functions_framework
| folkhack wrote:
| > Google Cloud Functions does not currently provide an
| officially supported Dart language runtime, but we're
| working to make running on Google Cloud Run as seamless and
| symmetric an experience as possible for your Dart Functions
| Framework projects.
|
| It's not natively supported - runs on Google Cloud Run
| instead.
| sofixa wrote:
| IIRC you can transpile Dart to JavaScript, so technically you
| _can_ deploy it as serverless functions.
| JyB wrote:
| I may be missing something, but why would you want to build a
| serverless function in Dart? you want a common
| backend/frontend language?
| folkhack wrote:
| I don't.
|
| It is one of my arguments against devs trying to bring Dart
| into solutions. Historically, I have had colleagues push to
| use Dart for backend/cloud/automation work which I
| personally disagree with.
| ClumsyPilot wrote:
| > Dart isn't horrible and is getting better, but it is still a
| somewhat awkward mish mash of Java and JavaScript
|
| Sounds like they should have used TypeScript?
| michaelbrave wrote:
| I was thinking MAUI(rebranded Xamarin) might be somewhat useful
| with .NET6 coming out. I've been playing with it the last week
| or so, it's quite nice.
| mhoad wrote:
| For what it's worth Dart is hands down the nicest OOP language
| I've ever used in my opinion.
|
| It's like they took all the good things about JS and Java and
| cut out all the bad parts. What's left is basically Dart.
| SemanticStrengh wrote:
| People being pleased with Dart is only because they have not
| tasted better, everything is relative. Kotlin is miles ahead.
| Mertax wrote:
| I think the decision of which cross platform technology to
| use mostly depends on a team's preferred tech stack.
|
| C++ -> QT
|
| C#/.NET -> MAUI/Blazor
|
| JS/Web -> React.Native/Electron
|
| Dart -> Flutter
|
| This is what I think is holding back Flutter -- that it
| wasn't built on an incumbent technology. Because Dart doesn't
| have quite the following, it has to evangelize itself a bit
| more than the other options.
| SemanticStrengh wrote:
| note that many languages credibly interop with JS/TS
| nowadays
| ttcbj wrote:
| I have been developing in Flutter for a few years now, and I
| really enjoy the ecosystem. It is the only mobile development
| environment I have every really enjoyed using.
|
| When I started, flutter worked on mobile, and web support was
| in beta. Now, my app works on iOS/Android/MacOs/Web. If you are
| a small developer with limited resources for cross-platform
| development, its an amazing environment.
|
| As for Dart, it is actually one of the things I like most about
| flutter. I really like the parameter passing/naming syntax. It
| is flexible and expressive. If you are looking for something
| that will challenge all your basic assumptions about what a
| language should be, you'll be disappointed. But if you come
| from any c-syntax background, you will pick it up almost
| instantly, and find a lot of nice ways to make code more
| concise and maintainable that previous languages.
|
| In my experience, Flutter is a great environment for getting
| things done with limited resources.
| curuinor wrote:
| they got clojuredart now, which is still kind of a fly-by-night
| thing but those Roam Research peeps are apparently using it in
| production
|
| https://github.com/Tensegritics/ClojureDart
|
| (and in turn, clojure itself is a highly opinionated thing
| which isn't gonna turn into a blub that everyone uses...)
| samwillis wrote:
| > Flutter is the only realistic option for true cross platform
| UIs that run everywhere.
|
| I understand that argument but 100% disagree. The _web_ is
| _the_ cross platform that runs everywhere (as in in a browser
| or webview). True it has many issues and some forms of it
| (electron) are not ideal for some use case but I believe it's a
| better platform than flutter in almost every way.
|
| You say "true" cross platform and could argue that the web
| isn't "true" cross platform. But really is anything?
| [deleted]
| mekkkkkk wrote:
| I have yet to see a world in which local file access,
| background services, local notifications, timers, alarms,
| native media controls, etc, works as well on web as in native
| apps. A lot of it is there "in theory", but web tech has the
| achilles heel of only allowing stuff that would be safe to
| have in a random website that some asshat links you on
| twitter.
|
| Of course this is only relevant if that deeper plumbing into
| the OS is needed, and of course it's quickly changing.
| Perhaps the day comes when web apps can truly be first class
| citizens in all major OSes, but it ain't here yet.
| SemanticStrengh wrote:
| You have yet to see a world where people update their
| beliefs more than once per decades. Hybrid native web apps
| are trivial, see e.g. Ionic capacitor plugins
| LocalPCGuy wrote:
| This 100%. Also, Flutter Web is still pretty much an
| abomination (right now), IMO. Sure, it "works". So did Flash.
| (edit: Just wanted to add, I love Flutter for mobile, even
| think desktop might work. Just don't think it's for web.
| Maybe for very specific app types.)
| hunterb123 wrote:
| I disagree, Flutter is probably the worst choice. React Native
| is the all around best choice for targeting all platforms
| natively, otherwise use pure web tech (Ionic + Electron)
|
| The desktop and web targets for Flutter are laughable in their
| current state. Completely unusable so I consider Flutter to be
| a mobile only platform at this time.
|
| Another downside is Flutter's emulated UI, it doesn't bridge to
| native controls like React Native, it's noticeable on iOS
| especially and will be hard to maintain the fake physics /
| styling.
|
| React Native is ready for production now for all platforms,
| including Windows & Xbox via react-native-windows, Web via
| react-native-web, MacOS via react-native-macos or Catalyst.
|
| Then there's the question as to why would you choose a Google
| only language and framework with their track record.
|
| With React you can use TypeScript or JS, you don't have to
| learn a new language or get locked into a framework.
| amelius wrote:
| > I just wish Google had built Flutter on a low level core that
| isn't tied to Dart, so it would be usable from other languages.
|
| Any chance that someone will build a transpiler from e.g. Go or
| even Rust to Dart? Or is Dart too exotic to be used like that
| in a practical way?
| skybrian wrote:
| Flutter and Dart have co-evolved to the extent that
| separating them would be difficult.
|
| One problem would be expressing the Flutter API as a Go API.
| For example, Flutter has lots of constructors with lots of
| keyword arguments. Flutter is doing things with keyword
| arguments that would be expressed as props in a React-style
| UI. A similar thing happened with JavaScript and JSX - while
| you _can_ write a React-style UI without JSX, you probably
| wouldn 't want to.
|
| Maybe you could define props using structs in Go, but the
| result would be awkward, particularly because Go doesn't have
| an easy way to bulk-copy fields from one struct to another,
| like you do with spread arguments in JavaScript.
|
| Also consider that Flutter uses class hierarchies extensively
| and Go doesn't have inheritance.
|
| Maybe look at how web development is done in Go when it's
| compiled to WebAssembly. Is that how you'd want to do web
| dev?
| eweise wrote:
| I don't know the history, but wouldn't Kotlin be a saner
| approach? Better language and at least native to android.
| SemanticStrengh wrote:
| nowadays you can do web programming in KotlinTS
| fmakunbound wrote:
| > I just wish Google had built Flutter on a low level core that
| isn't tied to Dart
|
| Why did they tie Flutter to Dart anyway?
| mhoad wrote:
| Take a look at this video from the team that talks about this
| exact topic. After watching it initially it became very
| obvious to me why and I agree it was the right choice
| https://youtu.be/J5DQRPRBiFI
| sph wrote:
| I keep hearing this, but none of the cross platform apps I run
| use Flutter. It's all Electron and Qt.
|
| I don't think I've ever seen Flutter in the wild.
| brundolf wrote:
| Or have you, and you just couldn't tell?
|
| (I personally don't know if it's this good, but it's
| plausible)
| folkhack wrote:
| Not OP - but almost all of the Flutter work I've ran into
| is mobile-centric.
|
| If you're looking for cross-platform on the desktop it
| really hasn't been a popular option vs. Electron/Qt.
| qaq wrote:
| Given that "Today, we are excited to announce that
| Flutter is now stable for macOS and Linux, in addition to
| Windows!" thats not surprising
| folkhack wrote:
| Of course, and to be clear I'm excited there are more
| cross-platform options even though I've had a reluctant
| history with Dart.
| brundolf wrote:
| I read "I don't think I've ever seen Flutter in the wild"
| to include mobile, but maybe I misinterpreted
| skybrian wrote:
| They just launched cross-platform desktop support today. Who
| would be using it for desktop apps like Electron?
| sarmasamosarma wrote:
| SemanticStrengh wrote:
| > is the only realistic option for true cross platform UIs that
| run everywhere
|
| wtf.. Ionic/electron is the true cross platform, no debate.
| Flutter web is dog shit.
| danielvaughn wrote:
| Ionic is pretty awful too, though I can't fault them. It's
| just that papering a web interface on top of a native app is
| gonna be a poor experience no matter what.
| ipnon wrote:
| I was hoping to see better HTML rendering. Using a single canvas
| to render web apps was my one turn off. Flutter is the right
| choice for many apps, but not for apps primarily accessed over
| the Web.
| LocalPCGuy wrote:
| It is not production ready for web and I don't have much hope
| it ever will be. I love it for mobile, even desktop apps. But I
| feel they chose the wrong direction at the beginning for web
| and it's just trying to dig back out of that hole since then.
| potatoman22 wrote:
| IMO it's most useful for more compute intensive web apps like
| an image editor.
| simulate-me wrote:
| What's wrong with using a single canvas? It can be faster.
| Google Docs and Figma, for example, use canvas rendering
| slibhb wrote:
| I just checked and Google Docs is not a single canvas. It
| uses a canvas for the text but all the tools and so on are
| good old html.
| SemanticStrengh wrote:
| no canvas are slower for UIs. The difference is between
| immediate vs retained mode rendering, and the later is order
| of magnitude more energy efficiency and is more performant,
| for well behaving not chaotically changing content.
| dmitriid wrote:
| > What's wrong with using a single canvas
|
| You can't even select and copy text. And canvas is
| inaccessible to screen readers
| the_duke wrote:
| For accessibility they create a separate DOM tree just for
| screen readers.
| steve_adams_86 wrote:
| Are there declarative and performant ways to synchronize
| a canvas with a DOM tree? Maybe the answer here is
| obvious but this seems like quite a bit of overhead, both
| for developers and the browser.
| 10000truths wrote:
| Do they need to be synchronized? I can't imagine that a
| screen reader would be sensitive to millisecond-level
| discrepancies between canvas updates and DOM updates.
| steve_adams_86 wrote:
| I'm not concerned about the delay between updates, it's
| the correctness of the DOM and the canvas and managing
| interactions between the two. I might be misunderstanding
| the problem (or lack thereof) because I haven't dealt
| with accessibility and canvas.
|
| When it comes down to it, I have no idea how you'd
| indicate something is selected in the canvas and have a
| screen reader correctly read out the current selection
| from the DOM. Would DOM events communicate to the canvas
| how to modify state, functions to call, etc?
|
| How would you manage focus between the canvas element and
| the rest of the DOM? Apologies if I'm not making sense;
| maybe there's a well known pattern people use for things
| like this.
|
| My understanding of accessibility relies heavily on the
| DOM behaving as a single document, and the idea of a sort
| of meta-document within it which coordinates pieces of
| the documents seems very complex and hard to get right.
| LocalPCGuy wrote:
| This right here should tell you why you shouldn't use
| Flutter for Web. The Web is pretty great for
| accessibility out of the box until us devs mess it up, we
| shouldn't use a technology that needs to completely build
| it from scratch to get it to work.
| gitgud wrote:
| Although it may render faster, it comes at a cost, as it
| completely circumvents what browsers are good at.
|
| Flutter is basically just painting pixels on a canvas
| manually, meaning no CSS, no text selection, no text
| wrapping, no responsive elements, no elements without JS
| enabled. Many accessibility tools rely on CSS and text in
| HTML in order to work too.
|
| It's a huge trade-off to make, and something to be aware of.
| LocalPCGuy wrote:
| Heavy emphasis on HUGE tradeoff. Too much for most web
| apps, IMO.
| kolanos wrote:
| Both are pretty disastrous accessibility-wise.
| strix_varius wrote:
| Both Google docs and figma _use_ canvases, but neither of
| them renders the whole app through a canvas.
|
| This is easy to verify - just open up dev tools and look at
| the DOM structure.
| mleonhard wrote:
| Google Flutter Team: You launched Flutter Desktop and got your
| promotions. Now can you please go back and finish Flutter Mobile?
| Specifically, please add:
|
| - Integration testing [0, 1]
|
| - Location [2]
|
| - iOS dark mode [3, 4]
|
| - iOS keyboard dismiss decoration [5]
|
| - iOS keyboard scroll-to-dismiss mode [6]
|
| - iOS NavigationLink widget [7]
|
| - iOS checkbox widget [7]
|
| - Android camera that doesn't randomly crash (unfixed for 3
| years) [8]
|
| - Android date-time picker (Requested in email to Flutter Team.
| They refused.)
|
| - Usable documentation for Navigator 2.0 [9, 10]
|
| - Debugger visibility into Dart async tasks
|
| - Stop HTTP requests on timeout [11]
|
| - Testing on physical devices for apps that use flavors [12]
|
| - UI inspection tools that don't randomly stop working
|
| EDIT: Added bug links.
|
| [0] https://github.com/flutter/flutter/issues/88549
|
| [1]
| https://github.com/flutter/flutter/issues?q=is%3Aissue+comme...
|
| [2] https://github.com/flutter/flutter/issues/31453
|
| [3] https://github.com/flutter/flutter/issues/48438
|
| [4] https://github.com/flutter/flutter/issues/80860
|
| [5] https://github.com/flutter/flutter/issues/45076
|
| [6] https://github.com/flutter/flutter/issues/57609
|
| [7] https://docs.flutter.dev/development/ui/widgets/cupertino
|
| [8] https://github.com/flutter/flutter/issues/70751
|
| [9] https://github.com/flutter/flutter/issues/69315
|
| [10] https://github.com/flutter/flutter/issues/81610
|
| [11] https://github.com/dart-lang/http/issues/424
|
| [12] https://github.com/flutter/flutter/issues/99607
| [deleted]
| [deleted]
| throwawaycuriou wrote:
| How not to get what you want
| mleonhard wrote:
| The only way I will get what I need from Flutter Team is if
| Sundar fixes the company's incentive structure to align
| employee incentives with long-term profitability. I do not
| expect that will happen. But if it did, I would probably
| immediately go back to work at Google.
| mattsolle wrote:
| I think a lot of these comments are not necessarily valid or
| have been addressed already and we've lost the actual
| productive feedback in the mess.
|
| - Integration testing - This exists and is very commonly used:
| https://docs.flutter.dev/cookbook/testing/integration/introd...
|
| - Location - This 100% should be a core offering, its crazy
| that its not for mobile application.
|
| - iOS dark mode - Flutter supports Dark Mode -
| https://api.flutter.dev/flutter/material/ThemeMode.html
|
| - iOS keyboard dismiss decoration - Not sure on this.
|
| - iOS keyboard scroll-to-dismiss mode - This is trivial to
| setup, just listen on scroll and hide keyboard. You could even
| create a generic handler that can be reused everywhere for
| this.
|
| - iOS NavigationLink widget - Not familiar with this construct
| but easy to build yourself.
|
| - iOS checkbox widget - Totally agree but also easy to build
| directly.
|
| - Android camera that doesn't randomly crash (unfixed for 3
| years) - We've got a couple application that use camera and
| never had this issue.
|
| - Android date-time picker - This has been in for a long time:
| https://api.flutter.dev/flutter/material/showDatePicker.html
|
| - Usable documentation for Navigator 2.0 - I think the updated
| docs on navigation have addressed this issue largely.
|
| - Debugger visibility into Dart async tasks - You can 100%
| debug async tasks.
|
| - Stop HTTP requests on timeout - This exists in Flutter
| https://stackoverflow.com/a/51489701
|
| - Testing on physical devices for apps that use flavors - We do
| this regularly across 5 different flavors on both iOS and
| Android.
|
| - UI inspection tools that don't randomly stop working - Never
| had this happen.
| mleonhard wrote:
| Integration testing supports only running tests inside the
| device. If your test needs to start an API server, then you
| must use the deprecated and broken flutter_driver module. See
| the bug I linked.
|
| Flutter's Cupertino dark mode support is broken. Some text is
| invisible. Some widgets are unusable. Cupertino Dark mode
| theme support is completely absent. See the bug I filed, with
| a comprehensive reproduction with screenshots. It's like the
| dev who added it just decided to stop half-way.
|
| > - iOS keyboard scroll-to-dismiss mode - This is trivial to
| setup, just listen on scroll and hide keyboard. You could
| even create a generic handler that can be reused everywhere
| for this.
|
| Please use an iOS device and notice how nicely one can
| dismiss the keyboard in iMessage, FB Messenger, Instagram,
| etc. Getting that behavior in Flutter requires using a third-
| party package.
|
| The Material date picker is not a date-time picker. Letting
| the user pick a date & time requires a lot of extra code. For
| example, I spent many hours writing a widget that displays
| the date & time and lets one click to change it, like in
| Google Calendar.
|
| See the bugs I linked about Navigator. The docs have multiple
| omissions. I lost a day and a half on them.
|
| Yes, you can debug tasks with a breakpoint. You cannot see
| which async tasks are running. You cannot pause a task. I
| needed to debug concurrent RPC problems and tried using
| print. Unfortunately, print provides no visibility into tasks
| running in standard library code, like timed-out HTTP
| requests that continue running.
|
| You can timeout waiting for an HTTP request to finish, but
| the request still continues in the background. If it's a
| large upload then it can continue for minutes, draining the
| device's battery and transferring data. See the bug I linked.
|
| > - Testing on physical devices for apps that use flavors -
| We do this regularly across 5 different flavors on both iOS
| and Android.
|
| How do you install on iOS? I tried `flutter build --flavor
| staging --release` and then `flutter install` which fails
| saying that I must supply `--flavor`. But when I supply
| `--flavor` it says the parameter is not supported. See the
| bug I linked. I spent a few hours and figured out how to
| first do a Flutter build and then use XCode to build again,
| then use Devices & Simulators to manually install the
| archive. But this requires that I remove the app from the
| device first, which destroys the app state. This makes manual
| testing extra slow. The process is noxious.
|
| Flutter Inspector in Android Studio on macOS breaks 1 out of
| 5 times I try to use it. I often waste a few minutes trying
| to figure out why my code changes did not have the desired
| change on the widget tree. Then I finally realize that the
| widget tree pane is broken and I need to restart Android
| Studio. It's been like this since 2018 through multiple
| upgrades of Flutter, Android Studio, and macOS.
| onli wrote:
| Just an additional note: Integration testing was indeed
| completely broken for a while, with the docs stating
| otherwise. They reworked it a few releases ago and since then
| it works well for us (limited usage, but completely stable
| for what we do with it).
| sergiotapia wrote:
| We have a react native app and sometimes it fails to build. We go
| to lunch, and come back no code change now it builds.
|
| I'm just sick of the NPM/Javascript bullshit.
|
| Does Flutter avoid all of these kinds of issues? I'm this close
| to scrapping the whole thing.
| mattsolle wrote:
| I worked with React Native for 3 years before jumping over to
| Flutter and this was the biggest reason why I made the switch.
| Its exponentially better on Flutter. The only time builds break
| for the team are when we made a code change that broke it. Its
| consistent and non-flaky (looking at you RN). Not that you
| won't run into the occasional issue but with React Native
| easily 20% of my time developing was "this just stopped working
| and there's no reason why". React Native was configuration
| hell. With Flutter, I haven't struggled with that at all past
| the initial setup.
| JyB wrote:
| > I'm just sick of the NPM/Javascript bullshit.
|
| Amen
| mekkkkkk wrote:
| I never coded React Native, but I have a lot of experience with
| Flutter. You can definitely run into build issues, but it's
| almost exclusively when doing precarious things like upgrading
| third party packages, SDKs or Flutter versions. As soon as
| you've traversed the depths of dependency hell and it builds,
| it builds without a hitch repeatedly in my experience.
|
| As the framework is maturing there have been some major
| transitions between APIs and project structure. My main app
| that was scaffolded two years ago has had no shortage of duct
| tape fixes and tweaks to especially Gradle/Cocoapods config to
| keep it building.
|
| I guess it's a fair price for what has otherwise been a
| fantastic developer experience. All in all I'd strongly
| recommend it.
| strongpigeon wrote:
| As someone with a lot of Flutter experience, I can second
| this. It usually works pretty reliably until someday you
| upgrade and cocoapods keeps complaining even when you clean
| everything and rebuild.
| akmarinov wrote:
| No, use native if you want to avoid that
| MrDresden wrote:
| There is no framework that never has issues.
|
| Flutter has its fair share (and to be fair, so do the native
| toolchains).
| livinglist wrote:
| I have been working on a Hacker News client using Flutter, if
| anyone is interested:
|
| https://github.com/Livinglist/Hacki
| mnorris wrote:
| Thanks for sharing! The design looks really slick.
|
| As a hobbyist Flutter developer who hasn't figured out how to
| make Flutter apps look remotely appealing yet, it's been cool
| poking around your code and trying to learn from it. Bloc and
| Cubit look especially interesting.
| tomatowurst wrote:
| so...anybody using it to build web apps in lieu of react?
| msoad wrote:
| What are big and highly used apps that use Flutter?
| mhoad wrote:
| Google Ads uses it on mobile which is responsible for literally
| billions in revenue.
| mattsolle wrote:
| They have a showcase page that details large brands that use
| Flutter: https://flutter.dev/showcase There's also there own
| website: https://itsallwidgets.com/
| strongpigeon wrote:
| My app [0] isn't big, but it's highly rated and uses Flutter
|
| [0] https://apps.apple.com/us/app/five-three-one/id1560266240
| justinmc wrote:
| Do you have an Android version?
| LocalPCGuy wrote:
| Doesn't appear to based on the website, which is just sad
| considering it's almost zero effort to create an Android
| build as well. I'd consider using this app also.
| hermanb wrote:
| Philips Hue is fully Flutter since a while now (v4). There were
| issues with (pre-rendering of) animations but those have been
| resolved in Flutter.
| discreteevent wrote:
| Canonical have specified it as the default development tool for
| their apps (e.g. the Ubuntu installer)
| davidkuennen wrote:
| My app[1] has 5 figure daily users (if that's considered
| somewhat big) and is written in Flutter.
|
| I love Flutter. It made all this so much easier.
|
| [1] https://stockevents.app
| trey-jones wrote:
| Google Home is the first thing that comes to mind.
|
| See here: https://flutter.dev/showcase
| msoad wrote:
| From all those apps Google Home is the only I had to use for
| my Google Wifi router and it crashed a bunch of times!
| trey-jones wrote:
| It's very spotty connecting to my Chromecast as well, but
| the UI is cool!
| strix_varius wrote:
| Google home is my most-hated mobile app. It's slow, janky,
| buggy, and has terrible UX.
| kringo wrote:
| I still can't find, in the docs, there is an open bug/feature
| request to NATIVELY copy/paste from web?
|
| Do they support copy / paste on the web app without using a
| special widget?
| justinmc wrote:
| I'm not aware of any planned/possible way to do copy exactly as
| you would an HTML page with HTML tags, but there's a big
| project to make selection and copying much simpler and more
| powerful (design doc [1], in progress PR[2]).
|
| With that PR it should be easy to just add one SelectionArea to
| the root of your app in order to make everything selectable,
| like it would be on a web page. You don't need SelectableText
| widgets. There's an example of this in the PR [3]. No built-in
| support for multimedia or rich text copying yet though.
|
| Text input fields should already do copy/paste pretty much the
| same as native.
|
| [1] http://flutter.dev/go/global-selection [2]
| https://github.com/flutter/flutter/pull/95226 [3]
| https://github.com/flutter/flutter/pull/95226/files#diff-a90...
| brabel wrote:
| Flutter 3 comes with an upgrade to Dart 2.17 [1], which has quite
| a few improvements as well... including state on enums.
|
| While that's great, I was hoping it would be like in Rust, where
| each enum variant can declare its own state components, but
| unfortunately it seems to be more like Java: same state for all
| variants.
|
| Well, at least there's quite a few other small but useful
| improvements... and they showed how they really listen to the
| community by implementing the new syntax for passing on
| constructor parameters to a super-class... and by improving the
| docs of the 200 most popular packages with lots of examples, as
| requested by the people.
|
| I like how they're listening to the community as well to
| implement meta-programming (like macros) [2] to solve the main
| pain point, currently, in Dart, which is how verbose it is to
| generate code for things like serialization and data types.
|
| Once they get that, Dart will be a really good language to work
| on (it's already quite ok IMO, despite most people, usually those
| who don't actually use it much, hating on it).
|
| [1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d
|
| [2] https://github.com/dart-lang/language/issues/1482
| kaba0 wrote:
| > While that's great, I was hoping it would be like in Rust,
| where each enum variant can declare its own state components,
| but unfortunately it seems to be more like Java: same state for
| all variants.
|
| As much as I like Rust's enums, I think they messed up on the
| naming. Java (and according to your comment, Dart) gets enum
| rights. What Rust has under this name is sum types, which is a
| separate (more expressive) concept and the two only correspond
| with each other in the case of a sum type where each component
| is of a zero-arity type.
| the_duke wrote:
| There is no real reason to have basic enums if you have ADTs
| , since those can easily provide everything a plain enum
| gives you.
|
| I guess the name was just a historical artifact.
| SemanticStrengh wrote:
| no the feature you're looking for is sealed classes, see
| e.g. Kotlin. Rust enum variants cannot be externally
| defined classes
| the_duke wrote:
| That's completely orthogonal to ADT vs enum.
| SemanticStrengh wrote:
| Enums enable two things: check current type from union of
| types and exhaustivity check in switch
|
| The former is solved by reflection, the latter by sealed
| classes.
| kaba0 wrote:
| I agree (that's what I meant under the more expressive
| part), though it is a bit more complex with identity in the
| way. Java's enums are also the singleton pattern.
|
| Java recently got ADTs as well in the form of sealed
| classes and records, here an enum would look like this:
| sealed interface Color permits Red, Blue, Green {
|
| } record Red() {} record Blue() {}
| record Green() {}
|
| You can now create as many Red instance as you want, they
| will be "equals" only under equals(), not under ==, while
| the latter is also true for the enum case.
| munificent wrote:
| _> While that 's great, I was hoping it would be like in Rust,
| where each enum variant can declare its own state components,
| but unfortunately it seems to be more like Java: same state for
| all variants._
|
| Yes, the enhanced enums we shipped in 2.17 are like Java enums.
|
| We are also working on support for pattern matching and
| algebraic datatype-style programming: https://github.com/dart-
| lang/language/blob/master/working/05...
|
| I say "style" here because object-oriented languages like Dart
| can already mostly model sum types using subclasses. What you
| need to get the rest of the way there is basically just:
|
| 1. Sealed types so that the compiler can check for
| exhaustiveness when you match over all of the subclasses.
|
| 2. A nice pattern matching syntax to let you discriminate
| between the subclasses and destructure them.
|
| 3. Ideally, a nice lightweight syntax for defining a sum type
| family as a superclass and set of subclasses, though this is
| relatively less critical.
|
| We're hard at work on this, but pattern matching in general is
| a pretty large feature and retrofitting it into a language
| whose syntax wasn't initially designed around it is a
| challenge.
|
| I'm very excited about macros too. That's another large,
| difficult feature, but one that I hope will provide a _lot_ of
| power to users and make the entire ecosystem more valuable over
| time.
| obert wrote:
| Happy paths not found...
| https://docs.flutter.dev/development/platforms-and-plugins/h...
| sfshaza wrote:
| Fixed! Thanks
|
| It's: https://docs.flutter.dev/development/packages-and-
| plugins/ha...
| ushakov wrote:
| did they fix the scrolling on iOS?
| scarface74 wrote:
| Yet another reason to avoid cross platform frameworks. They are
| always catching up to the vendor's capabilities.
| discreteevent wrote:
| That is a reason to avoid cross platform frameworks. But
| there are big reasons in favour of using then as well. It's a
| trade-off depending on your use case.
| LocalPCGuy wrote:
| For the vast majority of (mobile) apps, the benefit of being
| able to be built from a single code base outweighs being
| slightly behind vendor capabilities. Particularly things like
| there where it doesn't come up in some apps and relatively
| few people actually notice/care about it in those it does.
| akmarinov wrote:
| Not yet, but they have a beta thing that you can enable to
| smooth that out
|
| > Impeller precompiles a smaller, simpler set of shaders at
| engine build time so that they won't compile while an app is
| running; this has been a major source of jank in Flutter.
| SemanticStrengh wrote:
| if they disable the shader jit it will result in much worse
| performance overall
| karlmdavis wrote:
| From their What's New: " Flutter now supports variable refresh
| rate on iOS devices with ProMotion displays, including iPhone
| 13 Pro and iPad Pro. On these devices, Flutter apps can render
| at refresh rates reaching 120 hz, which were previously limited
| to 60 hz. This results in a smoother experience during fast
| animations such as scrolling. See flutter.dev/go/variable-
| refresh-rate for more details."
| SemanticStrengh wrote:
| can does not mean it will.
| butz wrote:
| Does Flutter have a complete Material UI components
| implementation? I'd prefer to use Flutter for multi-platform
| support over learning new Android Compose and figuring out what
| to do for other platforms later.
| vogtb wrote:
| Yes, there are two default widget packages, Cupertino and
| Material.
|
| https://docs.flutter.dev/development/ui/widgets/material
| mhoad wrote:
| It's built right into it. Both material 2 and 3.
| tylergetsay wrote:
| I'm not sure I can say it's complete but it's better than
| Android in my experience. There's also more built for you
| already, like button styles and page layouts.
| hbn wrote:
| Does anything have a complete Material components
| implementation?
|
| I always got the vibe from Material that it's just a bunch of
| designers pumping out docs for an ideal world, and then the
| various libraries try to implement a bunch of those things as
| they change faster than they can be implemented.
| trulyrandom wrote:
| Indeed. It wasn't that long ago that Material components for
| Android finally got proper support for Material 2 in a stable
| release of the library. But everything started too look too
| nice and consistent, so now we're getting steamrolled with
| Material 3.
| oldgradstudent wrote:
| Any plans to make it possible to embed Flutter in existing
| desktop applications?
|
| Especially for use in plugins to existing said that do not
| control the main event loop?
| mekkkkkk wrote:
| Congrats! Flutter is such an amazingly crazy concept that when I
| started my current job it was on the condition that I could learn
| and use it for our app. I'm not regretting it in the slightest.
| In fact I get more impressed with it the more I use it. Great
| job!
| baisq wrote:
| Does anybody know of any good Flutter for Windows applications
| that are worth looking at?
| SemanticStrengh wrote:
| and rendering benchmarks
| onphonenow wrote:
| Same question, do they have a reasonable component library on
| windows?
| redsolver wrote:
| There's https://pub.dev/packages/fluent_ui
| endisneigh wrote:
| Honestly I think browsers (desktop and mobile) will implement
| native apis faster than these things will implement native apis.
|
| TLDR: JavaScript and browser apis will win in the end.
| sarmasamosarma wrote:
| SemanticStrengh wrote:
| It's already the case, Cordova/Ionic has much more native
| plugins than react native and flutter combined!
| https://www.npmjs.com/search?q=ecosystem%3Acordova It's only a
| matter of time before people realize how superior Ionic is, and
| I can't wait for people to realize Ionic is faster and more
| energy efficient too! https://ionicframework.com/blog/ionic-vs-
| react-native-perfor...
| farmin wrote:
| I use Flutter as a way to host a sqlite and business logic and
| render all UI in a local webview for this reason. Just testing
| now, but works OK.
| 999900000999 wrote:
| On one hand, I'm excited, on the other hand, I'm using a Flutter
| app right now as essentially a utility for my own personal use.
|
| I'm horrified if I upgrade it everything will break and I'll have
| to commit to fixing it.
|
| Still, I'm very excited about this, I'd argue flutter is what
| react native wanted to be.
___________________________________________________________________
(page generated 2022-05-11 23:00 UTC)