Remove support for dart:mirrors and dart:isolate from dart4web

[munificent]

In Dart 2.0, our web products — dart2js and dartdevc — will no longer support dart:mirrors and dart:isolate. Support for those has been limited and problematic in many ways for years, so the simplest solution that gives us the most room for future improvement is to not support them at all.

Now that we have configuration-specific imports and const bool.fromEnvironment("dart.library.mirrors") "dart.library.isolate", it's feasible for user code to feature-detect whether those libraries are available and handle their absence.

This is the main metabug to track this. Feel free to file more specific issues for changes that are needed.

• Define "dart.library.mirrors" and "dart.library.isolate" as false in dart2js #30539
• Define "dart.library.mirrors" and "dart.library.isolate" as false in dartdevc #30540

[donny-dont]

@munificent will there be a web worker library then?

[matanlurey]

Likely, but mutually exclusive with this issue.

[donny-dont]

Sure I just figured there'd be an associated issue.

[matanlurey]

No associated issue yet.

[munificent]

No concrete plans that I know of, but I think you should be able to get to web workers by going through JS interop.

@jacob314

[matanlurey]

We talked a bit about this when I visited @jacob314 and others. Any "native" API is likely to be more-or-less equivalent of the bit of JS interop you'd write today - there aren't any immediate plans to make a super "Darty" web worker/service worker API, especially given the spec evolving.

[donny-dont]

I respect not wanting to have a darty web worker/service worker API at this time. My first concern is about how stuff exposed in dart:* libraries would be usable in a worker context.

As an example in Chrome's IDL there is https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/indexeddb/WorkerGlobalScopeIndexedDatabase.idl and https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/indexeddb/WindowIndexedDatabase.idl for the two different contexts of indexeddb.

I feel I should be able to have the same dart:indexed_db interfaces for dart:html and web worker contexts. So the IDL generation part should be conscious of this.

My second concern is about compilation. I'm not sure if DDC would freak out when running in a worker context because of any magic happening with dart:* apis to make them nice and darty. There could be other issues around compilation as well.

Thanks for the replies here. I'm really looking forward to the Dart's 2.0+ future but wanted to make sure I didn't run into trouble when I started trying to use worker contexts in Dart. Its going to get even more complicated with houdini and its additional set of worker contexts so figured I'd voice issues now rather than later.

[matanlurey]

I respect not wanting to have a darty web worker/service worker API at this time. My first concern is about how stuff exposed in dart:* libraries would be usable in a worker context.

This is just me spit-balling a bit, but I imagine a web-worker or service-worker script would just be a Dart web application with a main() method - it wouldn't immediately know/not know it is running inside of a worker. You'd have to be safe and not use methods not available in a worker context - just like JavaScript.

As an example in Chrome's IDL there is https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/indexeddb/WorkerGlobalScopeIndexedDatabase.idl and https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/indexeddb/WindowIndexedDatabase.idl for the two different contexts of indexeddb.

I feel I should be able to have the same dart:indexed_db interfaces for dart:html and web worker contexts. So the IDL generation part should be conscious of this.

This is a bit harder of one. Of course, some smart package:indexed_db could do:

abstract class IndexedDb {
  factory IndexedDb() {
    if (inWorker) return new _WorkerIndexedDb();
    return new _WindowIndexedDb();
  }
}

My second concern is about compilation. I'm not sure if DDC would freak out when running in a worker context because of any magic happening with dart:* apis to make them nice and darty. There could be other issues around compilation as well.

