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 during
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 car...@gmail.com wrote:
John, there are a couple of solutions at hand that you can apply:
1. loader provides the
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
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
On Monday, June 16, 2014 12:33 AM, Axel Rauschmayer a...@rauschma.de 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
On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer a...@rauschma.de 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
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com 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
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
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
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It
builds on our existing understanding of JS
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
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
Metcalfmailto:calvin.metc...@gmail.com; es-discuss
Steenmailto:es-discuss@mozilla.org; C. Scott
Ananianmailto:ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
From: es-discuss
es-discuss
Steen
es-discuss@mozilla.org; C. Scott Ananian ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using
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 waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at
On Mon, Jun 16, 2014 at 1:06 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It builds
on our existing understanding of
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring
Jasper: none of those things are legal in the current spec
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
On Mon, Jun 16, 2014 at 1:41 PM, C. Scott Ananian ecmascr...@cscott.net 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
On Mon, Jun 16, 2014 at 1:40 PM, Calvin Metcalf calvin.metc...@gmail.com
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
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
A few more thoughts...
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C.
Scott Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It
builds on our existing
@mozilla.org; C. Scott Ananian ecmascr...@cscott.net
Subject: RE: ES6 modules (sorry...)
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C.
Scott Ananian ecmascr...@cscott.net
Using destructuring
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com 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 `a,b,c` and it would all
- Matthew Robb
On Mon, Jun 16, 2014 at 11:42 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com
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
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 = import
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
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
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com 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
On Mon, Jun 16, 2014 at 3:42 PM, caridy car...@gmail.com wrote:
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com
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
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
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 web.
On Mon, Jun 16, 2014 at 4:04 PM, caridy car...@gmail.com 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
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
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
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
On Mon, Jun 16, 2014 at 4:49 PM, caridy car...@gmail.com 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
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't a
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:
I apologize for this email, but I still don’t understand the current module
design.
**Multi-export modules.** Modules made sense to me as long as they were maps
from names to exported values:
```js
// Module 'library'
export function foo() {
}
export function bar() {
}
// Module 'client1'
40 matches
Mail list logo
