Comments (1)
Thanks for the feedback, I hadn't thought of the cross-over so that's very interesting to consider.
I do wonder if loader customization could be seen to be a fully orthogonal problem which applies regardless, since surely importing evaluated modules would be the default under any custom loader scheme?
Specifically, how would a deferred loader would be defined? Loader evaluation hooks can be quite hard to specify without the loader effectively recreating most of the DFS algorithms, but perhaps that would be the way to do it. The risk there is the DFS algorithm invariants being broken in userland / it becoming too hard to construct a userland loader (as we've seen with Jest writing its own loader in Node.js to replicate the linking model internally resulting in lots of user issues).
Random idea - I wonder if a 'deferred'
evaluator attribute could make sense? What would it return for the namespace?
I think one of the driving pain points here is that Wasm modules are just easier to instantiate programmatically in many cases, since the interpretation steps do just end up more suited to the use case since the boundaries between Wasm compilations tend to require quite a bit of patching dynamic work especially while these interfaces are evolving so fast towards their final form. Also each compilation has its own specific linking needs, so being able to encapsulate the local toolchain linkage without a global loader having to recreate all the patching information for every single fine-grained Wasm import across a whole application is a huge benefit of this for Wasm. This is pretty much how all Wasm runs today, and I'm not sure we should change that? In contrast, in the ES module system the contract boundary is much simpler and much more respected throughout the ecosystem so global top-down conventions can be applied to the resolver like a single global import map.
In many ways it is quite natural to define attributes returning the naturally specified reflection we have today in WebAssembly.Module
and possibly for both JS and Wasm we could even have an import x from 'y' as 'block'
in future, effectively being the linked but unexecuted object as specified there. Enabling simple spec layering like this seems a very attractive aspect of this proposal to me. In this way we maintain equal capabilities of linking between JS and Wasm, even if their linking models themselves are slightly asymmetric (as they are anyway due to cycles) with Wasm using more nested programmatic instantiations, but otherwise sharing the simpler JS linking model where necessary. Over time I do think Wasm will unify on the JS linking model as conventions form, but these bridges at least get us there.
The other principle at play is just the one of enabling in JS what will be possible in Wasm - in some ways this proposal can be seen as JS playing catch up with interface types to ensure equal capability of the ability to import an unexecuted module without jumping through fetch hoops.
from proposal-source-phase-imports.
Related Issues (20)
- trusted type representation superceding asset references HOT 6
- Relationship to asset references proposal HOT 14
- Use extensible object syntax? HOT 68
- Use special module specifier format HOT 2
- Reflect string versus boolean HOT 2
- Lazy versus eager reflection HOT 2
- Reflect with transitive dependencies HOT 6
- Stage 3 reviews HOT 8
- Support both module reflection and module source reflection HOT 3
- Consider a method-like `import` metaproperty for source phase imports HOT 6
- Disallow newlines between phase and identifier HOT 1
- Consider cost of `import source from` ambiguity
- `export source x from "y"` HOT 4
- Missing sources should throw a *SyntaxError* when imported HOT 3
- Is %AbstractModuleSource% synchronously reachable from script? HOT 2
- Bikeshedding the `source` keyword HOT 17
- Bikeshedding the `source` keyword: voting HOT 16
- WebAssembly compile-time imports HOT 7
- "Source" is a little confusing HOT 1
- Implementation feedback: what's the deal with enforcing subclassing via [[ModuleSourceClassName]]? HOT 31
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-source-phase-imports.