Martin Kustermann

Maybe one addition: One could allow a `dart install --mode=jit` where the deployable bundle that is locally installed uses JIT and `dart:mirrors` - it could compile the app to kernel...

> it might be worth upping the abstraction level. I think there's actually a need to go higher in abstraction **and** lower: Example: With our existing `dart:io` APIs it's not...

Yes, dart2wasm doesn't support `dart:ffi` yet - we intend to look into how we can best support FFI on the web. But for the time being one would need to...

Actually, for our iteration speed and also conceptually, it may actually make sense for this `package:record_use` to live in the Dart SDK (i.e. `dart-lang/sdk@pkg/record_use`) for now: The code that generates...

> But we would still publish it, right? Of course we can publish it. > Also, do we have any restrictions on adding packages to the SDK? I don't want...

> The issue with Flutter is that our isolate group shutdown API is not synchronous. So Flutter doesn't wait until the isolate group has fully shut down before hot restarting....

> The GC can do the same thing, it can accumulate all native finalizers it wants to run, then exit safepoint operation, exit isolate group, run them, re-enter isolate group....

> CodeAsset.validateBuildOutput (static method). Doing that for all asset types makes the validators easy to find. I didn't want to do that, because a normal `hook/build.dart` writer shouldn't have to...

I still believe that the `hook/{build,link}.dart` should not do the validation. Conceptually this is the job of the bundling tool, it **has to do validation**. Here's a few reasons why...

> We cannot have validation for temporary asset types (that only live between build and link) in embedders, because embedders don't know about those. So if we want to support...