You can effectively try this today in Dart. When running in the browser, Dart can compile to either JavaScript or Wasm and both backends support DOM access via https://pub.dev/packages/web.
The DOM access in Wasm does trampoline through JavaScript under the hood, which introduces some overhead. Dart uses WasmGC, though, which is supported on Chrome/FF/Safari and lowers that overhead by enabling objects to be shared across the Wasm / JS boundary. In the benchmarks we've tried, the overhead is not that noticeable. But direct access (from Wasm) would be faster.
This app is too small to show benefits, but the code size is about the same across the two and similar to those at todomvc.com. We are seeing potential benefits on page load time (Wasm is faster to parse/initialize) and compute (Wasm is faster on many workloads).
The app prototyping logic in Firebase Studio isn't wired up for Flutter/Dart yet. You can play with Gemini+Dart/Flutter here: https://dartpad.dev/?channel=main.
We're working with the Firebase Studio team to integrate. FWIW, it seems to do fairly well with "Create a chess clock app".
Hey. That makes more sense. To be honest, I don’t think it should be one of the main things on the front page when creating a new project in that case.
However for what it’s worth Ive also asked gemini to translate this simple chess clock app to react because of how buggy the flutter project was and it just got stuck again and again no matter how much I helped it
We're still working on this, and you can find updates in the language repo. One reason we're taking extra time here is that macros / static metaprogramming can blow up compile times and hot reload.
That said, it was true that Dart was used heavily internally in that time frame. It was and still is, by Ads (ads.google.com) - that's a non-Flutter Dart app and still (to the best of my knowledge) the largest Dart app around. Before Flutter, we went through a period of primarily prioritizing internal customers. That work was often not visible externally.
We did do the shift to Dart 2 in that time period though. That was a fairly massive change to the language that began independently of Flutter. It was a nice timing that Dart 2 shipped at the same time as Flutter 1.
Let me be blunt, the work was never visible externally. What was visible externally is major language designers leaving the team (Lars Bak), Updates to the language slowing or stopping all together, the chrome team deciding to abandon dartvm in chrome, the angular team deciding to use typescript for angular 2.0, and Dart angular being abandoned (even as it was still being advertised on dart.dev!).
What other conclusion was an outsider to draw other than "Ok, google must be done with dart"?
What was the plan if flutter never happened? Would google ads continue to use dart?
Like I said, happy that you and your team are now enjoying some nice popularity. I jumped on dart early because I thought it was overall a good idea and decent language. However, once bitten, twice shy.
The odds are very good that Lars would have left regardless of how Dart was doing. He has repeatedly told me "I'm a 1.0 guy". He likes shipping new things but he's not the kind of person to spend a decade cultivating an ecosystem and refactoring mature codebases.
I'm really sorry you got burned by the early experience. It was a hard time for Dart users. It was a hard time on the team too. It felt like we were wandering in the wilderness for a while and struggling to agree on what language our users wanted us to build for them.
I think where we've landed is a much better product, but I'm sorry that our churn getting there caused you pain.
> It felt like we were wandering in the wilderness for a while and struggling to agree on what language our users wanted us to build for them.
And I really appreciate you saying this. I get that what I'm saying is harsh and probably comes off as whiny/ungrateful. I'm mostly just venting because of the original "Why are people mad about dart in HN" comment and explaining my position there.
Dart does look like it's moving forward in a good direction and I wish it all the best. It's certainly great that the language and ecosystem are seeing a fair bit more adoption.
This is precisely my take, as well. I got burnt by Angular Dart and the Dart VM, so I'm extremely reluctant to try out Flutter. I've only got so much time on this earth and I don't want to keep investing it in Google's abandonware.
Dart itself is used heavily on the Web by Google. E.g., ads.google.com is a Dart web app - but not a Flutter one. It uses a Dart version of the Angular framework. It's probably the largest Dart app in existence today.
Flutter on the Web is less mature, but (IMO) making good progress.
Isn't AngularDart "deprecated" now? I say "deprecated" in quotes because the repository has been archived [0] and it says it's been moved to a community project, which I'd think is a little strange if Google has a large (and I'd assume important due to it being a revenue generating site, ie ads) codebase but then archives the project.
Big fan of Flutter though, what's next for Flutter on the web, anything interesting?
TL;DR - It's still heavily used inside of Google, but the team decided to stop maintaining the open source version of it. It was a fair bit of work to do both - different build rules, different tests / test infra, different priorities. Effectively, AngularDart has been forked. There is an internal-only version that is actively developed, and there is an external community project.
Regarding Flutter on the Web, there is a lot of active work, but I'm not the best to speak to all of it. On the Dart side, it's one of the major reasons we're investing in things like compilation to Wasm.
Ah I see, so Google doesn't use the open source version at all. I thought it was like Flutter or Angular where the OSS version was used but it's different in this case.
Just had another question, I actually just filed a feature request for Dart (based on reading this thread about Option and Result types) about whether Dart has a Result type [0]. Looks like it does in Flutter's async module, but I wasn't sure why that wasn't also brought to the rest of the language.
And for WASM, I thought garbage collection for WASM wasn't stabilized yet, will Dart have to wait until then? What benefits does WASM provide for Flutter that's not already covered by how it does web support anyway, ie drawing inside a canvas?
For Wasm, yes, we're targeting the new garbage collection support using the experimental implementation in Chrome. We think this has the potential to help with performance.
That's excellent to hear! I did not know (my lack of research in that regard obviously) that Dart was used that much outside Flutter! I really like Flutter and see them as married, but I'm obviously wrong. Thanks for the explanation.
The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.
Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)
I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.
> Have you considered not going full-on structural-typing but still providing some sort of union?
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
No time frame, sorry. We generally don't make promises about future dates because schedules tend to be flexible and picking dates just sets people up for disappointment.
As timsneath mentioned above, Dartpad is the dev environment. That means we ship the full Dart and Flutter SDK ahead of time as you can type/change anything in the code box. We also ship debug metadata to give better errors.
In production mode, we do a much more expensive compile to remove the parts of Dart, Flutter, and packages you don't use and to optimize/minify the rest.
It is working in Safari for me, but we've definitely appreciate bug reports if it's breaking for you (https://github.com/dart-lang/dart-pad in this case).
It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.
As others have already noted, the intent here is to purely measure the one-time startup cost of the runtime in ahead-of-time compiled code - i.e., the amount of time necessary before we can starting executing any user code - i.e., the print in this case. It's assumed that the time to do the actual print is trivial here.
If you want to compare, you might compare with other garbage collected language/runtimes.
"Instant" is a relative word (unless we're actually at 0 time :-)).
We're focus on client apps, where we're really focused on human perception. In that sense, I'd consider 22ms or 2ms as instant (for startup). I wouldn't consider 2s as instant.
I'm not saying Dart doesn't have room to get better, but there are diminishing returns at a certain point.
The DOM access in Wasm does trampoline through JavaScript under the hood, which introduces some overhead. Dart uses WasmGC, though, which is supported on Chrome/FF/Safari and lowers that overhead by enabling objects to be shared across the Wasm / JS boundary. In the benchmarks we've tried, the overhead is not that noticeable. But direct access (from Wasm) would be faster.
Jaspr (https://jaspr.site) is a react-style framework that sits on top of this. You can see example usage here: https://github.com/vsmenon/todomvc/
This app is too small to show benefits, but the code size is about the same across the two and similar to those at todomvc.com. We are seeing potential benefits on page load time (Wasm is faster to parse/initialize) and compute (Wasm is faster on many workloads).