Thanks for linking the spec. It has been a living document for a long time. I discovered that the implementation had made it into the SDK's master branch. Since it's very early stage and lacking documentation, I made this repo which demonstrates creating a macro that implements some of the most popular codegen functionality Flutter developers use.
I hope Dart gets more support, I really want alternatives to TypeScript for developing webapps which aren't super "bulky" (slow startup, buggy and hard to debug) and support mobile apps. Dart seems to be the best at both although I haven't used it much. It also seems reasonable (one of the reasons I don't like TypeScript is because it still has some quirks from JavaScript like `===`, also because the types are occasionally wrong even in strict mode).
Isn't flutter the anti thesis of that? Making performant JavaScript apps is much much easier than making a performant flutter or especially flutter web app
I have an opposite experience. Making performant JavaScript app require years of learning hacks of web ecosystem. Which is unsurprising, given that web apps build on the foundation layer not suited for performant UI apps.
Flutter apps are performant out of the box, because, well, it was designed with this goal in mind.
No idea if it's any better on Android, but on iOS I can recognize a Flutter app within seconds, by the frame rate on a new iPhone dropping to something I haven't seen on any mobile device (iOS or Android!) since the Android 2.2 days on extremely underpowered Qualcomm chips.
On Android, Flutter apps are typically even faster than native on cheap low-end devices from my experience. I'm comparing using a Galaxy J3 pro and the difference is visible in favor of Flutter. On high-end devices, I don't see any difference.
That's also one of the reason why the framework is so popular in developing countries.
Most likely they’re not using the new impeller rendering engine. My flutter app is very smooth on iOS and I didn’t have to put in any fancy hacks to make it that way.
Flutter apps have god awful performance when there is even a single platform view on the screen. In effect this means that if the app is monetized by ads, have any video, map embed or anything of the sort, it will have sub-30fps and very janky scroll even on iPhone 15 Pro and it really seems that there is no hacks to save you.
Yep, my typical experience with flutter apps is having way more frame drops, and occasional bugs which lock up the entire UI and require an app restart. Thankfully I think google is moving towards just using the platform UI for most apps, though I can't remember where I read that so take it with a grain of salt.
Absolutely, but for webapps, is there any other options using dart?
For the record, dart is one of my favorite languages. I'm just a bit sad that it is more or less tied to flutter (not by design, just because it's the main usage it gets)
They are a couple of weeks away from launching a major rewrite of Web support.
Historically it was clunky and weird.
Now it’s able to use the exact same Web APIs that you’re already used to but now in a type safe way and much much better type safety guarantees that Typescript provides.
How do you feel about Java? How about Ruby? (If you have worked with those). I'm mainly asking so I have a baseline for what your preferences are. Considered Dart in the past but haven't tried yet
I dislike ruby, purely as a matter of personal preference. As a baseline, python is probably as "dynamic" as I can tolerate, and java I just don't have enough experience with sadly enough. I use mostly c++/go/python with some julia and rust (not enough to have tons of experience with it though!). I'd day try dart, it's very easy to pick up. In some odd ways it reminds me of swift!
> I really want alternatives to TypeScript for developing webapps which aren't super "bulky"
I hear you, but what do you expect Dart's contribution as a language/technology to be in this space, effectively? While syntactically comparable, TypeScript is a better typed JavaScript than Dart will probably ever be (in terms of leveraging a type system to enable more complex/maintainable apps and libraries). And since every programming language compiles to JavaScript these days, you've got some compelling options if you really want to depart from JS altogether (with http://www.scala-js.org/ an amazing one, for which I find the mix of Functional + Object Orientation to lend itself very well to the web).
In all, I really fail to see a good reason for Dart to exist nowadays (and surviving as "Flutter's best language buddy" isn't a great one).
> TypeScript is a better typed JavaScript than Dart will probably ever be
At the same time, thank goodness Dart doesn't have all the warts of Javascript and a standard sane build system. Dart doesn't have to be the best Javascript to be good at what it does, especially now with algebraic data types and pattern matching.
I'm hopeful they'll make Wasm production-ready soon to move away from JS transpilation.
I did a little programming in dart. There are many things to like. And I believe, at the time of writing, that Dart really is great for both java and js devs. Every object that is used has to be an instance of a class, and the event-driven style for reactive programming is pretty much 1:1 to how js does it. So it truly could become the sweet spot for UI development that is appealing to both types of devs.
After years of working in Typescript I've been doing a Dart project for the last 6 months or so. Overall it's a great language but one of the clunky aspects is the use of code generation for so many things. If this can reduce or even eliminate that it will be a big step forward for devX.
I'm curious what aspect of the code generation you find clunky. When I used Dart, my issue with the code generation was that it didn't "just happen". With C#, anything that's being generated just happens without any involvement from me and it happens basically instantly. With Dart, I was left running their build_runner manually. Plus common things like json_serializable then require you to add methods to wire up the generated methods (partly because you can't have a factory constructors outside of the class definition, but I don't know why they don't just wire up toJson() as an extension method).
I guess I'm trying to figure out if you just dislike having generated files (where you can see the code) or if you dislike how Dart does it (where it's a bit of a clunky process).
It works well enough. It's a bit of a hassle to set up and you have to always run the file watcher and add the `part "blah.g.dart"` imports. I wouldn't say it's held me back but I'd be happier if the language itself was flexible enough to eliminate the need for this. I'd also be defining my own macros if it was easier to do.
I'm not really sure where it slots in in a world with a lot of programming language choices. Why would I use it over something like Rust, Go, or even JavaScript?
>Why would I use it over something like Rust, Go, or even JavaScript?
Honestly, mainly for flutter. But if you do chose flutter for your project, you will suddenly wish everyone was using dart for everything else instead of Java on android, or c#/Swift on ios ect. if that makes sense. If sound type checking is truly feasible on the web then I'd say dart should be there too. But I can't say if that's really the case. At least ECMA seems to think it isn't, at least for js.
I think Dart really suffered from missteps in the early days. Originally, Dart didn't seem like anything special and it kinda wasn't. It was a dynamic language where optional type hints were suggestions and it'd be run in a VM just like JS and seemed like JS with some slight differences.
It feels like Dart became a completely different language that just happens to have the same name. It's now statically typed, has AOT compilation, null safety, etc.
I think that left Dart in a weird place in terms of mindshare. A lot of people likely looked at Dart 1, didn't see a real place for it, and haven't gone back to it. Google was also highly ambivalent about Dart for a while and most of the mindshare went to Go (despite the fact that I suspect most would prefer Dart).
In the end, it feels like Dart is lacking the ecosystem that other languages have. There's so much written for JS or Python or C# by comparison and so much of Dart seems to be in order to support Flutter.
Rust somewhat occupies its own place in the universe: people who want something a lot stricter than ordinary static languages where there's still a GC and still some runtime stuff. However, I think if Dart got more momentum it could be seen as a nice alternative to Java, JS/TS, C#, Python, etc. Note: I'm not saying that Dart has no momentum, but as you note it's mainly for Flutter.
On top of that, it was AdWords team that kept Dart 1.0 alive, while Flutter made Dart 2.0 happen.
It isn't much beyond Flutter making Dart relevant, other than the folks that decided to rewrite Sass into Dart I guess (I wonder when A RIIR will happen, like most JS tooling nowadays).
As someone who has written plenty of Java and JavaScript, Dart feels way more enjoyable to write. It just does. Maybe it's because I was less experienced when starting with Java and JavaScript, but it felt like there was a much smaller learning curve with Dart, too. I imagine it helps that I'm writing it in Android Studio, a JetBrains product, but I find the ergonomics better than even Kotlin. If you want to use it outside Flutter, you probably will wish it had a larger ecosystem, depending on what you're trying to write.
Nah. Dart is ok. It doesn't perform as well as those peer languages. It's nice its FFI story is good, but the ecosystem is very weak even compared to Javascript.
As for the tooling. It's decent. I wouldn't call it amazing, unless you come from systems that were anemic to begin with, then it seems pretty amazing.
As for flutter. I recently installed it again. A test app with a single CupertinoTextField consumes 45% of an Intel core on a linux desktop (Wayland and X11 were similar). Like, goodbye.
Maybe if WORA means iOS and Android, fine, I get that is the common use case. But that is wishful thinking to false advertising as far as I care.
The dart ecosystem is way richer than I expected it to be. So far I've found good options for everything I need and in more than a few cases the libraries are better designed than the JS equivalents.
I can't speak to Linux desktop performance but on the Mac my Flutter app sips CPU and memory.
Google abandoning it is a real risk. If they continue to support it I think Flutter has a great future.
So I tried the exact same test on a last gen Intel Macbook Pro. Same thing. 20 to 40% app CPU usage not including WindowServer.
Putting cursorOpacityAnimates: false "fixes" it, seemingly similar to this:
This is more of an eyebrow raising signal to me. This is not quality congruent with a multibillion dollar company backing. If the cupertino widgets are in this sorry of a state they probably should be marked as such.
But perhaps someone more invested in the ecosystem may want to submit that pull request. It seems like low hanging fruit.
Let me guess, you did a TextField, not a CupertinoTextField? (It's 20% on release for me, still too much for a blinking cursor). Sure there may be some simple pathological bug in that one widget, but this quality issue in a fundamental widget in the official kit just does not give me the warm fuzzies, especially looking over the the github issue tracker.
And yes I am biased because it is google and they hardly dog food this product.
This particular problem is "fixed" by a simple cursorOpacityAnimates: false (which is apparently how they "fixed" TextField). That still doesn't speak well for QA.
This is not really a complaint about a single widget.
I really really want to like this stuff, but I have no confidence in it as a serious long term product.
Eternally, as long as that text field has focus with the animation of a blinking cursor.
I'm not telling my customers to make sure they're not "holding it wrong" by deigning to leave the app in the foreground and killing their battery.
Exactly. I use it for a full stack mobile app development. Backend and frontend can share code. Server can be compiled to a single machine code binary.
That’s really interesting and compelling. What’s the rest of your backend stack look like? Do you get good performance from the database drivers written in dart?
Please do, because excluding minor exceptions, the more popular of recent programming languages have these as table stakes. Everything (even previously dynamic languages like python) has some form of static typing, options/null-safety, and really good tooling (ts ecosystem is huge, rust compiler has entire articles praising it for making people better programmers). Some languages might be slow to compile but have solutions like HMR for ts and are actively being improved in languages like rust.
Some form of static typing != proper static typing. The 'static typing' from Python (and other previously dynamic languages) do not come close to Dart's; neither does Typescript's.
All forms of null-safety aren't the same. The ergonomics differ.
Huge ecosystem != good tooling. But indeed, Rust has good tooling. Doesn't mean you can compare Rust to Dart though.
Rust's compile-time is improving, but why are we bringing in future items for comparison?
isn't this bad? every single language I have ever seen that added macros (including Rust) has had problems with macros. unless you are VERY careful, the macro language ends up being turing complete, and/or compile times explode. also now you have two programming languages, and macro heavy code tends to be unreadable, which is fine for the API users, but makes maintenance a nightmare.
> A macro declaration is a user-defined Dart class that implements one or more new built-in macro interfaces. Macros in Dart are written in normal imperative Dart code. There is not a separate "macro language".
OP, can you clarify what you mean by the tittle? You have been able to enable Macros as an experiment for a while now, right? And Macros still haven't achieved GA, so I'm not sure what has changed. Is there some point I'm missing here?
Flutter is what rescued Dart from certain death, after Chrome stop caring and AdWords took over from what was left in Dart 1.0, as most well know language designers on the team like Gilad Bracha and Kasper Lund left Google.
That information is about a decade out of date. In practice a bunch of new stuff is using it from the as yet unreleased Fuchsia OS and major products are being rewritten to take advantage of it (Google Earth comes to mind).
You didn't even knew about its use in Nest Hub Smart Displays.
I know how Flutter is implemented, thank you very much.
Most likely is a very thin layer over existing Google Earth C++, unless you have some proof the C++ code was fully rewritten into Dart, beyond a simple tweet.
I see a couple of comments regarding frame rates on load. The Flutter team claims they addressed that with their new rendering engine. Has anyone found this not to be the case?
I'm working on an app that is running on the latest version of Flutter with Impeller enabled. The performance seems good as long as you do not embed platform views inside a list. However, when you drop even a single platform view (web view, video player, google ads...), the performance drops to unacceptable levels even on the latest iOS devices. This is related to another issue with the Flutter ecosystem, it has close to zero support from third parties and therefore you end up having a lot of these platform views. Even things like Google Ads have no native Flutter support and therefore adding a single ad on a list ruins the app. Reading Flutter issues about the performance related issues is sad as the same issues have been there since the beginning and there is no end in sight.
However, if your app can do without any platform views, the performance seems pretty good.
You might be interested in Compose Multiplatform, it's from JetBrains and is a combination of Jetpack Compose and Kotlin Multiplatform. You can transparently use both platform views and CM views together in a way that I haven't seen in Flutter.
Here is a video about this where the JetBrains employees go over a demo of building a cross platform app in 100% Kotlin, just as would be the case with Flutter [0]. Check out the timestamp 41:37 where they talk about the above interoperability. They have an example of a messenger app where the messages are in CM while the text input box is in Swift, so that this ensures that you are not reimplementing the native text editing controls as Flutter does, so I see that as a clear advantage for specific things like that.
Also see timestamp 51:23 where they talk about graceful decomposition where if you decide to remove CM, you are left with a regular Android app as CM is backwards compatible with Jetpack Compose.
I use Flutter quite a bit but it seems like Compose Multiplatform might be the future, since it has a number of clear advantages due to how the architecture of CM is set up.
That Compose Multiplatform interoperability with the native views and other way around looks really nice, especially because it matches how SwiftUI deals with UIKit/AppKit interop. However, at this point it is hard to say if they will hit very similar performance issues that Flutter deals with as rest of the UI is not native and is drawn with Skia (as done by Flutter before it moved to Impeller for improved performance). It is definitely very valuable feature nonetheless.
I really love the engineering that has been put into dart/flutter and the innovation it has brought to native UI development, but I just can't justify using it for anything. The ecosystem is immature and anything I would use it for could just as easily be written in Kotlin or JavaScript (TS).
Well, Flutter is primarily for apps that work cross platform, if you use Kotlin then you can only run it on Android (yes, Kotlin Multiplatform with Compose Multiplatform exist but they're even less mature than Flutter).
For JS/TS, you could use React Native but you also wouldn't get the full spread of platforms as RN is primarily for mobile and the web and desktop implementations are based on third-party support, plus the developer experience is inferior to Flutter.
So, if you want to make multiplatform apps, use Flutter, but if you only need to make Android or RN apps, use those respective platform tools.
There are usually good libraries for most things today. And with Android / Jetpack ecosystem moving so fast and deprecating things, Flutter is something to consider even if you target just Android.
My biggest two concerns were state management and native interop.
State management is probably biggest concern - there are at least 5 approaches / libraries competing for mind-share - and none of them are particularly ergonomic.
I did get an opportunity to work for a while on native interop for android / java [1]. But I haven't been able to work on that since long time.
> State management is probably biggest concern - there are at least 5 approaches / libraries competing for mind-share - and none of them are particularly ergonomic.
I've heard this critique a lot (particularly about Flutter), but I'm not sure I agree that having multiple state-management approaches is a bad thing. Can you elaborate on why this is painful?
From my perspective, (and to borrow the 'ergonomic' metaphor), it's like opening a toolbox and finding 5 different screwdrivers with similar heads. Some might not be well-suited to your project, and of those that do, one might have a handle that you find more ergonomic. I find it hard to imagine a screwdriver that could fit all screws and feel amazing in all hands at once.
Also, fwiw, I find Riverpod to be very ergonomic ;)
To be honest, I'm glad. No development environment can be as great as to justify the horrible, juddery UX I experience as a user in the few apps that I know use it (and probably a few more where I only have a strong suspicion).
If that's really the case, I hope to be able to see the effects of that soon in Google Pay on iOS, which is even being touted as a showcase application by Flutter/Google: https://flutter.dev/showcase/google-pay
Tldr, it's a different philosophy between Flutter and Swift, of explicit being more useful that implicit, and of performance optimizations that can be made due to that. The second thread has the tech lead of Flutter responding to the claims.
I believe there are very good reasons to design Flutter as it is and I don’t want to denigrate it. I think it is awesome work.
It is just that Swift feels extremely elegant and well-shaped, like a Domain Specific Language, and it didn’t feel this in the beginning. It evolved and did a great job.
Maybe like Java and Kotlin. I like Java after all, however I enjoy Kotlin the way I enjoyed Groovy.
BTW: Hixie, tech lead for Flutter, is my man. Dude was instrumental in establishing HTML5.
Actually, check out this comment [0] I made in another thread that was recently posted (copy pasted below), it's about Compose Multiplatform in Kotlin, it seems to be an upcoming Flutter competitor. It's pretty intriuging as I was initially using Flutter because I didn't want to have different apps for each platform, but it seems like with CM, it can do the same thing as Flutter but with more advantages, as I wrote of below.
Something I thought was really interesting in Compose Multiplatform is that you can transparently use both platform views and CM views together in a way that I haven't seen in Flutter.
I just watched that video [0] as well and I wanted to highlight a few interesting concepts there. Check out the timestamp 41:37 where they talk about the above interoperability. They have an example of a messenger app where the messages are in CM while the text input box is in Swift, so that this ensures that you are not reimplementing the native text editing controls as Flutter does, so I see that as a clear advantage for specific things like that. I don't believe that is quite possible in Flutter, or am I mistaken?
Also see timestamp 51:23 where they talk about graceful decomposition where if you decide to remove CM, you are left with a regular Android app as CM is backwards compatible with Jetpack Compose. It looks like CM can both paint to the screen but also fall back to using pure native Android components.
The way the architecture of CM is set up seems to make CM quite robust. Initially, I wrote off Kotlin Multiplatform because I thought, what's the point of sharing business logic in Kotlin if I still have to write the UI twice for mobile, not to mention for the other platforms like web and desktop. But now with CM, it looks like they're directly addressing Flutter to the point of taking a lot of concepts from it like you mentioned, like painting pixels on the screen (but optionally falling back to native views), or using WASM and canvas for the web which is exactly what Flutter Web does too.
I use Flutter quite a bit but it seems like Compose Multiplatform might be the future, or at least a big competitor, due to Google focusing more on Android dev and the whole Kotlin ecosystem in the past few years, it seems. The only con right now seems to be that CM is way less mature than Flutter, which really reminds me of where Flutter was several years ago.
Don't discount the developer experience too. With the codegen annotations, you either have to check in your .g.dart files to git which could be stale and break compilation in CI, or have them generate in CI, which is unnecessarily slow and eats up CI minutes. Added bonus is the macro API is less complex than the codegen API.
> or have them generate in CI, which is unnecessarily slow and eats up CI minutes.
Maybe I'm missing something since I'm not that familiar with Dart, but wouldn't Macros use the same amount of time to run and compile?
Either you're processing my_thing.dart and writing out my_thing.g.dart and then compiling the whole thing -or- you're processing my_thing.dart and writing out the new stuff to something in memory and then compiling the whole thing. Right? The amount of time it takes to generate the methods should be the same between the two and then the time to compile the same methods with the same code should be the same as well, right?
Again, I'm not that familiar with Dart and maybe the source generators have drawbacks that I'm unaware of, but it seems like the macro would be doing the same compile-time work (just without emitting the code to a file). I'd love to know what it's doing differently if that isn't how it's working.
Yeah, it is. It inspired the reflection in Dart, which inspired the macros. You can only use Dart's reflection when running in VM mode though. Flutter apps use AOT compilation, due to tree-shaking, so you lose the reflection and fall back to having to run codegen - kind of like TypeScript -> JS. This is a nice improvement that is run in memory before compilation and allows better access to the AST.
Flutter is like Qt where they implement their own windows themselves. But instead of C++ and OpenGL, they use ... Dart and CSS? All the ease-of-use and ergonomics of C++, and the raw bare metal performance of Python. /s
I click play on the progress indicator. My CPU usage goes up 5%. This is on a Ryzen 9 7950X3D. Compare to Unreal Tournament 2004 at max settings running at 240fps, which uses 6% cpu.
I just can't take Flutter seriously. I don't care how good the developer experience might be. It's absolutely terrible for the user.
I started some cross-platform work about 6 ago and came into Flutter with plenty of hesitation. I was fearing this much ranted about janky feeling, but so far it has not come. AFAICT from the forums and such, the Web target is definitely far, far behind the mobile targets. This isn’t really a concern for me. For the app I’m building for iOS and Android, the result has been performant, and I’ve really liked the language and framework.
I think at least on iOS it's stable enough to use now. I'm also not having any issues with it on macOS. Android impeller still seems to have some bugs.
Flutter web is much less mature and performant than the native build targets. If the web is your primary target it’s not a good choice, at least not today.
Flutter mobile/desktop on the other hand performs great and is way more efficient than web UI.
Not really sure what the linked repo is about.