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?