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.
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Eric B
Sent: Thursday, April
In 10 years, we probably won't be using tools for the modules added in
ES2015, but we might be using them for the changes made in ES2020.
On Thu, Apr 23, 2015 at 7:24 AM, Eric B neuros...@gmail.com wrote:
So just to clarify, when browsers support es6 modules we will still need
some extra
So just to clarify, when browsers support es6 modules we will still need
some extra library to bundle the modules? This would mean es6 modules are
only a syntactical addition and not something functional?
On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi f.bagna...@gmail.com
wrote:
Matthew,
To add one more option. You can create a service worker that loads a single
zip file from the server and then splits it up for the client.
On Thu, Apr 23, 2015, 10:48 Domenic Denicola d...@domenic.me wrote:
Indeed, there is no built-in facility for bundling since as explained in
this thread
See https://github.com/tc39/ecma262. This proposal is currently at stage
one. To find out more about what that means, read the process document
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU
.
On Wed, Apr 22, 2015 at 8:15 AM, Jussi Kalliokoski
Matthew, there are already tools for es6 modules + bundling (e.g. babel +
webpack), or converting es6 modules to AMD (e.g. babel
https://babeljs.io/docs/usage/modules/).
On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
wrote:
Can you clarify what you mean about bundling?
Correct, ES6 has no plans for a bundling solution and the whatwg group
working on the loader has not proposed one.
Nevertheless bundling solution is easier to build and specify. In ES6,
given a root module you can compute the (static) dependency graph as the
basis for creating a bundle. The
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me 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:
James Burke wrote:
It is kind of sad that to use ES modules means to actually not really
use them at runtime, to transpile back to ES5-level of code, and
needing to ship a bootstrap loader script that allows slotting that
the ES5-level code into the ES loader. For the extra script and
Sorry, but what I read was not an explanation but rather a hope that HTTP/2
would magically solve this problem. I'm all for HTTP/2 solving this. But
so far I've not heard or read anything to back up the idea.
Will HTTP/2 make multiple round trips, one for each level of the dependency
tree,
It would be great if the web app manifest included the dependency graph for
the app. Something like the depCache in system js.
On Apr 23, 2015 8:03 PM, Matthew Phillips matt...@bitovi.com wrote:
I think the issue of round-trips is a red-herring. I spent some effort
trying to optimize an es6
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
new.target is available in functions.
On Thu, Apr 23, 2015, 21:02 C. Scott Ananian ecmascr...@cscott.net wrote:
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self
So, why exactly is SuperCall forbidden in function bodies? If people work
around it with Reflect.construct anyways, it just seems nice to use SuperCall
instead — at least if new.target is defined
On Apr 23, 2015, at 9:24 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
new.target is
I think the issue of round-trips is a red-herring. I spent some effort
trying to optimize an es6 loader with caching in indexeddb and even that
did not help much. I think what caridy said earlier is likely the biggest
issue, processing a large number of Promises.
On Thu, Apr 23, 2015 at 7:55 PM,
On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich bren...@mozilla.org 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
16 matches
Mail list logo
