Mutable bindings have valid use cases for object properties as well. My - very
late - vote is for modules to use the same destructuring syntax as objects.
Just leave out mutable bindings in modules for now. That way both modules and
objects use the same syntax and that syntax means the same th
I guess there is no technical argument that will convince you. Thanks for
at least having the discussion, more than we got before.
jjb
On Mon, Jun 16, 2014 at 9:02 PM, caridy wrote:
> John, there are a couple of solutions at hand that you can apply:
>
> 1. loader provides the right hooks for y
There are two options for prefetching dependencies without having to wait for
"load" and "parse":
1) Assume none of your modules use the loader object for loading other modules,
parse them during deployment and get the dependency graph.
2) Use what Guy calls a "tracer" that executes your app dur
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/
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
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
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
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
> > 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
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
>
>
> 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
> 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
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
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
> 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
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
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
- 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
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
;
>> - Matthew Robb
>>
>>
>> On Mon, Jun 16, 2014 at 10:24 AM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>> I'm not talking about MIO properties. I'm talking about the bindings
>>> created by import declarations.
>> 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 ;
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
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:
>>
>>
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
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
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.
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
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
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
menicdenicola.com> wrote:
> 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 Metc
gt;
Cc: Calvin Metcalf<mailto:calvin.metc...@gmail.com>; es-discuss
Steen<mailto:es-discuss@mozilla.org>; C. Scott
Ananian<mailto:ecmascr...@cscott.net>
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, "Domenic Denicola"
mailto:dome...@domenicdenicola.com>&g
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;
//
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.
>
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
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
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
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
>
>
>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
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
39 matches
Mail list logo
