Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Jan Krems]

> If I understand HTTP/2 correctly, this requires more than a server
> that simply has HTTP push, it requires a server that understands how
> to read ES modules and enumerate their dependencies.

Not only that: The server also has to "know" which modules are already
cached by the client (including potential match/modified-since logic). If
the server always sends _all_ modules in the dependency graph, then it's
just a less efficient bundle of all modules.

Afaik the more promising path are prefetch hints on the client. E.g. the
client (or initial HTML payload) knows the dependency tree, adds tags
for preloading the required modules, and then the browser can properly
handle fine-grained caching from there, only requesting what is actually
needed.

Cheers,
Jan

On Mon, Oct 12, 2020 at 12:59 PM #!/JoePea  wrote:

> I'm asking about a server that, upon request of a `.js` file, knows
> how to enumerate the dependency tree based on that file, _then_ HTTP
> pushes all the modules at once.
>
> So basically, from the code
>
> ```html
> 

Re: es-discuss Digest, Vol 161, Issue 2

[Jan Krems]

The current answer is in the current spec for HostResolveImportedModule

:

> Each time this operation is called with a specific
referencingScriptOrModule, specifier pair as arguments
> it must return the same Module Record instance if it completes normally.

In other words: The runtime generally cannot safely collect modules because
all modules are "always" referenced
by the thing that imported it. It gets more strict in HTML where all
modules are globally referenced in the "module
map". So even when it *looks* like a module isn't referenced by previous
kinds of references (object properties etc.),
there really isn't such a thing as an "unreferenced" module as long as the
realm/context is alive.

In short: There's no "module cache" in ES modules, it's an append-only
module map.

This also means that if you expect something to require GC, you maybe
shouldn't be loading it as a module. E.g.
JSON loaded via some future import mechanism would never be GC'd. In the
fictional example of the huge MMORPG
with many planets, you'd likely want to load the things you care about
GC'ing via fetch() or some other mechanism
that allows managing lifetime yourself.[1]

Cheers,
Jan

On Wed, Jul 1, 2020 at 5:00 AM  wrote:

> Send es-discuss mailing list submissions to
> es-discuss@mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
>1. Re: Are ES Modules garbage collected? If so, do they
>   re-execute on next import? (Isiah Meadows)
>
>
>
> -- Forwarded message --
> From: Isiah Meadows 
> To: Andrea Giammarchi 
> Cc: Isiah Meadows , Gus Caplan ,
> es-discuss 
> Bcc:
> Date: Wed, 1 Jul 2020 00:47:30 -0700
> Subject: Re: Are ES Modules garbage collected? If so, do they re-execute
> on next import?
> That's part of the caching I'm referring to. And if the cache entry
> for it has been evicted, I would *not* expect it to necessarily return
> the same instance, consistent with the behavior with `require` and
> `require.cache` in Node (and similar with most other module loaders
> that support cache eviction).
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Tue, Jun 30, 2020 at 11:57 PM Andrea Giammarchi
>  wrote:
> >
> > even if dereferenced, a dynamic import could re-reference it any time,
> and I would expect it to still be the same module, it'd be a surprise
> otherwise (cached things, same namespace checks, etc).
> >
> > On Wed, Jul 1, 2020 at 7:33 AM Isiah Meadows 
> wrote:
> >>
> >> Just to expand on that, if the module record itself is dereferenced
> >> (like if it's evicted from the cache somehow), then yes, it should be
> >> collected as appropriate. However, I'm not aware of any major
> >> implementation that offers that functionality.
> >>
> >> -
> >>
> >> Isiah Meadows
> >> cont...@isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >> On Tue, Jun 30, 2020 at 6:22 PM Gus Caplan  wrote:
> >> >
> >> > Modules in the spec are cached by specifier by modules that import
> them. Modules in major implementations are additionally cached for the
> entire realm by absolute URLs. I would say that for actual code (functions
> and classes and whatnot) leaks aren't really a problem. Even if you import
> a ton of levels, that's not that much memory. The main concern I've seen
> raised is JSON modules, where once you import them the JSON object, which
> can be quite large, will never be collected. Of course, there is a simple
> solution to that (fetch) so it isn't a world ending problem.
> >> >
> >> > On Tue, Jun 30, 2020 at 7:41 PM #!/JoePea  wrote:
> >> >>
> >> >> I am curious: can modules be garbage collected if the exports are not
> >> >> references by anything anymore? And if so, will the module be
> >> >> re-evaluated the next time it is imported?
> >> >>
> >> >> I haven't tried an experiment to answer this yet. I'll be back to
> post
> >> >> findings if someone doesn't post an official answer first.
> >> >>
> >> >> I'm thinking about code longevity. For example, if we make
> >> >> long-running web-based applications with many routes and features
> (for
> >> >> sake of example imagine a desktop environment, or a MMORPG game, with
> >> >> apps or components that are loaded within the same context). Over
> >> >> time, if imports are not collected, then it means we have a memory
> >> >> leak.
> >> >>
> >> >> Imagine, for example, an infinite-universe MMORPG where you can land
> >> >> on different planets where the code for features of a planet are
> >> >> provided by third parties as 

Re: Officially support a shebang line

[Jan Krems]

> What is an example use-case that would take advantage of this proposal?

There's quite a few scripts in "node land" that can be both entry point
(executable) and library. The rough idea is:

```
#!/usr/bin/env node
function myLibraryFunction(filename) {}
module.exports = myLibraryFunction;
if (process.mainModule === module) {
  console.log(myLibraryFunction(process.argv[2]));
}
```

It's not that uncommon for languages with C-like comment syntax to have
special support for shebang "comments" in the first line. Prior work
includes:

* F# ("3.8.4 Shebang"):
http://fsharp.org/specs/language-spec/4.0/FSharpSpec-4.0-latest.pdf
* Groovy ("1.4. Shebang line"):
http://groovy-lang.org/syntax.html#_shebang_line
* Lua (only mentions the entry point but it also works in required
modules): https://www.lua.org/manual/5.3/manual.html#7

For many other languages that can be used as executable scripts (*sh, Perl,
PHP, Ruby, Python), the problem doesn't exist because they already allow #
as line comments everywhere. Adding official support to JS would close a
gap to most other scripting languages.

On Fri, May 19, 2017 at 8:15 AM Wes Garland <w...@page.ca> wrote:

> In gpsee (using spidermonkey), we allow executable programs exactly the
> same way as a shell script, and there is no real penalty from a JavaScript
> parsing POV.  I'm not sure why node+v8 would be any different.  We just
> hand over the script to the parser with the pointer pointing to the newline
> at the end of the shebang.  This skips the syntax error and keeps the line
> numbers as expected.  As Alexander Jones explains, this shebang support
> stuff is deep in unix, and arrives by virtue of the exec-and-friends system
> calls declared in unitstd.h.
>
> I suppose the one 'gotcha' here is that you can't have a module which can
> both act as a program and library.  We have the similar limitations in C -
> we have a special object file which has a symbol named 'main' and usually
> load library code as DSOs - but I never really found that to be a
> significant limitation in real-world work.
>
> What is an example use-case that would take advantage of this proposal?
>
> Wes
>
>
> On 19 May 2017 at 10:25, Jan Krems <jan.kr...@gmail.com> wrote:
>
>> Sorry, mentioning support in syntax highlighters might have been
>> misleading. I am talking specifically about executable JavaScript scripts
>> and modules. It's a common pattern in node to have programs written in
>> JavaScript, with a shebang and the x flag set.
>>
>> I just mentioned editor / syntax highlighter support to say "this is
>> already de-facto part of real life JavaScript as it's understood by tools,
>> it's just missing from the spec".
>>
>> On Fri, May 19, 2017 at 1:44 AM Alexander Jones <a...@weej.com> wrote:
>>
>>> It doesn't make any sense. The shebang is a UNIX way of declaring the
>>> interpreter for an executable script, not for hinting your syntax
>>> highlighter. If your file is not executable (as in, it can't be run with
>>> `./filename`, it shouldn't have a shebang).
>>>
>>> On 19 May 2017 at 02:44, Jan Krems <jan.kr...@gmail.com> wrote:
>>>
>>>> Tried to search past proposals for this but couldn't find one The short
>>>> version: Most editors / syntax highlighting engines, non-engine parsers,
>>>> node.js - they all support a leading shebang line in .js files. With the
>>>> advent of ES6 modules it's the final holdout where node has to patch the
>>>> script source to make V8 parse the code (and thus producing a mismatch
>>>> between what's on disk and what the engine sees).
>>>>
>>>> Is there a downside to allow any script or module to begin with the
>>>> magical #! bytes? It should not break existing scripts because it's invalid
>>>> syntax today & the parse overhead should be fairly limited.
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102 <(613)%20542-2787>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Officially support a shebang line

[Jan Krems]

Sorry, mentioning support in syntax highlighters might have been
misleading. I am talking specifically about executable JavaScript scripts
and modules. It's a common pattern in node to have programs written in
JavaScript, with a shebang and the x flag set.

I just mentioned editor / syntax highlighter support to say "this is
already de-facto part of real life JavaScript as it's understood by tools,
it's just missing from the spec".

On Fri, May 19, 2017 at 1:44 AM Alexander Jones <a...@weej.com> wrote:

> It doesn't make any sense. The shebang is a UNIX way of declaring the
> interpreter for an executable script, not for hinting your syntax
> highlighter. If your file is not executable (as in, it can't be run with
> `./filename`, it shouldn't have a shebang).
>
> On 19 May 2017 at 02:44, Jan Krems <jan.kr...@gmail.com> wrote:
>
>> Tried to search past proposals for this but couldn't find one The short
>> version: Most editors / syntax highlighting engines, non-engine parsers,
>> node.js - they all support a leading shebang line in .js files. With the
>> advent of ES6 modules it's the final holdout where node has to patch the
>> script source to make V8 parse the code (and thus producing a mismatch
>> between what's on disk and what the engine sees).
>>
>> Is there a downside to allow any script or module to begin with the
>> magical #! bytes? It should not break existing scripts because it's invalid
>> syntax today & the parse overhead should be fairly limited.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Officially support a shebang line

[Jan Krems]

Tried to search past proposals for this but couldn't find one The short
version: Most editors / syntax highlighting engines, non-engine parsers,
node.js - they all support a leading shebang line in .js files. With the
advent of ES6 modules it's the final holdout where node has to patch the
script source to make V8 parse the code (and thus producing a mismatch
between what's on disk and what the engine sees).

Is there a downside to allow any script or module to begin with the magical
#! bytes? It should not break existing scripts because it's invalid syntax
today & the parse overhead should be fairly limited.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss