Re: ES6 modules (sorry...)

John, there are a couple of solutions at hand that you can apply: 1. loader provides the right hooks for you to hint at loader what are the modules you need to need to load. which is literally 10 lines of code for an extension of the loader: https://github.com/systemjs/systemjs/blob/master/lib/

Re: .entries() vs. the web

Would .items fare better, I wonder. /be Oliver Hunt wrote: It turns out there are a number of sites (such as mobile.twitter.com ) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided. We're

Re: IsConstructor

On Mon, Jun 16, 2014 at 5:39 PM, Allen Wirfs-Brock wrote: > Perhaps you could fill out what you actually mean by @@new and how it would > work for regular functions, class declarations, and subclasses of both > regular classes and the legacy built-ins. Yes, that's a very good idea. I'll do so.

Re: .entries() vs. the web

This is a gently reminder I don't represent my company anyhow in this mailing list but actually I've been working on mobile web here at twitter for 1.5 years how ... thanks for the report, I'll do what I can (already patched, waiting reviews) + I don't think mobile web should block anyhow new stand

Re: ES6 modules (sorry...)

You don't really want 300/3000/3 modules where you have to "load", "parse", then "request (dependencies)". You really need your dependencies, pre-ordered and pre-loaded (that is bundled) if you want your "empty cache" clients to get a good experience. SPYD is only one piece of a puzzle it isn

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 4:49 PM, caridy wrote: > > I thought SPDY was, to quote wikipedia, about: "reducing web page load >> latency and improving web security" >> > How does SPDY help when the issue is lots of small requests ping >> ponging back and forth between client and server? >> >> SPDY mu

Re: .entries() vs. the web

Apparently, this problem was already known more than 4 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=924386#c19 I guess it specifically affect the mobile web? for it didn't prevent Firefox to ship `Array.prototype.entries` in v28, released on March 18. —Claude Le 17 juin 201

Re: ES6 modules (sorry...)

Guy Bedford and I have been discussing a compromise with bundling of “internal” dependencies but leaving “external” dependencies out of the bundle. There are legitimate concerns around exposing a library’s internal module structure to the outside world. For example, Ember is written using ES6 modul

Re: ES6 modules (sorry...)

The latency problem caused by tree depth can also be solved with a Link prefetch header (when Chrome re-enables this) from a server trace or a simple loader extension that contains a traced dependency cache. Injecting a trace tree is a much simpler and better alternative to bundling as we get the c

Re: ES6 modules (sorry...)

> > I thought SPDY was, to quote wikipedia, about: "reducing web page load > > latency and improving web security" > > How does SPDY help when the issue is lots of small requests ping ponging > > back and forth between client and server? > > SPDY multiplexes the requests across the same connecti

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 4:04 PM, caridy wrote: > > I thought SPDY was, to quote wikipedia, about: "reducing web page load > latency and improving web security" > > How does SPDY help when the issue is lots of small requests ping ponging > back and forth between client and server? > > SPDY multipl

Re: .entries() vs. the web

@@unscopeable doesn't work as they are not using |with| The logic is something along the lines of if (foo.entries) ... It looks like there are paths that objects or arrays may path through, with "entries" being a perfectly reasonable property name in the object case, but now the array case hi

Re: ES6 modules (sorry...)

> > > All major browsers (including safari) support SPDY today. But the point > is, we should not consider "bundling" as a prime use-case for modules, > because it is not going to be important at all. > I agree, in principle, but I'm not quite as confident that bundling will have *no* place on the

Re: .entries() vs. the web

That is why you need to implement @unscopables too. On Jun 16, 2014 7:08 PM, "Oliver Hunt" wrote: > It turns out there are a number of sites (such as mobile.twitter.com) > that are property detecting .entries on objects, and that means that > they're breaking when Array.prototype.entries is provi

Re: .entries() vs. the web

On Mon, Jun 16, 2014 at 4:08 PM, Oliver Hunt wrote: > It turns out there are a number of sites (such as mobile.twitter.com) that > are property detecting .entries on objects, and that means that they're > breaking when Array.prototype.entries is provided. What are they using the detection for? ~

.entries() vs. the web

It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided. We're removing it from JSC now, until we can find a way to expose it without causing site breakag

Re: ES6 modules (sorry...)

> I thought SPDY was, to quote wikipedia, about: "reducing web page load > latency and improving web security" > How does SPDY help when the issue is lots of small requests ping ponging back > and forth between client and server? SPDY multiplexes the requests across the same connection, which is

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 3:42 PM, caridy wrote: > On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi > wrote: > > > The other big concern here is that in production, very few people are > going to be loading every JavaScript file asynchronously. If there's > magic, there needs to be a reasonable way

Re: Function.create

