On Fri, Aug 21, 2015 at 8:12 AM, Domenic Denicola wrote:
> No, custom elements cannot prototype the module tag, because custom elements
> will always be parsed as unknown elements. So e.g.
Ah, thanks for pointing that out. I was thinking more of the script
src style of tag. The need for module b
On Tue, Aug 18, 2015 at 11:36 AM, Dave Herman wrote:
> https://github.com/whatwg/loader/blob/master/roadmap.md
>From a loader/tool perspective, it seems like working out more of the
Stage 1 items before many of the Stage 0 items will lead to higher
leverage payoffs: the dynamic loading and module
On Fri, Apr 24, 2015 at 11:39 AM, Brendan Eich wrote:
> Not "bundling" in full; your previous post talked about HTTP2 but mixed
> dependency handling and bundling. You seemed not to advert to the problem
> of one big bundle being updated just to update one small member-of-bundle.
> One can be ske
On Fri, Apr 24, 2015 at 8:42 AM, Allen Wirfs-Brock
wrote:
>
> I think you're barking up the wrong tree. ECMAScript has never said
> anything about the external representation of scripts (called "Programs"
> prior to ES 2015) and the ES 2015 spec. doesn't impose any requirements
> upon the exter
On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich wrote:
> Your lament poses a question that answers itself: in time, ES6 will be
> the base level, not ES3 or ES5. Then, the loader can be nativized.
> Complaining about this now seems churlish. :-|
>
>
So let's stay on this specific point: bundling wi
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola wrote:
> Indeed, there is no built-in facility for bundling since as explained in
> this thread that will actually slow down your performance, and there’s no
> desire to include an antipattern in the language.
>
>
>
Some counterpoint:
For priv
On Fri, Dec 19, 2014 at 8:55 PM, caridy wrote:
> Yeah, the idea is to get engines (V8 maybe) to implement what is spec’d in
> ES6 today, and get a very basic implementation of
On Thu, Dec 18, 2014 at 6:13 PM, caridy wrote:
> What does this means?
>
> * no loader (if you need on-demand loading, you can insert script tags with
> type=module, similar to what we do today for scripts)
> * no hooks or settings (if you need more advanced features, you will have to
> deal with
I added a doc about module inlining/nesting, and why it should be
supported in a module system. Mentions SPDY/HTTP2, packaged formats,
Node’s Browserify, and transpiling:
https://github.com/jrburke/module/blob/master/docs/inlining.md
James
On Mon, Jun 16, 2014 at 1:21 PM, James Burke wrote
On Thu, Jun 19, 2014 at 12:13 PM, Domenic Denicola
wrote:
> From: es-discuss on behalf of James Burke
>
>
>> 1) Only allow export default or named exports, not both.
>
> As a modification of the current design, this hurts use cases like
>
> ```js
> import glob, {
On Thu, Jun 19, 2014 at 1:15 AM, David Herman wrote:
> ## Proposal
>
> OK, so we're talking about a better syntax for importing a module and binding
> its named exports to a variable (as distinct from importing a module and
> binding its default export to a variable). Here's my proposal:
> ```js
I have suggested alterations to the modules effort, and an in-progress
prototype[1].
It is based on field usage of existing JS module systems, and my work
supporting AMD module solutions for the past few years.
There is a document describing what it attempts to fix[2]. The table
of contents from
On Mon, Jan 27, 2014 at 11:53 PM, Marius Gundersen wrote:
> AFAIK ES-6 modules cannot be bundled (yet). But if/when they can be bundled
> this is an argument for silently ignoring duplicates
Loader.prototype.define seems to allow bundling, by passing strings
for the module bodies:
https://people
On Mon, Jan 27, 2014 at 3:14 PM, John Barton wrote:
> On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
> wrote:
>> Imagine that some browser has an ok-but-not-complete implementation of
>> the X library, but you want to use jQuery 17, which requires a better
>> version. You need to be able t
On Sun, Nov 3, 2013 at 12:34 PM, David Herman wrote:
> IOW expose the first-class "reference type" of ECMA-262 via a standard
> library? Just say no! :)
I was thinking that if they were used anyway by the module system,
formalizing them might help, the "provide the primitives" sort of API
design
With the import/export mutable slots concept, does it make sense to
allow an API that has expresses that type of concept? I think it would
allow creating a module-function thunk that would allow robust cycles
as mentioned here:
https://mail.mozilla.org/pipermail/es-discuss/2013-November/034576.htm
On Fri, Nov 1, 2013 at 2:19 PM, Jeff Morrison wrote:
> (I'm operating on the assumption that the Module constructor is still part
> of the spec):
>
> ```
> System.define({
> A: {
> deps: ['B','C'],
> factory: function(B, C) {
> var stuff = B.doSomething();
> return new Module
On Fri, Nov 1, 2013 at 1:04 PM, Jeff Morrison wrote:
> No, that's why I said the function generates an instance of a Module object
> imperatively (we're already in imperative definition land with this API
> anyway).
> No need for `import` or `export`
My understanding is that there is no way to ex
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison wrote:
> Throwing this out there while I stew on the pros/cons of it (so others can
> as well):
> I wonder how terrible it would be to have this API define module bodies in
> terms of a passed function that, say, accepted and/or returned a module
> ob
On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith wrote:
>> I wonder, though, if this might create issues for polyfilling:
>>
>> // polyfillz.js
>> if (this.Promise === void 0)
>> this.Promise = function() { ... }
>>
>>
On Tue, Jun 4, 2013 at 8:02 AM, Domenic Denicola
wrote:
> From: Yehuda Katz [wyc...@gmail.com]
>
>> In general, expectations about side-effects that happen during module
>> loading are really edge-cases. I would go as far as to say that modules that
>> produce side effects during initial executi
On Mon, May 20, 2013 at 12:07 PM, Kevin Smith wrote:
> On the other hand, I think it is possible with URLs to create a system which
> truly does work out-of-the-box.
>
> Let's imagine a world where publicly available modules are located at sites
> specifically designed for naming and serving JS mo
On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola
wrote:
> From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt
> [sa...@ccs.neu.edu]
>
>> There's a default place to fetch files from, because there has to be _some_
>> default.
>
> Why?
>
> This is the core of my problem wit
On Wed, May 8, 2013 at 10:44 AM, Sam Tobin-Hochstadt wrote:
> How is this in disagreement with what Jason said? His point is that
> if you're in the module "a/b/c", "./controllers" refers to
> "a/b/controllers", and "backbone" refers to "backbone". Once you have
> a module name, there's a default
On Tue, May 7, 2013 at 5:21 PM, Domenic Denicola
wrote:
> I'm not sure the Node.js scheme is the best idea for the web, but I *would*
> like to emphasize that the AMD scheme is not a good one and causes exactly
> the confusion we're discussing here between URLs and module IDs.
I believe this is
On Wed, May 1, 2013 at 8:28 AM, Tab Atkins Jr. wrote:
> Central naming authorities are only necessary if you need complete
> machine-verifiable consistency without collisions. As long as humans
> are in the loop, they tend to do a pretty good job of avoiding
> collisions, and managing them when t
On Tue, Mar 26, 2013 at 3:23 AM, Andreas Rossberg wrote:
> On 25 March 2013 18:31, James Burke wrote:
>> ### Single Anonymous Export ###
> Also, optimising the entire syntax for one special use case while
> uglifying all regular ones will be a hard sell.
I believe this is one o
Hi Sam,
I really was not expecting a reply, as it was a lot of feedback. Just
wanted to get some things in the "to be considered at some point/use
case" queue. Some clarifications, but I do not think it is worth
continuing discussion here given the breadth of the feedback and the
stage of the spec
I expect the module champions to be busy, so I am not expecting a
response. This is just some feedback to consider or discard at their
discretion. I'll wait for the next public update on modules to see
where things end up. In general, sounds promising.
I'm going off the meeting notes from here (th
On Thu, Feb 7, 2013 at 1:00 PM, Claus Reinke wrote:
> There are some existing ES.next modules shims/transpilers that
> could be used as a starting point.
Here is an experiment I did with a JS module syntax that allowed for a
static compile time hooks for things like macros, but still allowed JS
t
On Thu, Dec 20, 2012 at 11:51 AM, Sam Tobin-Hochstadt wrote:
> - I don't see what a mutable `exports` object would add on top of
> this system, but maybe I'm not understanding what you're saying.
It is one way to allow circular dependencies in CommonJS/Node/AMD
systems. The other way is to call
On Thu, Dec 20, 2012 at 8:22 AM, Kevin Smith wrote:
> This is exactly the use case that my OP addresses. The logic goes like
> this: in order to apply that boilerplate, you have to know whether the
> module is ES5 or ES6. In order to know that, you have to parse it.
> Pre-parsing every single m
On Wed, Dec 19, 2012 at 11:44 AM, Kevin Smith wrote:
> But that cowpath was only created because of the problems inherent in a
> dynamic, variable-copy module system, as I argue here
> (https://gist.github.com/4337062). In CommonJS, modules are about
> variables. In ES6, modules are about bindin
On Tue, Dec 18, 2012 at 12:56 PM, Kevin Smith wrote:
> At first glance, it seems like anonymous exports might provide a way for
> pre-ES6 (read: Node) modules and ES6 modules to coexist. After all:
>
> exports = function A() {};
>
> just looks so much like:
>
> module.exports = function A
On Tue, Dec 4, 2012 at 8:54 AM, Kevin Smith wrote:
> === Modules ===
>
> Perhaps I'm misreading the notes, but I am concerned about the amount of
> churn that I'm seeing in module discussions. Particularly worrisome to me
> is the suggestion that the default loading behavior should map:
>
> i
On Tue, Oct 16, 2012 at 2:58 PM, David Herman wrote:
> prints "a" then "b" then "main". That's clearly a problem for simple
> concatenation. On the one hand, the point of eager execution was to make the
> execution model simple and consistent with corresponding IIFE code. On the
> other hand, e
On Thu, Jul 5, 2012 at 5:56 AM, Kevin Smith wrote:
>> Will heterogenous transpiling in a web app be supported? Can a JS
>> module depend on a CoffeeScript file, and vice versa?
>
>
> Right - Sam's example of having a specific CoffeeScript loader isn't going
> to actually work for this reason. Ins
On Wed, Jul 4, 2012 at 11:13 AM, Sam Tobin-Hochstadt wrote:
> We've thought a lot about compile-to-JS languages, and a bunch of the
> features of the module loader system are there specifically to support
> these languages. You can build a loader that uses the `translate`
> hook to perform arbitr
On Tue, Jul 3, 2012 at 4:27 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Jul 3, 2012 at 7:19 PM, Allen Wirfs-Brock
> wrote:
>> Sam,
>> Isn't it also the case that the full characteristics of the default module
>> loader used by browsers still remain to be specified? This might be
>> somewhat out
A good chunk of my previous feedback is based on a higher level design
goal that is worth getting a common understanding on, since it may
invalidate my feedback:
Question:
What happens when a module depends on a non-module code?
Example:
I have an ES module, 'foo', it depends on jQuery. foo use
On Thu, Jun 28, 2012 at 7:56 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 28, 2012 at 10:40 AM, Kevin Smith wrote:
>>>
>>>