proposal-built-in-modules
proposal-built-in-modules copied to clipboard
tc39
Not convinced of use cases
Here are what I understand as the reasons why the champions feel built-in modules should exist:
- Performance: Global objects increase code size and memory usage. Built-in modules give implementations more flexibility to perform optimizations.
- Code health: You should think of built-in modules the same way they think of third-party modules.
On point 1, if I recall correctly, we have heard from browser engine implementors that they are able to lazy-load global objects and achieve good performance. It's already a solved problem. Engines will still need to ship this lazy-loading logic so long as globals continue to exist.
On point 2, I see that argument, but the proposal also brings downsides to code health (main issue: #58).
I also don't understand this: the README says, "The JavaScript language does not have a standard library", which is simply not true; Intl, Regex, Map, and Set are all examples of standard library.
Built-in modules are a big change to the ecosystem, and I am not convinced that the suggested use cases carry enough merit to justify the disruption.
i would go further and argue that es-modules were a mistake.
sure js-rollups in browsers have issues, but they're all fairly manageable for product-developers and devops. es-modules, otoh, have caused product-developers nothing but endless grief, wasting our time firefighting bugs in unncessary tooling, instead of shipping ux-features.
A nice example of point 2 is functions that are defined on globalThis:
import { setTimeout, setInterval } from "js:timers";
setTimeout(/* ... */);
setInterval(/* ... */);
This is equivalent to:
const { setTimout, setInterval } = globalThis;
But the former feels cleaner. Usage of globalThis has been—to word it politely—a bit bumpy, linters, lint rules, and transpilers are sometimes still using the global name which appeared before the spec was finalized, meaning that—as developers—it is still kind of hard to figure out what is the name of the global object. With this proposal in place we could conceive a new lint rule no-global-object which forces us to always import the methods and namespaces we plan to use from the global object while we never have to think about what the name of the global object is.
any engine with these modules is guaranteed to have globalThis already, so no need to worry about which global name to use.
@devsnek The problem is that we developers don’t always write directly for the engines that our users are using, so if our transpilers, linters, or lint rules are not up to date (which—sorry to say—is the case with globalThis).
Does this proposal provide a means for the user to define what is in the standard library?
For example, AudioWorkletGlobalScope does not define Response or fetch().
It is currently impossible to import a native function across contexts.
Does this proposal provide a means to for the user to define Response and fetch() in the standard library, and import Response and fetch() into the AudioWorkletGlobalScope where those native functions are currently omitted on purpose by the designers of the API?
E.g.
import {Response, Request, fetch} from 'by_any_means_necessary_import_fetch_into_audio_worklet_global_scope'
@guest271314 those apis are part of browsers, not ecmascript. you might want to look at https://github.com/whatwg/fetch/ or https://github.com/whatwg/html/.
@devsnek Am banned indefinitely from WHATWG. For context see
- https://github.com/WebAudio/web-audio-api-v2/issues/73
- https://github.com/WebAssembly/design/issues/1350
- https://github.com/WebAudio/web-audio-api-v2/issues/79
This proposal would be particularly useful for importing and exporting whatever the user defined as a "standard library".
@devsnek Adding to the last sentence at https://github.com/tc39/proposal-built-in-modules/issues/59#issuecomment-663583198, "across browsing contexts". For example, setTimeout() and Performance https://github.com/WebAudio/web-audio-api-v2/issues/77 are also not defined in AudioWorkletGlobalScope. Where a built-in function is defined in one context, the ability to export that native function to a context where the native built-in is not defined.
@guest271314 within ecmascript it is not possible to move a function between agents. some host function appearing within multiple agents is at the discretion and ability of the host to create that function in both agents with some backing not described by ecmascript. this also isn't really on-topic for this issue.
within ecmascript it is possible to move a function between agents.
Can you kindly direct to where that functionality is specified and how to achieve that?
also isn't really on-topic for this issue.
Well, the title of the issue is "Not convinced of use cases".
Am stating a concise and explicit use case for this proposal. Why you concluded the above comments are not on-topic for this issue is not clear.
@guest271314 Sorry I left out a key word, edited to fix. within ecmascript it is not possible to move a function between agents. a specific host implementation could enable such a functionality but we cannot mandate it.
From a front-end perspective, here, the internal and intra-body politics and differentiation between Ecmascript, W3C/WHATWG, et al. specification are just that, politics. The goal is to achieve use cases, by any means. If one or all of the above bodies need to be on the same page for a use case to reach fruition, have no issue filing issues in each of those body's respective repositories' in order to at least ask.
within ecmascript it is not possible to move a function between agents
Yes. that is what encountered when trying to do so. This proposal does have the potential to be useful for that purpose. The user defines what is "standard library", not some external, absentee body that has its own self-imposed restrictions. import Request from std in AudioWorkletGlobalScope where the user exported Request to std in window would be useful, here.
To be direct, this is the use case that am stating should be included in this proposal.
@guest271314 useful perhaps, but we have no way to generalize that behaviour in the language. at best we could say "a host may mark certain builtin functions as usable with export F into std", and then the browsers would say "neat, we choose not to mark Request/fetch/etc as able to do that".
@guest271314 this proposal offers no additional cross-realm abilities that “having a module at a URL” does not already offer. It will not allow you to serialize functions or share module maps between workers. The use cases you’re describing are already possible with import(), and whether builtins are provided by global or Modules doesn’t affect that.
Yes, browsers do that anyway, now. If the question goes unasked then the answer is no anyway. On the other hand, browsers could implement such a mechanism, at the very minimum test the concept to analyze if anything breaks.
Concur with your assessment at OP. Not sure what this proposal adds as far as functionality.
The use cases you’re describing are already possible with
import()
Getting mixed signals now. AFAICT that functionality is currently impossible.
@ljharb import() is not defined in AudioWorkletGlobalScope, only import.
Ah, i didn’t realize that. I’d suggest advocating for that support then.
Fundamentally, functions can’t be serialized without language support, and it’s not something this proposal enables.
@ljharb Basically, it is impossible to test and verify the theory that defining fetch() in AudioWorkletGlobalScope, or, essentially, a "real-time" thread, will impact performace. So, wee have a theory, yet no way to verify the theory using scientific method.
If this proposal does not have specific intent, the comments that have posted so far should be construed as direct request to include the described functionality within the scope of the proposal, even if that means upstream changes.
Again, have no issues asking for functionality in whichever venue is necessary to be heard. If the answer is "no", then so be it. Will then, as with any endeavor that have and am engaged in, will proceed to attempt to achieve the requirement by any means. E.g., if capture of audio is not explicitly defined by a specification, experiment, test and eventually find a way to achieve the expected result, or determine if the requirement is impossible to achieve. In the cases of system audio capture https://github.com/guest271314/captureSystemAudio and SSML support for Web Speech API https://github.com/guest271314/SSMLParser there is no restriction from achieving the result, the respective governing organizations simply either have not saw fit to implement the capability, yet, i.e., is a WIP in some form, perhaps;https://github.com/w3c/permissions/pull/218; or just just not moving forward at all, even where technically possible https://github.com/WICG/speech-api/issues/10#issuecomment-619589378. Am not in to standing around watching someone else work, or waiting for some one else to do anything. Will ask, and ask more, until all remedies are exhausted, then, as Frantz Fanon described, the goal must be achieved by "any means necessary".
Unfortunately the only way to really get the answer to your question is to ask it in WHATWG. Does “any means necessary” include correcting the behavior that got you banned, apologizing to those you transgressed against, and working to get yourself unbanned, so you can ask the question in the proper place? That’s how I’d suggest moving forward. Good luck!
Do not apologize for asking questions. No behaviour needs to "corrected" from perspective here. Have been banned for asking questions, and perhaps not kowtowing to individuals who might believe themselves to be the smartest people in the room. Every post that make on any platform includes cites to primary sources, states facts, asks questions.
There was no "transgression". Individuals are sensitive, emotion and ego driven, and press a button to ban when they feel their little realm is not fully in their control, yet, in general have no formal appeals process for users to challenge the actions they take. Which is problematic from several perspectives. Have litigated to SCOTUS twice, by myself. To do that, generally, requires multiple appeals in District and Circuit Courts. These code and specification repositories do not understand law, and what it takes to litigate for 4 years up to the Supreme Court, they have not really challenged anything that adversely impacts them, so they have no clue, and dismiss appeals systems entirely: they do not have them. Further, they engage in hypocritical practices.
Do not do any begging here. Will create own or take over and topple before beg.
I would like to echo some of the concerns of @sffc here. I understood a similar motivation based on the explainer.
I would also like to add some of the ones presented in the slides, including namespace collisions (which are a sore point for the committee). The other goals feel like they are not so significant that it is worth splitting into two locations: global and the builtin modules.
One of the reasons that I would like to raise, that would show a significant enough motivation, was that this would allow Wasm to import DOM related APIs. I don't know if this is still important (cc @lars-t-hansen). At present, the motivation without this does not seem strong enough to outweigh the potential issues. I would be interested to see if there are more fundamental benefits that we could find here before saying this is a problem space that needs solving. cc'ing @annevk for visibility.
