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