Claude: Thanks, I was under the impression that existing ES6 class inheritance wouldn't allow this to work. If it does, that's a big improvement and I'll have to try it once class syntax is working in one of the browsers I target. Scott: The problem isn't a 'sync issue'; the body of the function i

Re: IsConstructor

On Jun 16, 2014, at 3:02 PM, Jason Orendorff wrote: > On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem wrote: >> Interesting. It'd be nice if we could further simplify the Proxy/Reflect >> API. Given the local nature of these changes, we might still include it in >> ES6 if we achieve quick consen

Re: ES6 modules (sorry...)

On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi wrote: > The other big concern here is that in production, very few people are going > to be loading every JavaScript file asynchronously. If there's magic, there > needs to be a reasonable way to handle bundling multiple ES6 files together. This

Re: ES6 modules (sorry...)

> The other big concern here is that in production, very few people are > going to be loading every JavaScript file asynchronously. If there's > magic, there needs to be a reasonable way to handle bundling multiple ES6 > files together. > OK, so there are two issues here: 1. How do you bundle mo

Re: IsConstructor

On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem wrote: > Interesting. It'd be nice if we could further simplify the Proxy/Reflect > API. Given the local nature of these changes, we might still include it in > ES6 if we achieve quick consensus. I'm mostly interested in getting rid of [[Construct]]

Re: ES6 modules (sorry...)

The other big concern here is that in production, very few people are going to be loading every JavaScript file asynchronously. If there's magic, there needs to be a reasonable way to handle bundling multiple ES6 files together. The [current solution][1] turns it into common.js (or others) and do

Modules: suggestions from the field

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

Re: ES6 modules (sorry...)

