| 13:20 | <littledan> | Text imports and asset references/URLS are orthogonal designs, my comments here are that URLs are a subpar experience because they are env specific |
| 13:20 | <littledan> | I was feeling more optimistic about them... |
| 13:22 | <littledan> | I'd note: If we go for a general key/value pair scheme, but make each key be built-in to JS syntax, maybe we could even handle reflective module imports that can be statically imported later--the problem becomes action at a distance, not logical impossibility |
| 13:23 | <littledan> | e.g., if the syntax is (strawperson!) import foo from "./foo.js", module |
| 16:01 | <Justin Ridgewell> | No, in these comments about asset references/URLs vs actual JS values, I'm explicitly saying the using an asset reference is subpar, because it is env specific |
| 16:02 | <Justin Ridgewell> | There was no intention of commenting on the syntax of the proposals (though I have opinions on that too) |
| 16:05 | <Justin Ridgewell> | It's been suggested a few times that asset references are a replacement for the ability to import text |
| 16:05 | <Justin Ridgewell> | In the strict sense, yes, because they'd allow me to reference and access the asset the same way we currently do for URLs |
| 16:06 | <Justin Ridgewell> | But that doesn't make it a good experience to use, it just means it's better than the current URL approach (which is awful) |
| 18:57 | <Kris Kowal> | I like to tease apart the motivating use cases. I think there are cases where URLs are necessary, but the current approaches miss an opportunity to statically express dependency on a URL asset (and its transitive dependencies) in a way that bundlers could see. Embedded binary assets are useful for different things too, not least of which is that they don’t couple a mechanism for reading them, so they’re necessarily more portable. |
| 18:59 | <Kris Kowal> | Then all the remaining embedded asset types follow from the various treatments you can make on the binary, particularly UTF-8 text, but also others. An interesting dimension to that problem is that each of those cases has potentially different treatments at runtime or bundle time, and those treatments can be environment-specific. |
| 19:02 | <Kris Kowal> | For example, with Guten Tags, there’s a treatment for HTML. During development, it translates the HTML to JavaScript on the client, but for production, the translation occurs in the bundler (in a compartment that can see the dev dependencies, and ideally producing a module that executes in a corresponding compartment with access to the translator’s prod dependencies). There could be alternate treatments that use virtual module sources and interpret the HTML at runtime. And a key feature here is that the surrounding mechanism dictates whether you get an implementation of the translator that uses the DOM for parsing HTML, or brings in JSDOM for the bundler. |
| 19:05 | <Kris Kowal> | Concretely, bundling with a “text” loader implies very different trade-offs depending on whether you’re compiling to an archive or a bundle. With an archive, it makes sense to keep the original binary and use a virtual module source to decode it to a string on the fly. For a stringy bundle, it makes more sense to translate the asset to JavaScript. |
| 19:22 | <Kris Kowal> | cc naugtur |
| 19:25 | <Kris Kowal> | Mentioning here because I aspire to add translators as a feature to Endo’s compartment mapper, and it strikes me that translated modules would need to run in a synthetic compartment that has is internally identical to the source package, but additionally has access to the prod dependencies of the translator package. In Guten Tags, I wanted to write a translator for a custom bindings language that would necessarily need access to certain runtime components that the destination package didn’t necessarily have access to. |
| 19:25 | <Kris Kowal> | Specifically, observer utilities, like the ones you see in stuff like immer. |
| 19:26 | <Kris Kowal> | Because it’s prohibitively expensive and unnecessary to entrain the entirely of a runtime like FRB https://github.com/kriskowal/frb |
| 21:04 | <littledan> | Hey, could someone with permissions invite @peetk:matrix.org ? |
| 21:04 | <littledan> | This is a coworker of mine in Bloomberg |