pcattori

Yep, totally could do that. But I like I mentioned here (https://news.ycombinator.com/item?id=34659597) I wanted to keep the interfaces for `compileBrowser` and `compilerServer` since my mental model for it is that those two are "siblings".

The manifest is an artifact produced by the browser compilation, but it can be shared _before_ the browser compilation writes its results to disk.

I _could_ refactor to have "browser compilation phase 1", then assets manifest, and then "browser compilation phase 2", but that's not how I model it in my head. Plus it would mean a diverging interface for `compileBrowser` and `compileServer` which doesn't fit my mental model either.

So prefer to use channels instead.

The main trick on display here is that you can store a reference to the `resolve` method of a promise that normally would have to be called within the promise definition itself.

Of course, you don't need a channel abstraction to do that. To me, channels are the most intuitive and self-contained way to solve the problem, so I wanted to use that model of concurrency in JS.

Its a Typescript-ism for asserting that the value is not `undefined`. So you're telling the typechecker to trust you on this one

That's correct. The last three paragraphs of the article cover this and include links to libraries that have "full" channel implementations.

The point about "Inadequate data modelling facilities" is why I wrote Maps: https://github.com/pcattori/maps . Specifically, the "Named Maps" variants provide the same interface as `namedtuple` but for different levels of immutability/mutability.

Feedback/suggestions welcome!