Some wanky theory about computing and the design of programs follows. (Not out of scope considering the philosophical underpinnings of this product and the "edge", etc.)
The chat demo says:
> With the introduction of modules, we're experimenting with allowing text/data
blobs to be uploaded and exposed as synthetic modules. We uploaded `chat.html`
as a module of type `application/octet-stream`, i.e. just a byte blob. So when
we import it as `HTML` here, we get the HTML content as an `ArrayBuffer`[...]
import HTML from "chat.html";
I've thought a lot about this for the work that I've been doing. From an
ergonomics standpoint, it's really attractive, and the only other viable
alternatives are (a) dynamically reading the asset, or (b) settling on using
some wrapper pattern so the original asset can be represented in the host
language, e.g.:
export const IMAGE_DATA =
"iVBORw0KGgoAAAANSUhEUgAAAD8AAAA/..." +
"..."
export const HTML = `
<!-- totally the HTML I wanted to use -->
`;
... which is much less attractive than the "import" way.
Ultimately I ended up going with something closer to the latter, and there wasn't even any reluctance about it on my part by the time I made the decision—I was pretty enthusiastic
after having an insight verging on a minor epiphany.
I'd been conflicted around the same time also about representing "aliens" (cf
Bracha) from other languages and integrating with them. I slapped my head
after realizing that the entire reason for my uneasiness about the latter "data islands"
approach was because I wasn't truly embracing objects and that these two problems (foreign integration and foreign representation) were very closely related. Usually you don't actually want `HTML`,
for example, and focusing on it is missing the forest for the trees. I.e.,
forget whatever you were planning with your intention to leave it to the
caller/importer to define procedures for operating on this inert data. Make it a class
that can be instantiated as an object that knows things about itself (e.g.
the mimetype) and that you can send messages to, because that's what your
program really wants it to be, anyway. Once you're at that point, the "wrapper" approach is much more palatable, because it's really not even a wrapper anymore.
The chat demo says:
> With the introduction of modules, we're experimenting with allowing text/data blobs to be uploaded and exposed as synthetic modules. We uploaded `chat.html` as a module of type `application/octet-stream`, i.e. just a byte blob. So when we import it as `HTML` here, we get the HTML content as an `ArrayBuffer`[...]
I've thought a lot about this for the work that I've been doing. From an ergonomics standpoint, it's really attractive, and the only other viable alternatives are (a) dynamically reading the asset, or (b) settling on using some wrapper pattern so the original asset can be represented in the host language, e.g.: ... which is much less attractive than the "import" way.Ultimately I ended up going with something closer to the latter, and there wasn't even any reluctance about it on my part by the time I made the decision—I was pretty enthusiastic after having an insight verging on a minor epiphany.
I'd been conflicted around the same time also about representing "aliens" (cf Bracha) from other languages and integrating with them. I slapped my head after realizing that the entire reason for my uneasiness about the latter "data islands" approach was because I wasn't truly embracing objects and that these two problems (foreign integration and foreign representation) were very closely related. Usually you don't actually want `HTML`, for example, and focusing on it is missing the forest for the trees. I.e., forget whatever you were planning with your intention to leave it to the caller/importer to define procedures for operating on this inert data. Make it a class that can be instantiated as an object that knows things about itself (e.g. the mimetype) and that you can send messages to, because that's what your program really wants it to be, anyway. Once you're at that point, the "wrapper" approach is much more palatable, because it's really not even a wrapper anymore.