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.

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.

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.

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.

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.

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.

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.

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.

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

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).

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.

[1] https://github.com/flutter/flutter/issues/93416

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.

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.

The only thing I really hated about Dart was poor enum support. Now that's fixed.

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.

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.

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.

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.

[0] https://rows.com/download

https://flutter.dev/showcase

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.

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.

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.

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.

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.

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)

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...

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.

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.

[1] https://github.com/flutter/flutter/issues/103645

[2] https://www.youtube.com/watch/0Bt-c9-h92c

* 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!

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...)

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 ¯\_(ツ)_/¯.

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.

https://go.dev/doc/effective_go#embedding

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...

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.

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.

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).

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.

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.

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.

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.

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.

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.

Someone currently on the Instagram team can correct me if I'm wrong.

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.

https://news.ycombinator.com/item?id=31346887

Why did they tie Flutter to Dart anyway?

wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.

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 it

It 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

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.

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)

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).

[1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d

[2] https://github.com/dart-lang/language/issues/1482

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.

[0] https://pub.dev/packages/freezed

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.

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.

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() {}