Flutter 3
docs.flutter.dev
docs.flutter.dev
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.
I don't think I've ever seen Flutter in the wild.
(I personally don't know if it's this good, but it's plausible)
If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.
So what is this made in then? [0] Hint it is not Electron.
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.
As a developer, I personally want to make those kinds of programs too. I periodically check into the state of the cross platform toolkits and frankly they really aren’t any better than they were a decade ago.
Separating out a UI layer that is unique in each platform helps and writing with native toolkits helps, but there are still fundamental differences that you can’t really abstract away.
I think the biggest market for these toolkits is in enterprise software. There, lowering development costs seems to be more important than anything else.
There have been some bad efforts at this in the past which is maybe how you arrived at the conclusion but the concept of Flutter is pretty straightforward and not dissimilar to games in some sense where you just need to push pixels to a screen.
They even have a some game engineers who used to work at EA on the team. One even wrote a popular book on it https://gameprogrammingpatterns.com/
Like in short, Flutter is going to be fine. It compiles to native code that just needs to push pixels to a screen, it has a bunch of smart people on it and some extremely heavy incentives to get this right.
Of the toolkits I’ve looked into (which admittedly are mostly on the desktop), Qt is probably the best on that front.
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/
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.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
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.
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.
Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams.
Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else.
However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption.
It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions.
Where I ended up landing was basically:
===Front End===
Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures.
===Backend===
Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits:
- Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf.
- Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe.
- Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to.
It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider.
- Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway) also get's me a free JSON / REST <-> gRPC gateway for web along with a free gRPC-web <-> gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport) makes native gRPC in the browser a viable option.
- Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default.
- Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works.
- The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code.
- Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc..
- The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild).
- The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about.
- Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment.
===Wrap Up===
That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair.
Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase.
But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that.
Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.
It's not natively supported - runs on Google Cloud Run instead.
You said there were no good backend solutions for serverless functions and I’m telling you that is incorrect.
I’ve done a bunch myself, it was actually really pleasant.
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...)
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?
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?
FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct.
wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.
That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported on the web 2) most apps should not be in material design if they want to have a personality.
You said the word awful, don't you have concrete pain points?
Also: what makes a framework "native" for me is that it has it's own rendering stack. With webview solutions you are still facing cross platform inconsistencies between Safari/iOS, Android and Electron.
> what makes a framework "native" for me is that it has it's own rendering stack
lel, the point of react native is exactly that it doesn't have its own rendering stack, it defer rendering to external rendering stacks (android native lib, swift native lib) Flutter and the web are not native and are not different. They both have their own custom rendering stack, which allow them to improve it. flutter has not created its own 2d renderer btw, it uses the chromium 2D renderer named skia, in fact android native use the chromium 2D renderer since a few versions already. Simply because its the fastest to exist.
> With webview solutions you are still facing cross platform inconsistencies
crazy how reversed with reality your argument is. React native is by design inconsistent, it uses a separate library for each platform which result in an impedence mismatch of features, performance, and bugs. A webview has no inconsistencies between android and electron, it's the same chromium behind. Safari is slighly inconsistent (webkit) but order of magnitudes less than using a completely different library.
Every framework has bugs and feature requests that are fighting for resources. And the ones affecting you _always_ seem more important than the ones that don't.
That being said, the fact that memory leaks in widely used components (e.g.: `<ion-img>` [1]) go mostly unnoticed both by Ionic developers and by the community [2] just doesn't give me confidence in Ionic being a framework used to build quality apps.
[1] - https://github.com/ionic-team/ionic-framework/issues/19242#issuecomment-556182556
[2] - the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`, which seems even more serious and the developers have been made aware of itIt looks like you answered yourself, this issue does not seem to affect people. Either it is a rare intermittent or only happen in very specific configurations, either there is a leak but it is negligeable, or shortlived. OR maybe this leak cause suboptimal performance but it must not be "feelable" although you did a great find, this issue has been overlooked and its severity should be better investigated. I'd like to remind you that Ionic is not the point, Ionic is simply a packaging of good practices and optimized components (because yes ion-img implement important optimizations over a normal img tag). Some might have leaking issues but the point is that you can trivially use a standard img tag, or a regular react/angular image lazy loading library or even better https://chromestatus.com/feature/5637156160667648 The web BTW will probably be the first ecosystem to provide support for JPEG XL images, which are a significant evolution in performance. Compare the discussed underinvestigated suboptimality with e.g. this 50% CPU increase over a trivial GIF, and mostly ignored/delayed https://github.com/flutter/flutter/issues/88858 or even https://github.com/flutter/flutter/issues/94205
> Every framework has bugs and feature requests that are fighting for resources. relativism has its limits, chromium has thousands more human resources than flutter and react native devs combined
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.
You weren’t wrong historically but you aren’t right currently.
Flutter web including the canvas rendering option has proper accessibility as of today AFAIK.
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?
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.
So if your claim is simply that CSS/HTML/JS is capable of creating good user interfaces, I'm not arguing against it.
bruh it's not just UI, the JS/TS code is where the business logic code is. And anyway the UI is the whole point, we are debating UI libraries. But most importantly native plugins are niche, you use them very rarely and for very specific needs, they occupy generally less than 1-5% of the code base. e.g. when you need to access the camera or sensors, which you usually don't need and most apps don't actually benefit from plugins. I'm not even talking about the fact that most of those niche needs are generally covered by equivalent modern web APIs (e.g. web share) but since plugins are trivial to use, people often use them even when a web api already exist.
However, I believe it might not matter. 95% apps can be done as web apps today, especially what comes to boring business applications. 5% we can wait for some time.
What comes to Flutter, it can never integrate well within a browser as it sufferes from the same issue as Java applets. It does not use the web browser native rendering engine and widgets will always feel kludgy, have accessibility issues and so on. Not a big deal for some apps like games. And Google Docs is already using Canvas based rendering so seems like Flutter canvas based apps might have hope.
Well, isn’t it the Java applets model as you call it as well? But is a colored div that much better of a button?
Though I don’t disagree with you, indeed most apps can be web-based.
However given the app store is a cash cow for Apple I highly doubt they’d want to integrate web more deeply.
Local storage already does a lot of needed data storage (though apple has recently made this complicated with their auto delete after certain period). Local file access for uploads is also now possible on iOS using the Files app.
Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
I am not saying that electron-based apps are generally good or efficient. Most of them are frustratingly slow and awkward. But this inefficiency rarely seems to be constrained by local resources: the apps often stand still, consuming barely any resources (CPU time, memory, etc.) and taking ages to load each page. At the same time you can often visit the same page in Chrome and it will load almost instantly.
It is frustrating and I have no idea what is going on, but it doesn't seem like upgrading the PC would solve the issue.
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
What are your thoughts on flutter vs react native?
(assuming you're only targeting phones)
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.
That's not true, FB very much still uses RN on mobile.
The Ads Manager app is written in React Native.
The Instagram app is written in React Native.
The entire FB app is not written in React Native yet, but overtime I'd expect more things to be.
The statement that FB "abandoned react native on mobile" is demonstrably false.
Second, they serve different purposes. Litho will be used for FB scale optimization of certain intensive views. React Native is used for fast developer productivity. I'd wager that RN will be used in most places and Litho is used in hot spots sparingly.
Someone currently on the Instagram team can correct me if I'm wrong.
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.
You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
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.
spoiler, flutter non-web is generally slower than Ionic
WebGPU and WasmGC are both already implemented in most browsers and are currently just behind a flag as far as I know.
It doesn’t feel like magical thinking to me at all, it’s a pretty clear path forward IMO.
Personally, I'm not willing to be on Flutter Web right now, and as you can see, I still actively dissuade it's use as I don't think it's good for the web as it is. But that doesn't mean that in a few years I'll think differently.
Flutter is a great fit for applications which (and I say this as someone who did SEO for fortune 500s for many years) aren’t really all that relevant for SEO purposes and are difficult to index at best.
But the short answer to your question is the accessibility object model API is what gets used to surface relevant information that could be used by search engines along with all the other things that have nothing to do with the stuff that sits inside your body tags. Like it wouldn’t actually be that different IRL.
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
Would you consider Instagram or Twitter a website or a web app?
If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.
Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all.
Though surely the render codepath could use wasm, but that could be written natively as well without a need for GC.
As for WebGPU, I don’t think a web app would be okay with the latency of compiling shaders. Not sure whether it will be needed, or if it can be cached but it is not a trivial win either.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
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.
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.
> Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)
It’s clear that Flutter wasn’t for you for whatever reason and you seem to love Iconic which is great but obsessively hanging out on this thread and just trying to shit all over it at every opportunity you get without citing any evidence is weird.
Just go an enjoy Iconic. I don’t know why you keep trying to pick arguments with everyone here.
I am sick of people ignorance in GUI rendering engines and the religious myths they build over native, so I actively comment too because online GUI conversations are still on a middle age like era. If I wzs tied to Ionic I would try to please people, which I don't. In fact Ionic communication has often self victimized itself by corroborating the native rendering myth in lany of their blogs. The internet and HN indeed is a small place and seeing the Ionic CEO and one of the only person with expertise in 2D GUI renderers (me) on thr flutter 3.0 announcement is actually, not unlikely. But it surprises because on average on the internet, people don't care to push depth/accuracy into discussions.
BTW I am capable of pointing flaws in Ionic, the documentation on the web is often not up to date, and inn general I would much prefer a Kotlin based GUI framework (such as jetpack compose) over a JS framework (ionic). I am in fact the only person on HN to have an actual argument to defend a true Ionic competitor, based either on fastuidraw, piet-gpu or gecko but there's no point in discussing this given no one could contribute to the discussion.
That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
I also mentioned elsewhere in the thread how impressed I was just watching that repo in general for a year. They clearly give a shit on a such a deep level about building a solid long term language in a way that I was totally unfamiliar with say coming from a Ruby background previously.
Here is the section on pattern matching specifically https://github.com/dart-lang/language/tree/master/working/05... and this is the design spec itself https://github.com/dart-lang/language/blob/master/working/05...
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.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
I wouldn't touch it again.
You certainly don't need it though, I have no issue with my React Native stack.
Flutter has its share of similar tooling issues, most of the time its native things like CocoaPods that affect both projects.
RN has a huge amount of plugins, a lot that are very good quality. It's up to the dev to pick quality dependencies.
This is one of the underappreciated part of flutter, 4 months of upgrade take me 30min of work and the hot reload just works, good luck with that in the JS world.
Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion.
Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade issues only after a month...
> Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
You need much less native tooling in Flutter since almost everything is canvas based. Broken stuff on the native part is very rare, I can't really remember anything like this from the past 3 years. I had to upgrade the graddle version once but that's about it.
I have ~30k lines of dart excluding tests and about 15 lines of Kotlin (and zero in ios), that's the kind of ratio we're talking about.
Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
> and the fact that it's dynamic language does not help
Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.
> upgrades are often and painful
You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
> the tooling is not very stable in my opinion.
Seems stable to me since the last couple years.
Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.
The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
React you can snapshot test the component tree, as well as diff images on each platform.
> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
That's plain false, they for sure do.
> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
React Native performs well on older devices as well.
Not every ecosystem is created equal, they are better testing cultures than dart (such as ruby for example) but they are also worse ones and javascript is definitely worse at that. Packages you install will be on average less tested and less care will be put into the dev experience than in some other languages.
They are exceptions of course such as RN & React but they are far outside the norm.
> Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
As with any other JS project, RN and React are not the main issue but everything around it is and you certainly need extra packages.
> That's plain false, they for sure do.
Have a look at those apps and tell me if they look Material (they don't).
All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
There's also https://github.com/valence-native/valence-native that can use either wxWidgets or Qt.
All in all it's better than the current Flutter web / desktop implementation.
There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.
> You can wrap the React Native Web target in Tauri or Electron for Linux.
That's one of the only realistic solution for now in my opinion.
Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
> That's one of the only realistic solution for now in my opinion.
Yup, and you get it for free with if you build your app with RN and React Native Web.
Even the simplest bridge needs upgrades, unless you want to be stuck with react 16.
> Yup, and you get it for free with if you build your app with RN and React Native Web.
That's better than nothing I'd say yeah. That's kind of the issue with react native, you need platform-specific rendering code and since companies don't really care that much about linux desktop it's not really there.
They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.
It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.
Why did they tie Flutter to Dart anyway?
Sounds like they should have used TypeScript?
Qt is LGPLv3, which is really a problem only if you plan to develop embedded software.
Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)
Also, JNI requires you to use DLLs/shared objects, so you definitely can use them on Android.
from a quick grep on my hard drive, Telegram and QBittorrent statically link against Qt on Windows ; my own software also does, on all platforms. I assume there are others.
Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle.
> 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.
Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened.
Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said.
In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends.
With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
That matches my experience. Getting Qt Widgets to resize in an even remotely sane way proved to be just about impossible.
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
You should have decently qualified developers be productive within a week.
But forcing a new language on people usually doesn't go well.
Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.
A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter app was really good.
It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.
YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
And Android would have been much better off if they didn’t fork the whole ecosystem and just used OpenJDK, perhaps with an added low-memory GC.
Flutter's performance issues, on the other hand, is a separate story.
Can you expand on that? I know react native has performance issues but does Flutter have it too? Why?
Flutter draws whole ui by itself: welcome to blinking cursor that consumes 5-15% CPU in idle.
https://medium.com/swlh/flutter-vs-native-vs-react-native-ex...
Citation? Flutter draws its own UI but game engines do that too.
All code in flutter compiles down to native code.
> React native has less performance issues, since it uses native toolkit.
In theory.
https://github.com/flutter/flutter/issues/59327
This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.
Reading the bug report my takeaways were the following:
1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.
2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.
3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)
They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.
I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.
The question in my mind is whether Flutter is consistently and significantly more resource efficient than web technologies for my particular use cases.
While I understand this may be a dealbreaker issue for your use-case, we've been pretty busy getting a few higher-priority (overall) issues fixed (universal binary support, CJK text input, key event APIs, etc.) prior to 3.0, but we'll get to this.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
Depending on your needs, Livecode has you covered. https://livecode.com
Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
https://gallery.flutter.dev/#/demo/cupertino-text-field
As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI
I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed.
* emoji is not the system emoji.
* neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered)
* reconvert and other IME options don't work
just to name a few. Just please stop with the canvas rendering!
Dart is horrible and the sole reason i don't touch Flutter
I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too.
People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho.
Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
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).
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.
I guess the name was just a historical artifact.
The former is solved by reflection, the latter by sealed classes.
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() {}
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like enum Option<T> { Some(T), None }
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.
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.
It's what Scala and Kotlin do and I think it's a fairly natural mapping. (Swift takes a different approach with their enums).
> defining an entire class for each variant does not sound like fun!
If you come at it expecting the brevity of ML, yes, it's not. But if you accept that those variants are real classes and may also have their instance methods, documentation comments on the fields, etc. then the overhead starts to feel less onerous.
I think the marketing is getting ahead of the actual development of the framework. If parts are truly not stable, why call them stable, if not for wanting Flutter to be in the news cycle every so often?
I don't feel it's great, especially on older devices. Take google pay, a showcase flutter app. It's a laggy mess on an iPhone SE 2016, whereas the "old" google pay ran perfectly fine. On top of that, many google apps I use these days will just freeze and stop accepting touch inputs. I have no idea if it's all flutter, or just the weird stuff google does on mobile platforms, but other apps don't suffer from this.
I think flutter is good for a resource-scarce team trying to create mobile apps for multiple platforms, but otherwise it creates an inferior end product compared to a native app (let's please not get into the definition of "native", for iOS and Android you know what I mean). For google, who has enormous developer resources, I'm not sure why they would ever use it themselves unless it's for apps they don't care about.
Google doesn't even support its own devices from 2016, so I doubt they'd optimize their apps for the iPhone SE 2016.
I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I think that's great if you're testing for performance on older phones! Many of them are still quite capable devices. I suspect google isn't doing much of this.
> As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
That's a pretty modern phone, right? Have you tried it on your 6 or 6S?
> On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I haven't, because I think the OG SE is one of the best phones ever made. And I'm not a phone power user in the sense that I'm gaming on it, or doing lots of graphically intensive things. I just replaced the battery on it after using it for 5 years, and it runs everything I want to do perfectly...with the exception of google pay and some of google's other apps.
The issue I have with these basic CRUD apps running with tons of jank is that they're essentially just a UI with some text labels and buttons. For google pay, I want to open it up, navigate a list of people, select one, enter a number, and press "Pay". A computer from the 80s could do this no problem, it's not a graphically or computationally demanding thing. Certainly a computer from 2016 (iPhone SE) is up to the task, and before the google pay transition to flutter, it totally was.
Creating this software that runs slower, with no tangible end-user benefits, is simply pushing us towards more e-waste as people upgrade their devices unnecessarily.
Interesting thread from a year ago may interest you: https://news.ycombinator.com/item?id=26333973 (it's a flutter lead talking about Google pay).
I'd be interested to know how much the team tests with an iphone that old.
It’s even worse when you’re in a less common set up, like using an iPad with a keyboard case. I can’t even use the arrow keys to move between search results in the YouTube app.
I know most people don’t care, but it’s the endless little details that make me thoroughly dislike cross-platform toolkits.
You can't even select and copy text. And canvas is inaccessible to screen readers
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.
I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.
We're using Flutter for mobile development at my workplace.
[1] https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-local...
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.
This is easy to verify - just open up dev tools and look at the DOM structure.
Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.
For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.
The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.
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.
Flutter has its fair share (and to be fair, so do the native toolchains).
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.
Amen
Not as good as native, but if you're going to go cross platform due to various reasons such as development costs, then it's the way to go.
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.
https://github.com/flutter/flutter/issues/91605
Feel free to upvote any issue that you would like to see prioritized, as it helps us with planning.
Do they support copy / paste on the web app without using a special widget?
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...
Do they know that a ton of devs are not jumping in because of this one simple issue and sticking to other frameworks?
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.
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.
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.
Generally you just run a single command of dart fix and it will statically analyse the code and automatically rewrite anything that’s outdated to use the latest syntax for you.
Like it's essentially finished. Then again, I can always branch it and see what happens.
Just the best. No affiliation.
See here: https://flutter.dev/showcase
[0] https://apps.apple.com/us/app/five-three-one/id1560266240
I love Flutter. It made all this so much easier.
Right off the bat, I notice stuttering animations everywhere: Scrolling, swiping back, etc... This is on an iPhone 13.
In one section, the keyboard opened on top of a text-field so I couldn't see what I was typing.
The components are _just_ different enough that I feel something is wrong, but for the most part, I can't tell what it is.
Then there's a bunch of minor stuff. Switches become slightly larger when they change. You cant swipe down modals. You can't drag & release over options in the sheet. I feel like I'm missing buttons more often.
Overall, I get a vague cheap feel. Not so bad that I would outright dismiss the app as a customer, but I would definitely look for alternatives.
This isn't a critique of the app. I think all of these issues are flutter-related.
Regardless I'm sure what you have is a great app here so hope you don't feel like I'm targeting you or your app directly here, and at the end of the day if flutter allows you to make your customers happy more power to you and hope it works out the best for you.
iOS: https://apps.apple.com/us/app/tracker-network-stats/id128769... Android: https://play.google.com/store/apps/details?id=network.tracke...
Flutter is a mature option for mobile development, esp. for small teams developing for multiple platforms.
Especially for use in plugins to existing said that do not control the main event loop?
that should have been working day 1. maybe day 2. flutter has been out for years, and the fact that you can’t successfully use Google software with Google’s other software is starting to be a wart they can’t excuse because of internal build chain differences.
I could not get this to run on a Ubuntu VM (arm64) - anyone know if this is also working?
And typical Google
> As part of this shift, Google in July put Material’s iOS libraries in “maintenance mode.”
Who is to say Flutter isn’t next? Google has the attention span of a coked up teenager.
Doesn't seem like the article you linked accurately represents your statement.
> 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.
The best experience for users would be a library that handles business logic, as well as describes how the UI should be laid out, then building native clients that use that library.
I found it a bit difficult to work with, and I also wanted to code my UIs from the back-end. So I wrote DocUI which will be released in the next month or two. https://nexusdev.tools
It's: https://docs.flutter.dev/development/packages-and-plugins/ha...
Love the concept but eyeing it for b2b style apps that need extensibility.
Or does it require google services or call home monitoring
Yes, there's several in F-droid. Flutter doesn't use any Google services by default.
However, it doesn't hurt to know a bit about reactive UI concepts.
TLDR: JavaScript and browser apis will win in the end.
From my perspective, while I'm sure Flutter is wonderful, it fits squarely in the "mobile" UI toolkit and "basic" desktop application category.
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.
Desktop GUI software is a pretty small niche. The web has eaten nearly everything, and games don't use native UI stuff.
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?
I also don't consider native phone/tablet apps to be desktop apps
So VSCode isn't a desktop app?
(Disclaimer: I work on the Flutter team.)
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.
[1] https://www.youtube.com/watch?v=OEdQXBUPYOE
- 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
- 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.
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.