Dart/Flutter now has macros/metaprogramming
github.com
github.com
Not really sure what the linked repo is about.
All good things.
Hot take to think Dart is superior in that respect.
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.
Example code here: https://github.com/dart-lang/web/blob/main/example/example.d...
I tried something similar a few years ago and I would have said you're absolutely right. But with the one I'm writing now, it is quite the different experience.
That's also one of the reason why the framework is so popular in developing countries.
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).
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 just wished it would have native tuples.
Also "destructuring" via patterns: https://dart.dev/language/patterns
(Go, Dart/Flutter, Angular, Bazel)
It's quite common to generate code that way.
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).
Yeah, I’ve been trying to stay away from it but it feels inevitable!
I do not want to deal with code generation.
* instant compilation
* amazing tooling
* null safety
* typed
I could go on.
Dart has a GC.
> Go
Dart has exceptions.
> JavaScript
Dart is statically typed.
---
Plus....Dart has a first-class mobile story, unlike Rust + Go.
---
Hope that helps!
Not really, the Android team doesn't even list it as supported language, a team that belongs to the same employeer.
The same team not only lists Rust, it has official documentation on the Android site for OEMs, on how to use Rust.
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.
You mean Kotlin?
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.
https://github.com/flutter/flutter/issues/125388
https://github.com/flutter/flutter/issues/101591 (going on 2 years!)
I also believe Google will shit can both this and Fuchsia, because Google is CADT baked into its organizational structure.
Like for 1ms? For a second? Eternally?
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.
https://github.com/flutter/flutter/pull/104335
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.
The material stuff looks good and performs well and at this point users have more desktop apps on their machine that don’t use native controls than do.
My flutter app is way more responsive and efficient than the electron prototype it replaced.
Just tried it out. 3-5% in debug build. 0% on release build.
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.
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.
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).
All languages that have more use cases than being bound to a GUI framework, which is the problem with Dart.
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?
Because the only use case I see with Dart is UI development, nothing else.
Which has been released onto smart displays, which you apparently missed.
Since when has Google Earth lost its C++/WebAssembly/WebGL roots?
And I don’t know what you think Flutter is built with but it’s C++ / WebAssembly and WebGL.
https://news.ycombinator.com/item?id=39005470
https://news.ycombinator.com/item?id=36871673
https://news.ycombinator.com/item?id=34515277
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.
However, if your app can do without any platform views, the performance seems pretty good.
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.
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
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.
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 ;)
I've written a lot of code in many languages. C, C++, Obj-C. Why does Dart need state management libraries?
None of my Flutter code uses "state management", and I've never felt the need for it, ever.
I think people are just too afraid to use static variables (globals) when necessary.
For me, Flutter is code bloat in comparison with Swift. Swift is doing a great job of reducing the code you need to write, lots of syntactic sugar.
I only compared few basic apps like Hello World and Buttons, but the difference in code to write was stunning to me.
Flutter also resembles React in this regard to me. Lots of bloat instead of syntactic sugar like for example in Angular.
https://www.reddit.com/r/FlutterDev/s/kKVzkvpnlj
https://www.reddit.com/r/FlutterDev/s/RyBQaLBeuS
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.
[0] https://reddit.com/r/FlutterDev/comments/1afeo2r/has_anyone_...
---
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.
Nice recommendation. Only by looking at the video do I feel that it appeals more to me and my needs than Flutter.
CM for iOS is still in Alpha.
[0] https://reddit.com/r/androiddev/comments/19em0d3/multiplatfo...
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.
Is Flutter still just rendering everything to a <canvas> as an image?
Why not a “Plutter” framework using Python instead of Dart and outputting a WASM app that uses Flutter for all the layout?
No, it can spit out html instead.
Dart has runtime reflection and annotations that predate this. The benefit of making this compile time are mainly performance.
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.
I try to give it the benefit of the doubt, so I found a demo site. Here is the first example I opened: https://flutter.github.io/samples/web/material_3_demo/
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.
A flutter desktop app will perform a lot better.
Flutter mobile/desktop on the other hand performs great and is way more efficient than web UI.