I don't know specifically about DDC, though I'll defer to @jmesserly - Jennifer does DDC assume it is running in a windowed context? (I imagine if the answer is "yes" we can fix it, though it probably won't be a top priority)

Thanks for the replies here. I'm really looking forward to the Dart's 2.0+ future but wanted to make sure I didn't run into trouble when I started trying to use worker contexts in Dart. Its going to get even more complicated with houdini and its additional set of worker contexts so figured I'd voice issues now rather than later.

It would definitely be useful to create some sort of dart-web-worker-examples repository - at the very least we could give advice how to get everything working, even if we are missing some of the pieces.

/cc @jakemac53 on the build/DDC story, since we might need multiple entry-points?

[jmesserly]

I don't know specifically about DDC, though I'll defer to @jmesserly - Jennifer does DDC assume it is running in a windowed context? (I imagine if the answer is "yes" we can fix it, though it probably won't be a top priority)

I think DDC should be fine from a worker -- we can run on node and even barebones environments like d8 with a small polyfill script. We inherited code from dart2js SDK that appears to be designed for a worker environment. That said, I doubt it has gotten much testing. If there are bugs, they should be easy to address.

[MikeMitterer]

You remove mirrors without a clear strategy for reflections???? OMG!

These are the available technologies I am a ware of:

• Mirrors (after x years of Dart it gives still a warning if compiled to JS),
• Reflectable - nice, seems to get the most men power from Google,
• built_mirrors - https://pub.dartlang.org/packages/built_mirrors - also a nice approach,
• compilted_mirrors - https://pub.dartlang.org/packages/compiled_mirrors - nice 2

Reflections are essential for a modern language - please recommend one, clear strategy.

[munificent]

On the web (and to some extent our other platforms), Dart is:

• Ahead-of-time, statically compiled.
• Very focused on keeping the generated code size small.

Those constraints lean heavily towards doing metaprogramming statically (during the compile) instead of dynamically (at runtime). So most of our metaprogramming focus is on static tools right now. source_gen is a good package to take a look at. Ahead-of-time code generation is also how Angular templates are managed.

Reflection and mirrors — doing your metaprogramming while the program is running — is nice on VM- or image-based systems where code size doesn't matter and you already happen to have access to all of the underlying information at runtime. That's true in platforms like Smalltalk, the JVM, and the CLR. The designers of Dart hoped it would eventually be true of the Dart VM in the browser as well.

Now that that's not going to happen, I believe a static metaprogramming approach is a better fit for the language's compilation model and target platforms.

[MikeMitterer]

Thanks for your answer but it's a very general answer. A metaprogramming/reflection strategy from the Dart-Team should be out before Dart 2.0.

I think sometimes at Google you don't know how real world apps are built.

In my case my package "mdl" uses mirrors. I import "dice" for DI and "mustache" for templates - both of them are also using mirrors. Now what? Betting on the wrong horse is to expensive. I can't make my lib Dart 2 ready. I have to wait an see where the train goes. Very annoying.

Thats the problem with Dart - it's a nice language with nice ideas but approaches like this makes it look like a language in beta.

[daniel-v]

@wdevore my understanding is that the removal affects only browser targets. If you run your code on VM, you should be fine.

[matanlurey]

It's being removed from Dart2JS/Dart4Web only. Anybody using mirrors or isolates in the command-line VM can continue to do so. Flutter doesn't support mirrors, but isolates will continue to work.

For the web, we'll be focusing on supporting web technologies like web workers, service workers, animation workers - etc - which have different constraints than isolates.

For compilation, mirrors unfortunately just doesn't allow any kind of decent JavaScript output. In a world with lots of dynamic programming options, I'd probably suggest something like TypeScript, Flow, etc, if you truly need runtime reflection. Funny enough, even Angular TypeScript is soft-deprecating runtime reflection support for similar JavaScript code size issues.

We are investing hugely in code generation (pkg/source_gen, pkg/build_runner) for static meta-programming, so would love to know your thoughts on how we can better support your use-cases.

Cheers!

[Bluenuance]

So basically the idea that I can use code from my web application to a "vm-application" dies another little bit here?
Before I could use Isolates here and there. Now I have to use Isolates for VM and some Webworker (library or through js does not matter).
Really dislike the removal of Isolates for web :(

[matanlurey]

@Bluenuance

Now I have to use Isolates for VM and some Webworker (library or through js does not matter).

Yup, but as mentioned, I'm sure folks will have abstractions that target both. Web workers are better than isolates in almost every way (today), so we're excited that we'll be able to offer web users this API. On the other hand, Flutter may choose to at some point supporting, say, coroutines, which aren't implementable in the web at all.

[jmesserly]

Some dependency cleanup:
https://dart-review.googlesource.com/c/sdk/+/43581 removes dart:io dependency on dart:isolate
https://dart-review.googlesource.com/c/sdk/+/43860 removes dart:html dependency on dart:isolate

Neither dependency was used on dart4web, so this is purely a cleanup. Those CL's do not disable dart:isolate on dart4web.

[dgrove]

This needs to happen very soon if it's happening for 2.0

[sigmundch]

rules for conditional imports are implemented in dart2js now, we will however make dart:isolate produce runtime errors in a future version (likely in beta4). That's being tracked separately here: #32684

As soon as ddc returns false on dart.library.isolate, we can close this bug.

[sigmundch]

Jenny just fixed #30540

[jmesserly]

Jenny just fixed #30540

yeah although I still need to disable mirrors functionality (#32294) ... I'm fine with closing this one though, as it seemed to be about the configuration flags :)