Re: Importing modules inside HTML imports
On Sun, Aug 17, 2014 at 8:52 PM, John Barton johnjbar...@google.com wrote: The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts. If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great. It seems you did not read what I wrote. CSP does support inline scripts these days. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls
Hi, Exploring how web browsers implement Array.protototype.sort, I've found two patterns: On the one hand, Firefox (SpiderMonkey) and IE (Chakra) have three distinct phases: 1. Get the values from the target, in ascending order of the keys (from 0 to the length exclusively) (using [[HasProperty]] + [[Get]]); 2. Perform a series of calls to the comparison function, using the values found in the previous step as arguments, in order to sort them; 3. Put the sorted values on the target, in ascending order of the keys (using [[Set]], or sometimes [[Delete]] in case of sparse array). On the other hand, in Safari (JSC), Chrome and Opera (V8), calls to the comparison function are intermingled with getting and putting the values of the target. It is more or less as follows (omitting minor complications irrelevant to the discussion): 1. Repeat, until finished: a. Get the values from the target for two keys (using [[HasProperty]] + [[Get]]); b. Perform (if necessary) a call to the comparison function, using the values found in previous step as arguments; c. If necessary, put partially sorted values on the target for keys recently visited (using [[Set]], or sometimes [[Delete]] in case of sparse array). The SpiderMonkey/Chakra behaviour seems more appropriate for the following reasons: * Since the sorting phase is completely isolated from the retrieving/putting phases, even if the target has strange read/write semantics, that cannot make the sort algorithm go nuts (provided that the comparison function is sufficiently consistent, anyway). * The number of read/write accesses to the target is minimized, which is a win if the target is an object with slow read/write semantics (e.g., an object with convoluted getters/setters). * The order and the moment of each read/write access is exactly determined, so that the result is more predictable, even when confronted to a strange-behaving target, (provided that the comparison function doesn't do strange things). Therefore, I think we ought to normalise the SpiderMonkey/Chakra behaviour. (Currently, the specced semantics is nearer to the one of JSC/V8.) —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls
Do you have any examples of real-world issues caused by this difference? If not, I don't think we should spec the behavior of .sort any more than it is right now. (Well, I'd argue for requiring a stable sort, but then that's easy for me as an implementor working on an engine that already has a stable sort.) The reason is the same as for the way .sort is currently specced: to enable experimentation and substantial changes to implementations in an area where meaningful changes in performance characteristics are to be expected. These changes aren't likely to be gained by substantial advances in sorting itself, granted. However, changes of performance characteristics of other parts of the engine (say, memory allocation, reading Array elements, or invocation of getters/setters) might make algorithms feasible for an implementation that weren't, before. Case in point, in SpiderMonkey we're likely to switch to a self-hosted implementation of, probably, Timsort, soon-ish[1]. This will change our implementation's behavior in precisely those characteristics you propose to standardize. In the future, we might experiment with parallelizing parts of the sorting. This might force us to read all values once and only write the fully-sorted array back in the end, but it might also not, and precluding a more efficient implementation for theoretical concerns would be bad. Note also that, by my reading of the spec at least, all implementations currently fully adhere to the spec: they [p]erform an implementation-dependent sequence of calls to the [[Get]] and [[Set]] internal methods of obj, to the DeletePropertyOrThrow abstract operation with obj as the first argument, and to SortCompare. My reading of this is that implementation-denendent sequence refers to all four mentioned functions, where an implementation might either intermix all of them (like v8/JSC do) or first do a (sub-)sequence of only [[Get]] calls and then a second (sub-)sequence intermixing calls to all the other functions (like Chakra/SpiderMonkey). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=715181 On Mon, Aug 18, 2014 at 12:22 PM, Claude Pache claude.pa...@gmail.com wrote: Hi, Exploring how web browsers implement Array.protototype.sort, I've found two patterns: On the one hand, Firefox (SpiderMonkey) and IE (Chakra) have three distinct phases: 1. Get the values from the target, in ascending order of the keys (from 0 to the length exclusively) (using [[HasProperty]] + [[Get]]); 2. Perform a series of calls to the comparison function, using the values found in the previous step as arguments, in order to sort them; 3. Put the sorted values on the target, in ascending order of the keys (using [[Set]], or sometimes [[Delete]] in case of sparse array). On the other hand, in Safari (JSC), Chrome and Opera (V8), calls to the comparison function are intermingled with getting and putting the values of the target. It is more or less as follows (omitting minor complications irrelevant to the discussion): 1. Repeat, until finished: a. Get the values from the target for two keys (using [[HasProperty]] + [[Get]]); b. Perform (if necessary) a call to the comparison function, using the values found in previous step as arguments; c. If necessary, put partially sorted values on the target for keys recently visited (using [[Set]], or sometimes [[Delete]] in case of sparse array). The SpiderMonkey/Chakra behaviour seems more appropriate for the following reasons: * Since the sorting phase is completely isolated from the retrieving/putting phases, even if the target has strange read/write semantics, that cannot make the sort algorithm go nuts (provided that the comparison function is sufficiently consistent, anyway). * The number of read/write accesses to the target is minimized, which is a win if the target is an object with slow read/write semantics (e.g., an object with convoluted getters/setters). * The order and the moment of each read/write access is exactly determined, so that the result is more predictable, even when confronted to a strange-behaving target, (provided that the comparison function doesn't do strange things). Therefore, I think we ought to normalise the SpiderMonkey/Chakra behaviour. (Currently, the specced semantics is nearer to the one of JSC/V8.) —Claude ___ 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
Re: Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls
Le 18 août 2014 à 12:59, Till Schneidereit t...@tillschneidereit.net a écrit : Note also that, by my reading of the spec at least, all implementations currently fully adhere to the spec: they [p]erform an implementation-dependent sequence of calls to the [[Get]] and [[Set]] internal methods of obj, to the DeletePropertyOrThrow abstract operation with obj as the first argument, and to SortCompare. My reading of this is that implementation-denendent sequence refers to all four mentioned functions, where an implementation might either intermix all of them (like v8/JSC do) or first do a (sub-)sequence of only [[Get]] calls and then a second (sub-)sequence intermixing calls to all the other functions (like Chakra/SpiderMonkey). Nit: As currently specced, SortCompare includes obligatory calls to [[HasProperty]] and [[Get]] on some keys before invoking the comparison function: so, SpiderMonkey/Chakra don't adhere to the specs. Even JSC/V8 don't fully adhere to the spec on this point, because (as I've observed) they may omit a call to [[HasProperty]]/[[Get]] when the value is known. But I think it is a spec bug that can be corrected, in order to make all current implementations compliant (SortCompare should take the values, not the keys, as arguments). —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls
On Mon, Aug 18, 2014 at 1:32 PM, Claude Pache claude.pa...@gmail.com wrote: Le 18 août 2014 à 12:59, Till Schneidereit t...@tillschneidereit.net a écrit : Note also that, by my reading of the spec at least, all implementations currently fully adhere to the spec: they [p]erform an implementation-dependent sequence of calls to the [[Get]] and [[Set]] internal methods of obj, to the DeletePropertyOrThrow abstract operation with obj as the first argument, and to SortCompare. My reading of this is that implementation-denendent sequence refers to all four mentioned functions, where an implementation might either intermix all of them (like v8/JSC do) or first do a (sub-)sequence of only [[Get]] calls and then a second (sub-)sequence intermixing calls to all the other functions (like Chakra/SpiderMonkey). Nit: As currently specced, SortCompare includes obligatory calls to [[HasProperty]] and [[Get]] on some keys before invoking the comparison function: so, SpiderMonkey/Chakra don't adhere to the specs. Even JSC/V8 don't fully adhere to the spec on this point, because (as I've observed) they may omit a call to [[HasProperty]]/[[Get]] when the value is known. But I think it is a spec bug that can be corrected, in order to make all current implementations compliant (SortCompare should take the values, not the keys, as arguments). Oh, you're right. And I agree: SortCompare should take values. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Aug 17, 2014 at 8:52 PM, John Barton johnjbar...@google.com wrote: The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban inline scripts. If the argument is wrong, ignore my advice, CSP will die. I personally think that would be great. It seems you did not read what I wrote. CSP does support inline scripts these days. So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the unsafe-inline value to opt out of the restriction? Some of the sites that make me think this has not changed: http://www.w3.org/TR/CSP/ In either case, authors should not include 'unsafe-inline' in their CSP policies if they wish to protect themselves against XSS. https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives *Note:* Both 'unsafe-inline' and 'unsafe-eval' are unsafe and can open your web site up to cross-site scripting vulnerabilities. http://content-security-policy.com/ jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote: So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the unsafe-inline value to opt out of the restriction? Neither. See https://w3c.github.io/webappsec/specs/content-security-policy/ for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote: So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the unsafe-inline value to opt out of the restriction? Neither. See https://w3c.github.io/webappsec/specs/content-security-policy/ for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.) Excellent thanks! Hope those new features are adopted and servers routinely implement the hash-source feature. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Smarter Module Instance Object
So today I was thinking about the possibility of having the module instance object be a function. If it were a function with fairly simple code to check if the default exports is also a function and if so then apply-invoke it then you would have a much more useful module instance object. If you were to do this then either changing it so the unnamed import returned the module instance object/function instead of the default export OR using the new `import * as mod from module` syntax would get you what you want much more often than previously. Here's a gist with kind of what I am saying: https://gist.github.com/matthewrobb/1cfd9e10f8d70d4fb524 There are a few limitations to this like some of the non-configurables of functions but it's possible it could instead be a proxy that supports a call trap or what have you. Just a thought and I'm sure there are good reasons it's a stupid thought, just figured I'd rather know why than say nothing. - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Various Loader-related e-mails
To avoid overly spamming the list I've coallesced my responses to various threads over the weekend into this one e-mail. On Fri, 15 Aug 2014, John Barton wrote: But since the only way the client can know that it needs a.js and jquery.js is if the server tells it [...] There's at least four ways this can happen [...] 2: the server sends the browser all three files at once, preemptively. [...] The second is too slow, because it implies sending resources that aren't needed, possibly using up bandwidth that could be used for other purposes. It's something that can be supported by packaging and other solutions already being developed, if people want it. The second method is faster than your method. It results in the same three file transfer in one less round trip. The second method does not imply sending any more or less resources than any other method listed. The second is too slow because there's lots of other files involved in practice, for example the default style sheet, the scripts that are needed straight away, the Web components that are needed straight away, all the default images, etc. The whole point of the discussion in this thread is that we're talking about files that are not needed straight away, and how to obtain them promptly once they are needed. Loading all of the files in a web page in the order they are needed is great goal and one that I think would make a great improvement in the Web. It is certainly true that data for pages is chunky: we need a mechanism for loading a group of related files at the right time. Within each chunk we need all of the files if we need the root of the chunk. But that is exactly the ES6 case: if we need the root of the dependency tree, then we need all of the tree, that is the declarative design. Having a design where the browser gets all the names, sends all the names back to the server, and gets the tree is just wasting a trip. Simply send the tree when the browser asks for the tree. That's why in my opinion 'bundles' or 'packages' make sense: they combine the related dependencies and allow them to be loaded in one trip. Divide this problem in to small pieces: ES6 bundles, HTML Imports, and some bundle/package loading solution. Don't use the same fine-grained solution for all layers. This just doens't work. Suppose the dependency graph looks like this: Feature A -- Dependency A1 \__\ Dependency\ Feature B -- Dependency B1 / /AB -- Dependency D Feature C -- Dependency C1 --- Dependency C2 / All of A, B, and C are to be fetched on-demand-only, to avoid using up too much bandwidth. All the files here are non-trivial in size. How do you package this? If you make a package for A, a package for B, and a package for C, then you'll have redundant content in the packages, and when the client asks for B after already having asked for A, the amount of content sent back will be greater than necessary and therefore it'll be slower than necessary. If you create multiple packages such that you group as much as possible into each package as possible without overlap, then you still end up with multiple resources to download when you need any of A, B, or C. Basically, it boils down to: Package A \__\ Package\ Package B / /AB -- Package D Package C - / ...and then you're back to the problem I asked about. If you don't have server-side support, then to avoid round-trips the client needs to know about the dependencies before it makes the first request. It can't wait til it receives the packages to discover the dependencies because if you do that then you're serialising your RTTs instead of pipelining them. The fourth is what I'm looking at. The fourth consists of the server having no built-in knowledge except what is in-band in the HTML file, namely, predeclared dependency trees. By humans writing markup? That's not happening, at least not for more than trivial programs. It turns out that on the Web, there are lots of trivial programs. When you have trillions of Web pages, even the smallest of fractions ends up being significant numbers of pages. Such programs don't need the kind of features we are discussing. There are applications that cover the entire spectrum from trivial one-file apps to gigantic monsters with thousands of packages containing each dozens of resources. Within this spectrum, you find applications that are satisfied by today's features, and you find applications that will need HTTP2 and be able to use all the fancy server-side support. But you also find, near the middle of the spectrum, applications that are complicated enough to need dependency management, and yet not high-profile enough to get server-side support. No one is going to write hundreds of lines
Modules and dependencies found during the load (before instantiation)
On Wed, 13 Aug 2014, Ian Hickson wrote: One of the problems I'm running into when it comes to trying to integrate ES6 modules with HTML and new HTML-based dependency features is the way that I can't tell ES about dependencies I know about before the data is actually fetched and instantiated. Another example of where we have something like this is HTML imports. The fetch hook for HTML imports needs to actually be the hook that does all the parsing, since HTML loads incrementally. (For HTML imports, the translate and instantiate hooks are essentially no-ops.) This means that the in-band dependencies for HTML imports are found during the fetch hook, and need to be set up right away. For example, if an HTML import contains a script type=module block, that inline module needs to be added as dependency of the import itself (so that the import's 'load' event doesn't fire until all internal modules are loaded). It it contains an img src= element, that needs to be added as a dependency as its loading. This is similar to the instantiate hook adding dependencies, except that it has to happen earlier due to the incremental parsing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Referencing modules loaded by HTML Imports.
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: To avoid overly spamming the list I've coallesced my responses to various threads over the weekend into this one e-mail. I really think this makes the discussion more difficult to follow and certainly more difficult to participate in. Now, in the main page, you reference the HTML import: link rel=import href=foo.html Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document. Separate document implies separate JS global: each needs its own Loader. So the rest of the questions aren't needed. HTML imports definitely need to expose modules across documents. Are you saying this requires changes to ES6 to support? What changes would we need? You need to give more details about such requirements. What is the runtime relationship between Imports and other documents? I assume the Import is providing some state that ends up in the importer but then you are saying these are different documents. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Changing dependencies during the load process.
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: The ES Loader does not maintain a dependency tree. It maintains a table of names-modules. Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record [[Dependencies]] list? The dependencies for the Load. Once the load is complete the record is not needed. How about if the dependencies are changed during the load? For example: script id=a src=a.js load-policy=when-needed/script This seems like an unfortunate design choice script id=b src=b.js load-policy=when-needed/script script id=c needs=a ... /script script // at this point, the script with id=c is blocked waiting for a.js to // load. Let's change its dependencies: document.scripts.c.needs = 'b'; ...which leads to exotic quirks like this. // now the script needs to trigger b.js to load // a.js' load can be deprioritised (or canceled, if network is at a // premium), and no longer blocks the script from loading /script System.import already supports dynamic loading with runtime dependency selection. If you have a problem with it let's discuss that before redesigning it. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Importing modules inside HTML imports
John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside with the original HTML that will mimic the use of inline scripts but behaves like an external script. Essentially, you will have: `script src=/my-sticky-data-and-initialization-per-page.js/script`, while that script is actually sent thru the SPDY multi-plex, which means no roundtrip is issued, no perf penalty, and it complies with CSP restrictions, the best of both worlds! /caridy On Aug 18, 2014, at 11:35 AM, John Barton johnjbar...@google.com wrote: On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote: So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the unsafe-inline value to opt out of the restriction? Neither. See https://w3c.github.io/webappsec/specs/content-security-policy/ for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.) Excellent thanks! Hope those new features are adopted and servers routinely implement the hash-source feature. jjb ___ 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
Re: Importing modules inside HTML imports
Sounds promising, but the key use case cited by Brendan is ease-of-use so it's important that all of this happens by default as far as Web devs are concerned. On Mon, Aug 18, 2014 at 11:23 AM, caridy car...@gmail.com wrote: John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside with the original HTML that will mimic the use of inline scripts but behaves like an external script. Essentially, you will have: `script src=/my-sticky-data-and-initialization-per-page.js/script`, while that script is actually sent thru the SPDY multi-plex, which means no roundtrip is issued, no perf penalty, and it complies with CSP restrictions, the best of both worlds! /caridy On Aug 18, 2014, at 11:35 AM, John Barton johnjbar...@google.com wrote: On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote: So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server set the unsafe-inline value to opt out of the restriction? Neither. See https://w3c.github.io/webappsec/specs/content-security-policy/ for the new nonce-source and hash-source features. (Don't read TR/, it's kind of equivalent to reading the previous version of ES, but worse.) Excellent thanks! Hope those new features are adopted and servers routinely implement the hash-source feature. jjb ___ 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
Proposal: Promise.prototype.Finally
I created the following gist as a proposal for the addition of a `finally` method to the prototype of the Promise constructor, either for ES6 (if such a thing is considered valuable and could be fast tracked at this date), or for ES7. This method would take in a single callback that would be executed once when the antecedent Promise is settled regardless of whether it was fulfilled or rejected. If the callback results in a normal completion, the state of the antecedent promise would be adopted by the new Promise. However, if the callback results in an abrupt completion, the new Promise would be rejected with this reason. You can find more details about this proposal along with amendments to the current ES6 working draft below: [1] https://gist.github.com/rbuckton/66918c8491aa335b003c [https://avatars2.githubusercontent.com/u/3902892?s=140]https://gist.github.com/rbuckton/66918c8491aa335b003c Proposal for addition of Promise.prototype.finally Proposal for addition of Promise.prototype.finally - Gist is a simple way to share snippets of text and code with others. Read more...https://gist.github.com/rbuckton/66918c8491aa335b003c After working heavily with an ES6 Promise shim as of late, I have found such a feature would be very valuable. It is possible to patch the ES6 Promise API to add such a feature, however it seems like it could be a worthwhile addition that could benefit the community until such a time as an `async/await`-like syntax is available in ES7+. Best regards, Ron ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Proposal: Promise.prototype.Finally
Here is the current design for Promise.prototype.finally. I agree it is a useful feature. https://github.com/domenic/promises-unwrapping/issues/18 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Promise.prototype.Finally
Yes. Needed it recently. Ended up doing .then(f).catch(f) which can be survived but feels stupid. David Le 18/08/2014 21:20, Domenic Denicola a écrit : Here is the current design for Promise.prototype.finally. I agree it is a useful feature. https://github.com/domenic/promises-unwrapping/issues/18 ___ 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
Re: Modules and dependencies found during the load (before instantiation)
On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Aug 2014, Ian Hickson wrote: One of the problems I'm running into when it comes to trying to integrate ES6 modules with HTML and new HTML-based dependency features is the way that I can't tell ES about dependencies I know about before the data is actually fetched and instantiated. Another example of where we have something like this is HTML imports. The fetch hook for HTML imports needs to actually be the hook that does all the parsing, since HTML loads incrementally. (For HTML imports, the translate and instantiate hooks are essentially no-ops.) This means that the in-band dependencies for HTML imports are found during the fetch hook, and need to be set up right away. For example, if an HTML import contains a script type=module block, that inline module needs to be added as dependency of the import itself (so that the import's 'load' event doesn't fire until all internal modules are loaded). It it contains an img src= element, that needs to be added as a dependency as its loading. This is similar to the instantiate hook adding dependencies, except that it has to happen earlier due to the incremental parsing. Can we explore the opposite question: how much does the HTML dependency problem really overlap the ES dependency problem? To the first approximation these are the same problem: given the root of graph, load all of the nodes of the graph. The solution to this generic problem is well known and the code, while not trivial, is not very complex. As soon as we go beyond this first level, the problems diverge. In fact I think your posts make the case that the character of these problems differ on so many points that code reuse is unlikely and algorithm reuse unwise. In particular the reason we -- 'we' being you and me -- can't understand the ES spec is (evidently) that it supports loading a graph of mixed nodes (ES and legacy) with different assumptions about circular references. HTML is unlikely to have the identical requirements on circular references and it's legacy (script tags, document.write, mutable declarations, HTML imports) has quite different issues. It seems to me that a better design for HTML dependency loading would integrate with the ES Loader rather than attempt to mutate it. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Promise.prototype.Finally
On Mon, Aug 18, 2014 at 12:30 PM, David Bruant bruan...@gmail.com wrote: Yes. Needed it recently. Ended up doing .then(f).catch(f) which can be survived but feels stupid. And doesn't have the correct pass-through behavior, unless you've got a switch in f that makes it return or throw based on whether the argument is an Exception. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
On Mon, 18 Aug 2014, John Barton wrote: On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: The ES Loader does not maintain a dependency tree. It maintains a table of names-modules. Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record [[Dependencies]] list? The dependencies for the Load. Once the load is complete the record is not needed. How about if the dependencies are changed during the load? For example: script id=a src=a.js load-policy=when-needed/script This seems like an unfortunate design choice Can you elaborate? What would a better design be? I'm certainly not married to this approach. Fundamentally, though, if the problem is how to mark HTML elements as load on demand with a dependency tree, I don't see many options beyond putting things in HTML attributes or elements. (I use scripts in the example above, but the problem applies equally to images or other non-script features, and the use cases for them apply even with scripting disabled. For example, marking images as load on demand so that they don't load until the user scrolls down, with some images needing particular style sheets that are also to not load until you scroll down to the relevant image.) script id=b src=b.js load-policy=when-needed/script script id=c needs=a ... /script script // at this point, the script with id=c is blocked waiting for a.js to // load. Let's change its dependencies: document.scripts.c.needs = 'b'; ...which leads to exotic quirks like this. Well, the DOM is mutable. If we hook something into the DOM, we have to define what happens when it mutates. // now the script needs to trigger b.js to load // a.js' load can be deprioritised (or canceled, if network is at a // premium), and no longer blocks the script from loading /script System.import already supports dynamic loading with runtime dependency selection. If you have a problem with it let's discuss that before redesigning it. I'm not sure I follow. Can you elaborate? How would you use System.import() to mark e.g. an image as dependent on a style sheet when scripting is disabled? Or indeed even when scripting is enabled, how would you use it to mark one non-loaded script as dependent on another non-loaded script such that when you later ask for the former, the latter loads automatically? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
On Mon, 18 Aug 2014, John Barton wrote: On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: To avoid overly spamming the list I've coallesced my responses to various threads over the weekend into this one e-mail. I really think this makes the discussion more difficult to follow and certainly more difficult to participate in. Apologies, I'm not familiar with this lists' conventions. Now, in the main page, you reference the HTML import: link rel=import href=foo.html Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document, and the import has a separate document. Separate document implies separate JS global: each needs its own Loader. So the rest of the questions aren't needed. HTML imports definitely need to expose modules across documents. Are you saying this requires changes to ES6 to support? What changes would we need? You need to give more details about such requirements. What is the runtime relationship between Imports and other documents? I assume the Import is providing some state that ends up in the importer but then you are saying these are different documents. HTML imports and regular documents share a Window object, but have separate Documents objects. You can find out more about them here: http://w3c.github.io/webcomponents/spec/imports/ They are shortly to be merged into the HTML spec proper; doing so is mostly just blocked on my work trying to integrate HTML with ES6's module loader so that we don't end up with multiple redundant dependency systems. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
On Mon, Aug 18, 2014 at 2:00 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
The ES Loader does not maintain a dependency tree. It maintains
a table of names-modules.
Maybe I'm misunderstanding the ES6 loader spec. What's the Load
Record [[Dependencies]] list?
The dependencies for the Load. Once the load is complete the record
is not needed.
How about if the dependencies are changed during the load? For
example:
script id=a src=a.js load-policy=when-needed/script
This seems like an unfortunate design choice
Can you elaborate? What would a better design be?
The current System.import + Loader mechanism.
I'm certainly not
married to this approach. Fundamentally, though, if the problem is how to
mark HTML elements as load on demand with a dependency tree, I don't see
many options beyond putting things in HTML attributes or elements. (I use
scripts in the example above, but the problem applies equally to images or
other non-script features, and the use cases for them apply even with
scripting disabled.
The problems are not equal but rather have significant unique aspects.
For example, marking images as load on demand so
that they don't load until the user scrolls down, with some images needing
particular style sheets that are also to not load until you scroll down to
the relevant image.)
Why should I have to mark images? The page should load the images needed
for the visible area. (But I'm unsure if this is even technically feasible
since images below the fold could affect layout above the fold).
script id=b src=b.js load-policy=when-needed/script
script id=c needs=a ... /script
script
// at this point, the script with id=c is blocked waiting for a.js
to
// load. Let's change its dependencies:
document.scripts.c.needs = 'b';
...which leads to exotic quirks like this.
Well, the DOM is mutable. If we hook something into the DOM, we have to
define what happens when it mutates.
There is no reason to make this case work great. It's much more important
to make the simple cases work well.
// now the script needs to trigger b.js to load
// a.js' load can be deprioritised (or canceled, if network is at a
// premium), and no longer blocks the script from loading
/script
System.import already supports dynamic loading with runtime dependency
selection. If you have a problem with it let's discuss that before
redesigning it.
I'm not sure I follow. Can you elaborate?
Your examples use script. I just don't think now that we should use the
same solution for HTML. We should analyze the HTML requirements and design
a solution. If the result is similar to script then we can reuse.
If we do want to follow the pattern of the script loader, we would extract
'static' dependencies by parsing and use script for dynamic dependencies.
We would not mix them.
In parsing for static dependencies we need not start from the assumption of
extra declarations. These extra declarations added to ES6 are really about
convenient abbreviations. For example,
import {Foo} from 'src/baz/Foo';
var foo = new Foo();
is just a much nicer syntax than
var foo = new {src/baz/Foo}.Foo(); // illegal
or whatever. But in the case of image tags we already know exactly which
image the HTML depends upon. All we have to do is not load it until we need
it to render the page. (Again I'm assuming a magical solution to the
rendering part, which is needed in any dependency loading solution).
How would you use
System.import() to mark e.g. an image as dependent on a style sheet when
scripting is disabled?
Once we understand how these dependencies arise we can look for ways to
extract the dependency information and determine whether explicit
dependency declaration is needed.
Or indeed even when scripting is enabled, how would
you use it to mark one non-loaded script as dependent on another
non-loaded script such that when you later ask for the former, the latter
loads automatically?
import './latter';
It's a solved problem for scripts.
If you ask about images, then you will have to explain what it means for an
image to be dependent upon an image. Surely there are legitimate non-script
dependencies but we can't just treat everything like script and vice versa.
Discussing HTML dependency loading and ES dependency loading together makes
a lot of sense -- up to a point. But requiring specs and implementations to
converge does not seem good to me now.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson i...@hixie.ch wrote:
Now, in the main page, you reference the HTML import:
link rel=import href=foo.html
Now how would you refer to the modules? We can't have #b refer to
it, since the scope of IDs is per-document, and the import has a
separate document.
...
HTML imports and regular documents share a Window object, but have
separate Documents objects. You can find out more about them here:
http://w3c.github.io/webcomponents/spec/imports/
If they share a Window object then they should share a Loader, but they may
have different baseURLs. So for you example above we write eg.
import {b} from ./b;
because the scripts in the HTML import will have names relative to the same
default baseURL as the main document. So I guess URL space is like
http://example.com/index.html
http://example.com/foo.html
http://example.com/b.js
I suppose it would be more common for the component to be in a
subdirectory, eg
http://example.com/index.html
http://example.com/foo/theFoo.html
http://example.com/foo/b.js
so the import would be
import {b} from ./foo/b;
I think we could also imagine that such an import declaration could be used
without the HTML Import declaration. The fetch() call will ask for
baseURL/foo/b.js and the server will say hey that's in an HMTL Import
and serve text/html. The fetch() hook will have to detect this and process
the HTML Import, then continue with the loading process. This much I'm
just making up.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Proposal: Promise.prototype.Finally
Domenic, I like the addition that your version of `finally` can itself return a Promise, which I hadn't considered (as I hadn't had a need for it myself yet). Is the consensus that this won't make it into Promise until at least ES7, and then only if there's enough of a call for it? To be honest, if ES7 has something like async/await then it won't need Promise.prototype.finally. Promise.prototype.finally is primarily a feature needed for Promises without async/await (e.g. in the ES6 timeframe, or ES7 if async/await is deferred to a later revision). Ron From: Domenic Denicola dome...@domenicdenicola.com Sent: Monday, August 18, 2014 3:20 PM To: Ron Buckton; EcmaScript Subject: RE: Proposal: Promise.prototype.Finally Here is the current design for Promise.prototype.finally. I agree it is a useful feature. https://github.com/domenic/promises-unwrapping/issues/18 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Proposal: Promise.prototype.Finally
Is the consensus that this won't make it into Promise until at least ES7, and
then only if there's enough of a call for it?
Although I find the arbitrary division of features into ES6 and ES7
distasteful personally: yes, ES6 will not be adding new APIs. That doesn't mean
that Promise.prototype.finally won't ship in all major browsers before other
ES6 features do. But it does mean that we won't be submitting a document to the
Ecma general assembly with Promise.prototype.finally before we submit one with
proper tail calls.
To be honest, if ES7 has something like async/await then it won't need
Promise.prototype.finally.
That's mostly true, I suppose, but it can increase brevity in some cases:
```js
function doThingySafely() {
return doThingy().finally(cleanup);
}
// vs.
async function doThingySafely() {
try {
return await doThingy();
} finally {
return cleanup();
}
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing modules loaded by HTML Imports.
Would there be any problems treating the html import as a virtual module
itself. Giving all scripts inside the sub document the module context
object as its this binding? Then to do any additional loading you'd need to
do this.import().
On Aug 18, 2014 6:56 PM, John Barton johnjbar...@google.com wrote:
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson i...@hixie.ch wrote:
Now, in the main page, you reference the HTML import:
link rel=import href=foo.html
Now how would you refer to the modules? We can't have #b refer to
it, since the scope of IDs is per-document, and the import has a
separate document.
...
HTML imports and regular documents share a Window object, but have
separate Documents objects. You can find out more about them here:
http://w3c.github.io/webcomponents/spec/imports/
If they share a Window object then they should share a Loader, but they
may have different baseURLs. So for you example above we write eg.
import {b} from ./b;
because the scripts in the HTML import will have names relative to the
same default baseURL as the main document. So I guess URL space is like
http://example.com/index.html
http://example.com/foo.html
http://example.com/b.js
I suppose it would be more common for the component to be in a
subdirectory, eg
http://example.com/index.html
http://example.com/foo/theFoo.html
http://example.com/foo/b.js
so the import would be
import {b} from ./foo/b;
I think we could also imagine that such an import declaration could be
used without the HTML Import declaration. The fetch() call will ask for
baseURL/foo/b.js and the server will say hey that's in an HMTL Import
and serve text/html. The fetch() hook will have to detect this and process
the HTML Import, then continue with the loading process. This much I'm
just making up.
jjb
___
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
Re: Changing dependencies during the load process.
On Mon, Aug 18, 2014 at 5:32 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 18 Aug 2014, John Barton wrote:
...
But in the case of image tags we already know exactly which image the
HTML depends upon.
But other elements might depends on the img, and that we don't know.
(For example, a graphical game might need some sprite assets to be loaded
before it can start up. So its script might be marked as depending on an
img element that loads that image. Or the script contents might have an
import statement that refers to that image.)
Supporting this case seems straight-forward and can be done entirely by the
browser Loader implementation using hooks.
The reverse case, where a img depends on a script, is not a use case.
Or indeed even when scripting is enabled, how would you use it to mark
one non-loaded script as dependent on another non-loaded script such
that when you later ask for the former, the latter loads
automatically?
import './latter';
It's a solved problem for scripts.
The key part of my question was non-loaded. The import bit is in the
script. The script isn't loaded yet, so we can't rely on it.
script
System.import('./former').then((former) = {
// do stuff with former, knowing './former' imported './latter'.
});
/script
Here we are expressing the dependency of the HTML file on the non-loaded
file './former' and it depends on the non-loaded file './loaded'.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
That First Next Argument
Background: http://esdiscuss.org/topic/next-yo-in-newborn-generators http://esdiscuss.org/topic/april-8-2014-meeting-notes It appears that the current state of affairs is that the argument supplied to the first call of `next` on a newborn generator is ignored and inaccessibe. Clearly, this means that there are some iterators which cannot be expressed as a generator (namely, any iterator that echoes back it's `next` arguments). It seems like there should be parity here. More concretely, the fact that information can be passed into generators means that they can be used to create data sinks. Since that first input is inaccessible, however, this use case is made more awkward than it needs to be; the consumer has to artificially pump the generator to get past that first (useless) `next`. Is there any way that the generator function can have access to that lost data? Thanks! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
