On Sun, Nov 17, 2013 at 2:23 PM, Matthew Robb matthewwr...@gmail.com wrote:
I like it. If there is a desire to stay closer to script I could see
script module and script module=
Has to be script type=module otherwise it would execute in legacy clients.
--
http://annevankesteren.nl/
On Nov 18, 2013 7:17 AM, Brian Di Palma off...@gmail.com wrote:
Correct me if I'm wrong David but module import/exports are not
dynamic which allows tooling/IDEs to be more intelligent and
programmers to easily understand what dependencies a module
has/provides?
Yes, that's correct, if I
You can statically analyze the module text and enumerate the complete
imports and exports of the module without having to execute the module. The
execution of the module will not dynamically increase it's imports/exports.
For instance could you have a Math.random that decides if a dependency is
Yes, exactly.
Of course, running a module can load other modules using the Loaders API,
but that doesn't add any new imports or exports to the module itself.
Sam
On Nov 18, 2013 8:54 AM, Brian Di Palma off...@gmail.com wrote:
You can statically analyze the module text and enumerate the
On Nov 17, 2013, at 6:14 , David Herman dher...@mozilla.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of the reasons
why script async was a non-starter.)
Is the value of `src` a module ID or a path? How about when packages are used
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Nov 17, 2013, at 6:14 , David Herman dher...@mozilla.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of the
reasons why script async was a non-starter.)
Is
Is the value of `src` a module ID or a path? How about when packages are
used (for bundling)? Is there a way to combine module IDs and packages?
For the most part the answer to these kinds of questions is that we support
all of the above, but I'd like to wait just a little bit longer
On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote:
Could someone help me understand why two goals for parsing JS is a good thing?
Hm, it sounds like you've assumed a conclusion already. Let me try to explain
anyway.
Scripts are for synchronous loading and evaluation;
Does this imply module src= ?
On Sat, Nov 16, 2013 at 12:30 AM, David Herman dher...@mozilla.com wrote:
On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote:
Could someone help me understand why two goals for parsing JS is a good
thing?
Hm, it sounds like you've assumed
On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of the reasons
why script async was a non-starter.)
Dave
___
es-discuss mailing list
3 this, it matches my go-back-to-1995 dreams.
/be
On Nov 16, 2013, at 9:14 PM, David Herman dher...@mozilla.com wrote:
On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of
I like it. If there is a desire to stay closer to script I could see
script module and script module=
On Sat, Nov 16, 2013 at 10:16 PM, Brendan Eich bren...@mozilla.com wrote:
3 this, it matches my go-back-to-1995 dreams.
/be
On Nov 16, 2013, at 9:14 PM, David Herman dher...@mozilla.com
Could someone help me understand why two goals for parsing JS is a good
thing?
On Mon, Nov 11, 2013 at 3:30 PM, John Barton johnjbar...@google.com wrote:
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter =
14 matches
Mail list logo
