We originally supported semantics along these lines, but we thought it was confusing to have 'dart:html' imported into a background isolate that could not possibly use it.

cc @a-siva.

I think the current behavior is also confusing, and more disruptive.
It prevents using Isolate.spawn in some settings, but a library won't know in advance in which settings it will run, so it can't program around it. That makes Isolate.spawn dangerous to use, which isn't good for a fundamental part of our isolate functionality.

If we allowed the spawn, but let the HTML library fail when it is used, we would allow more programs to run. Those that want to use the DOM in the new isolate will still fail, but those that just want to run some generic code can work, and libraries can use Isolate.spawn everywhere.

How much work would it be to reenable the original semantics?

This comment was originally written by @zoechi

What about httpRequest. This works in WebWorkers but not in Dart isolates. Would this work in an isolate if spawn were supported? (I saw a bug/feature request here about this very recently and this is also my primary use case)

Another option we discussed was to make Isolate.spawn in a dom isolate always create another dom isolate with access to dart:html, etc. This however, won't run in parallel - all dom isolates run in the UI thread.

Re-enabling throw-on-use is certainly doable, if we want to go that way.

Regarding workers, we've discussed implementing a library that provides an intersection of regular dom and worker apis - e.g., something like dart:browser (not really fond of that name though). An isolate using this library could work on dom or background.

Coming back to this, I'm not sure that time-sharing the DOM event thread is a good idea in general.
A library that want to do parallel computation would spawn an Isolate to do the computation. If that computation didn't run in a separate thread anyway, then library wouldn't work as expected (no parallelism where it is expected and desired is very likely to mean that it's very slow). For Isolate.spawn, which has access to the same code, running in the same thread removes all reason to use Isolate.spawn. You could just run the same code in a microtask instead.

I'd rather have Isolate.spawn always create a new thread, and have a specialized DOMIsolate.spawn that creates thread-sharing DOM isolates if that is ever desired.

There might be reason to have DOM-sharing Isolate.spawnUri calls, but again, it would probably be better to have to explicitly ask for that.

This comment was originally written by trent.grove...@workiva.com

In this vein, 1 related use case that I'd be interested in is the ability to support dynamically loaded 'plugins' in a web app.

For example, if I had a web app with multiple viewports, I'd like to be able to dynamically load (at runtime) some sort of visualization in a side panel. If an isolate could be used for this, while still providing access to the DOM, the side panel visualization options could be developed and versioned independently of the main core web app.

Is there any available approach to this sort of functionality in Dart at the moment? Or would you approach this dynamic visualization approach differently?

This comment was originally written by @zoechi

The only thing I can currently think of is to provide a messaged based API on the main isolate that receives messages from the plugin isolate and does the DOM related stuff for the plugin.

If possible, I'd prefer if we prioritized making Isolate.spawn work, even if the resulting isolate cannot access the DOM.

Until that is done, packages cannot use Isolates to do concurrent processing. A package doesn't know which kind of isolate it is run in, but it should be able to trust Isolate.spawn to run its own code concurrently. I'm ok with throwing on any access to the DOM.

If you also need DOM access, we can add a DOMIsolate.spawn function later, but that should not block fixing Isolate.spawn. In its current state, it is broken.

Issue #16209 has been merged into this issue.

Marked this as blocking #13921.

Sorry to append here so late, but I have a situation where I want to clone a piece of the DOM in the dom-enabled Isolate, do some long running work on it in a background Isolate (thread), then use the main dom-enabled Isolate to replace the fragment in the DOM. So, essentially, I want to process HTML Elements, without accessing the DOM, in another thread. Any thoughts on how to accomplish this would be useful.