Another alternative is to introduce this funny "binding not destructing" behavior as a first-class language construct, so that one could do: ``` let o = { f: 1 }; let < f > = o; // using your angle-bracket syntax for the sake of discussion o.f = 2; console.log(f); // prints '2' let < foo > = imp

Re: ES6 modules (sorry...)

- Matthew Robb On Mon, Jun 16, 2014 at 11:42 AM, C. Scott Ananian wrote: > On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb > wrote: > > My argument is that you can keep everything the same as it is now but > change > > the syntax to not use curlies and avoid the confusing similarity to > > destr

Re: In ES6, do for loops with a let/const initializer create a separate scope?

On Jun 16, 2014, at 11:29 AM, Michael Zhou wrote: > Thanks for the clarification, one detail about the order between incrementing > and setting $$lastIteration_i: > { >let i = $$lastIteration_i; //create and initialize per iteration i >if (!(i<10)) break; > { > let i; >} >

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb wrote: > My argument is that you can keep everything the same as it is now but change > the syntax to not use curlies and avoid the confusing similarity to > destructuring. You could use `(a,b,c)` or `` and it would all > continue working as it does bu

Re: Re: In ES6, do for loops with a let/const initializer create a separate scope?

Thanks for the clarification, one detail about the order between incrementing and setting $$lastIteration_i: { let i = $$lastIteration_i; //create and initialize per iteration i if (!(i<10)) break; { let i; } *i++; $$lastIteration_i = i;* } Should it be* $$lastIteratio

Re: ES6 modules (sorry...)

My argument is that you can keep everything the same as it is now but change the syntax to not use curlies and avoid the confusing similarity to destructuring. You could use `(a,b,c)` or `` and it would all continue working as it does but be less confusing. - Matthew Robb On Mon, Jun 16, 2014 a

Re: ES6 modules (sorry...)

Yes! Don't make it look like destructuring and then say it's nothing like that. At this point I'd be happy to be able to only get back one thing from an import (no destructure-like syntax) that could be any kind of value, including an object with lots of methods on it like we are used to in Node.j

Re: ES6 modules (sorry...)

A few more thoughts... On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre wrote: > > On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron > wrote: > >> >> On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf > > wrote: >> >>> e.g. something like >>> https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4ad

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre wrote: > > On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron > wrote: > >> >> On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf > > wrote: >> >>> e.g. something like >>> https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7 >>> >> >> re: >> >>

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:40 PM, Calvin Metcalf wrote: > > > A good question Rick, I sketched that out pretty quickly earlier today. > It did take me a while to remember that modules are the ONE place where > strings are by reference an not by value... > It's more than that—if I specify an expo

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:41 PM, C. Scott Ananian wrote: > That is, IMHO mutable bindings and modules with cyclic dependencies > are members of "the bad parts" of JavaScript. Sure, sometimes there's > a valid reason to use them. But for most developers they will be > happier sticking with "the g

Re: ES6 modules (sorry...)

Jasper: none of those things are legal in the current spec On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre wrote: > > On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron > wrote: > >> >> On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf > > wrote: >> >>> e.g. something like >>> https://gist.github.

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron wrote: > > On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf > wrote: > >> e.g. something like >> https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7 >> > > re: > > let { foo, bar } = import "library"; > > Ignoring the UnaryExpression ambiguit

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:06 PM, Domenic Denicola wrote: > From: es-discuss on behalf of C. Scott > Ananian >> Using destructuring syntax for imports would be a *good thing*. It builds >> on our existing understanding of JS constructs, instead of adding more >> gratuitously different things

Re: ES6 modules (sorry...)

A good question Rick, I sketched that out pretty quickly earlier today. It did take me a while to remember that modules are the ONE place where strings are by reference an not by value... On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron wrote: > > > > On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcal

Re: ES6 modules (sorry...)

I wonder if it would help reduce confusion if the syntax wasn't so similar to destructuring: import ( foo, bar ) from "library"; or > import < foo, bar > from "library"; - Matthew Robb On Mon, Jun 16, 2014 at 10:24 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I'm not talk

RE: ES6 modules (sorry...)

I'm not talking about MIO properties. I'm talking about the bindings created by import declarations. From: Sam Tobin-Hochstadt Sent: ‎2014-‎06-‎16 13:21 To: Domenic Denicola Cc: Calvin Metcalf

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf wrote: > e.g. something like > https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7 > re: let { foo, bar } = import "library"; Ignoring the UnaryExpression ambiguity, what happens here: // library.js export const MAX_VALUE = 1023; //

RE: ES6 modules (sorry...)

On Jun 16, 2014 1:06 PM, "Domenic Denicola" wrote: > > From: es-discuss on behalf of C. Scott Ananian > > > Using destructuring syntax for imports would be a *good thing*. It builds on our existing understanding of JS constructs, instead of adding more gratuitously different things to learn. >

RE: ES6 modules (sorry...)

From: es-discuss on behalf of C. Scott Ananian > Using destructuring syntax for imports would be a *good thing*. It builds on > our existing understanding of JS constructs, instead of adding more > gratuitously different things to learn. This would be a very *bad thing*, as long as the curr

Re: ES6 modules (sorry...)

e.g. something like https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7 On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian wrote: > On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf > wrote: > > They curly braces only look like destructuring if you keep the name the > > same, when imported

Re: ES6 modules (sorry...)

On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf wrote: > They curly braces only look like destructuring if you keep the name the > same, when imported with a different name it's a slightly different syntax, > {oldname as newname} not {oldname: newname}, also as it currently stands I wish that the

Re: IsConstructor

On Jun 15, 2014, at 11:45 PM, Tom Van Cutsem wrote: > 2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock : > Anotherconcern I have with @@new, it that it exposes two extension points, > @@new and @@create, on very constructor. I'm afraid that it wouldn't be very > clear to most ES programmers when y

Re: Function.create

On Mon, Jun 16, 2014 at 3:06 AM, Katelyn Gadd wrote: > emscripten/asm.js) will face similar issues. The other compilers I've > seen that tackle this solution efficiently do so by abandoning the > 'new' keyword in favor of magic methods, which I consider a poor > solution. I'd be interested in hea

Re: ES6 modules (sorry...)

On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer wrote: > I apologize for this email, but I still don’t understand the current > module design. > ... > **Single-export modules.** Still missing is support for single-export > modules, which could be added as follows (the keyword `default` instead

Re: ES6 modules (sorry...)

> > >On Monday, June 16, 2014 12:33 AM, Axel Rauschmayer wrote: > > >**Single-export modules.** Still missing is support for single-export modules, >which could be added as follows (the keyword `default` instead of the asterisk >works just as well, in my opinion). You're being confused by C

Re: ES6 modules (sorry...)

They curly braces only look like destructuring if you keep the name the same, when imported with a different name it's a slightly different syntax, {oldname as newname} not {oldname: newname}, also as it currently stands // BAD import lib from 'library'; lib.foo(); lib.bar(); is no

Re: Function.create

Hi Katelyn, If you intend to have a constructor that inherit from another one, it is possible in ES6: just recall that, in ES, constructors and classes happen to be the same thing: class C extends D { // alternatively: let C = class extends D { constructor(...) { ... }

Re: In ES6, do for loops with a let/const initializer create a separate scope?

On 13 June 2014 18:23, Allen Wirfs-Brock wrote: > We could consider special cases loop bodies that are BlockStatements and > statically reject those that contain declaration that shadow the loop > declarations. However, I think it is probably best to leave that sort of > check for linters to p

Function.create

What's the current status on proposals for Function.create? At present the inability to set a prototype on a Function instance is a real hindrance to creating objects that are both new()-able and have properties. The same goes for creating callable objects that happen to have properties or methods