Harmony modules feedback

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Harmony modules feedback

James Burke-5
I did a blog post on AMD that also talks about harmony modules. In the
"ECMAScript" section I talk about some of the questions I have about
with harmony modules:

http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html

It is a fairly long post, not all of it applies to ECMAScript, but
some of it ties into my comments on ECMAScript, so I think it is best
to leave it in the blog post vs. reproducing here. Also, I do not
expect answers to my questions right away, just throwing out things
that would be nice to have answered as part of the final design.

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Axel Rauschmayer
I think introducing new language constructs for modules is good, because they are so fundamental. For incrementally migrating old code bases, it would make a lot of sense to allow ES.next modules to import AMDs and vice versa.

Furthermore, npm’s ability to install modules locally and to let local modules shadow global ones is a very smart way out of version hell. It would be nice to have something similar for ES.next modules, but it’ll be harder to do for browsers (as opposed to for Node.js and local file access).

On Jan 12, 2012, at 7:40 , James Burke wrote:

I did a blog post on AMD that also talks about harmony modules. In the
"ECMAScript" section I talk about some of the questions I have about
with harmony modules:

http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html

It is a fairly long post, not all of it applies to ECMAScript, but
some of it ties into my comments on ECMAScript, so I think it is best
to leave it in the blog post vs. reproducing here. Also, I do not
expect answers to my questions right away, just throwing out things
that would be nice to have answered as part of the final design.

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Sam Tobin-Hochstadt
In reply to this post by James Burke-5
On Thu, Jan 12, 2012 at 1:40 AM, James Burke <[hidden email]> wrote:
> I did a blog post on AMD that also talks about harmony modules. In the
> "ECMAScript" section I talk about some of the questions I have about
> with harmony modules:
>
> http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html

Thanks for writing this -- we appreciate the feedback.  [As an aside,
Dave and I still plan to address your point that module instance
objects need to be usable as functions.]

As to your current post, I think the fundamental disagreement is all
encapsulated here:
  "ES harmony may be able to do something a bit different,
   but the basic mechanisms will be the same: get a handle
   on a piece of code via a string ID and export a value."

First, there are two things you might mean by "piece of code".  One is
"the source code for a library/script", which is necessarily
identified by a URL on the Web (perhaps by a filename in other
contexts, like Node).  That stays as a string in every design.  The
other is "a library that I know I have available", and that we're not
using strings for.   Instead, you refer to modules by name, just like
variables are referred to by name in JS.

Second, we don't want to just stop with "export a value".  By allowing
the module system to know something ahead of time about what names a
module exports, and therefore what names another module imports, we
enable everything from errors when a variable is mistyped to
cross-module inlining by the VM. Static information about modules is
also crucial to other, long-term, desires that at least some of us
have, like macros.

Third, the "basic mechanisms" available for existing JS module systems
require the use of callbacks and the event loop for loading external
modules.  By building the system into the language, we can not only
make life easier for programmers, we statically expose the
dependencies to the browser, enabling prefetching -- here, the basic
mechanisms don't have to be the same.
--
sam th
[hidden email]
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

medikoo
In reply to this post by Axel Rauschmayer
rauschma wrote
I think introducing new language constructs for modules is good, because they are so fundamental.
+1

rauschma wrote
For incrementally migrating old code bases, it would make a lot of sense to allow ES.next modules to import AMDs and vice versa.
-1

I'm not sure if I understood this correctly, but trying to support backwards what was never a standard is probably not good idea, and AMD didn't get that much momentum to make exception for that, for many it's still controversial.

rauschma wrote
Furthermore, npm’s ability to install modules locally and to let local modules shadow global ones is a very smart way out of version hell. It would be nice to have something similar for ES.next modules, but it’ll be harder to do for browsers (as opposed to for Node.js and local file access)
It belongs rather to packages concept not modules (at least in that way it originated from CommonJS).
Currently I can't imagine any need for packages implementation in browsers. It's strictly just server-side and I assume it's fine to not have it standardized

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Mark S. Miller-2
On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <[hidden email]> wrote:
rauschma wrote:
>
> For incrementally migrating old code bases, it would make a lot of sense
> to allow ES.next modules to import AMDs and vice versa.
>

-1

I'm not sure if I understood this correctly, but trying to support backwards
what was never a standard is probably not good idea, and AMD didn't get that
much momentum to make exception for that, for many it's still controversial.

While I agree that ES.next modules do not need to worry about AMD if it does not establish itself as a widely used de facto standard, I think we would all be better off if (the core subset of) AMD did become a wild success and ES.next felt the need to figure out how to manage the transition.

The reason being that currently, the only widespread practice for browser programming is to do inter-module linkage by side effecting shared global state, such as new shared global variables. ES.next modules do not and probably cannot offer a smooth transition from this practice. It can at best achieve an uneasy co-existence, which is the most any proposal has offered.

As soon as ES.next modules becomes available in JS engines, server-side programmers can start to use them. The situation is of course much less happy in the browser. Even after all the browsers roll out ES.next, there will be a long fade-out period when programmers will want to write most of their browser-side code so that it continues to work on ES5 browsers (or even ES3 browsers, depending on how the timing works out). While they could use an ES.next to ES3-or-ES5 translator, experience shows that most will continue to deploy code without such a translation step.

AMD is a simple elegant solution for doing inter-module linkage without (much) global state. It works today across browsers, including ES3. We should see if we can identify a translation between well chosen subsets of AMD and ES.next modules. But even if no good automatic translation is found, code written to AMD will be more easily ported to ES.next modules that code written by current web practices.

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Andrea Giammarchi-2
I have posted about a "better approach" to load modules too talking about an early state library that already works like a charm:

AMD is good in theory but as far as I can see it fails miserably when it comes to JS packages.
For JS packages I mean those files where more dependencies are included, rather than loaded on demand.

Regardless the "Y U NO" funny name I chose for my tiny library ( it fits in 1Kb once minzipped ) there are best parts from all other proposals, except the sandboxed nature which is not implemented for browsers right now, but that can be easily implemented in both CommonJS and AMD logic.

The semantic API is also a plus, I don't think I need to explain what are arguments for ... example

yuno.use(
  // multiple requires allowed
  "core",
  "namespace.Generic",
  "other.Whatever",
  "myNMSP"
).and(function (
  // arguments passed as it is for AMD
  core, Generic, Whatever, myNMSP
) {
  // add reflects Object.defineProperty method
  yuno.add(myNMSP, "moduleName", {value: function () {
    // cool stuff here
  }});

  // since "and()" is fired via yuno object
  // old code can be simply used as well
  // so this is possible too
  myNMSP.moduleName = ...

});

// if the module has no dependencies
// we can either juno.add() to define 
// the module or simply 
// myNMSP = .... whatever ...

The main difference from CommonJS world is that the module could receive already defined namespaces in its context
The main difference from AMD world is that module define explicitly what it is about, rather than export.
This makes scalability with pre-compiled JS packages possible, something I am struggling right now with current implementations: synchronous in CommonJS require implemented via node, and not easy to understand runtime with AMD proposal.

If AMD is able to solve this problem too, well ... I will change "yuno" accordingly to make it AMD like ... right now it loads as much as possible in parallel for browsers, and it can be easily implemented for node.js too ( as I have said, it's an early stage )

Best Regards

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Axel Rauschmayer
In reply to this post by Mark S. Miller-2
While I agree that ES.next modules do not need to worry about AMD if it does not establish itself as a widely used de facto standard, I think we would all be better off if (the core subset of) AMD did become a wild success and ES.next felt the need to figure out how to manage the transition.

From where I’m standing, AMD is already a standard in browser space. The only negative reaction I have seen is by Node.js developers – their reasons make sense from a server-centric viewpoint, but (IMHO) less if you are considering the bigger picture of using the same language for client and server. AMD’s greatest advantage is that its core is very simple and that it lends itself to asynchronous loading (which is a must for browsers).

AMD is a simple elegant solution for doing inter-module linkage without (much) global state. It works today across browsers, including ES3. We should see if we can identify a translation between well chosen subsets of AMD and ES.next modules. But even if no good automatic translation is found, code written to AMD will be more easily ported to ES.next modules than code written by current web practices.

+1

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Axel Rauschmayer
In reply to this post by Sam Tobin-Hochstadt
First, there are two things you might mean by "piece of code".  One is
"the source code for a library/script", which is necessarily
identified by a URL on the Web (perhaps by a filename in other
contexts, like Node).  That stays as a string in every design.  The
other is "a library that I know I have available", and that we're not
using strings for.   Instead, you refer to modules by name, just like
variables are referred to by name in JS.

It might be useful not to make that distinction. Node.js does not make it which gives you the possibility to isolate yourself locally from the rest of the system. That is, you can override “system modules” locally.

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

medikoo
In reply to this post by Mark S. Miller-2
Mark S. Miller-2 wrote
On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
medikoo+mozilla.org@medikoo.com> wrote:

> rauschma wrote:
> >
> > For incrementally migrating old code bases, it would make a lot of sense
> > to allow ES.next modules to import AMDs and vice versa.
> >
>
> -1
>
> I'm not sure if I understood this correctly, but trying to support
> backwards
> what was never a standard is probably not good idea, and AMD didn't get
> that
> much momentum to make exception for that, for many it's still
> controversial.


While I agree that ES.next modules do not need to worry about AMD if it
does not establish itself as a widely used de facto standard, I think we
would all be better off if (the core subset of) AMD did become a wild
success and ES.next felt the need to figure out how to manage the
transition.
It's very subjective, for example I don't see any added value in AMD (also subjective). I work with complex JavaScript (on client-side) applications, and AMD is not for us. Let me explain:
The point is that there are two ways of thinking of modules, first is fine grained, when you care about DRY then your modules are rather small, it means that with AMD you would need to load hundreds of such modules asynchronously it wouldn't work even in dev environment. You may say - ok but you may pack it with [your favorite AMD packer] - then I ask, what's the point of using AMD when I don't need to load my modules asynchronously ?

Other way of thinking is bigger picture: it's about modules that are larger packs of small modules that are loaded on demand, and this is when AMD can be useful, however again I don't see a point of using AMD just for that, implementations of AMD that I looked at are heavy and over-bloated for such simple need.

If you look at the most complex JS applications in a web Today (e.g. Google +, Facebook) most of them are built exactly that way, fine grained modules packed into larger packs that are loaded on demand. Facebook even has their own CommonJS style modules packer.

So @axel saying that AMD is already a browser standard and it's just Node.js users that don't like it, is overstatement. I don't see a need for AMD in ES5.next and I'll be happy to refactor my CommonJS style modules for Harmony implementations when it will become a reality.

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Andrea Giammarchi-2
You are underlying my points too .. I am dealing on daily basis with highly dependent little modules and the build procedure takes care of packing everything together before deployment.

However, we are using a synchronous version of require, similar to the one used in node.js but that does not scale the day we would like to go asynchronous in order to lazy load on demand only needed code.

Specially on mobile HTML5 applications where the manifest file is included, the lazy loading is handled by the browser itself and the module will be almost instantly available once required later on if this was present in the manifest.

What is missing is simply a common way that scales across all requirements and I am sure you are using similar approach we do, stripping out requires, used only to order file inclusion before minification, using synchronous loading on demand during debug ... isn't it?

This is OK as long as your requirements won't change and, talking about google, they do lazy load on demand many parts of their namespace too in different applications 'cause a core of 1Mb does not simply scale over 3G connections ... if you don't need that functionality instantly then why creating such big package?

var module = require("module");

is totally fine but 

require("module", function (module) {
  // is totally fine too
});

latter could be synchronous in node.js and asynchronous in the web, who cares, as long as it scales for all scenarios ... don't you agree?

About AMD, yuno is 1Kb minzipped and it resolve dependencies with parallels downloads so you might be interested in having a look.

br




On Mon, Jan 16, 2012 at 7:33 PM, Mariusz Nowak <[hidden email]> wrote:


Mark S. Miller-2 wrote:
>
> On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
> [hidden email]> wrote:
>
>> rauschma wrote:
>> >
>> > For incrementally migrating old code bases, it would make a lot of
>> sense
>> > to allow ES.next modules to import AMDs and vice versa.
>> >
>>
>> -1
>>
>> I'm not sure if I understood this correctly, but trying to support
>> backwards
>> what was never a standard is probably not good idea, and AMD didn't get
>> that
>> much momentum to make exception for that, for many it's still
>> controversial.
>
>
> While I agree that ES.next modules do not need to worry about AMD if it
> does not establish itself as a widely used de facto standard, I think we
> would all be better off if (the core subset of) AMD did become a wild
> success and ES.next felt the need to figure out how to manage the
> transition.
>
>

It's very subjective, for example I don't see any added value in AMD (also
subjective). I work with complex JavaScript (on client-side) applications,
and AMD is not for us. Let me explain:
The point is that there are two ways of thinking of modules, first is fine
grained, when you care about DRY then your modules are rather small, it
means that with AMD you would need to load hundreds of such modules
asynchronously it wouldn't work even in dev environment. You may say - ok
but you may pack it with [your favorite AMD packer] - then I ask, what's the
point of using AMD when I don't need to load my modules asynchronously ?

Other way of thinking is bigger picture: it's about modules that are larger
packs of small modules that are loaded on demand, and this is when AMD can
be useful, however again I don't see a point of using AMD just for that,
implementations of AMD that I looked at are heavy and over-bloated for such
simple need.

If you look at the most complex JS applications in a web Today (e.g. Google
+, Facebook) most of them are built exactly that way, fine grained modules
packed into larger packs that are loaded on demand. Facebook even has
they're own CommonJS style modules packer.

So @axel saying that AMD is already a browser standard and it's just Node.js
users that don't like it, is overstatement. I don't see a need for AMD in
ES5.next and I'll be happy to refactor my CommonJS style modules for Harmony
implementations when it will become a reality.

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo

-----
Mariusz Nowak

https://github.com/medikoo
--
View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33149500.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Axel Rauschmayer
@Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint.


-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Andrea Giammarchi-2
now I am ... thanks for those links, requires optimizer seems already good enough as cross-platform concept

br

On Mon, Jan 16, 2012 at 9:01 PM, Axel Rauschmayer <[hidden email]> wrote:
@Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint.


-- 
Dr. Axel Rauschmayer




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

Rick Waldron
In reply to this post by Axel Rauschmayer

On Jan 16, 2012, at 1:02 PM, Axel Rauschmayer <[hidden email]

From where I’m standing, AMD is already a standard in browser space.

By definition, AMD not a "standard" in the browser space. I challenge anyone to cite more then 5 high traffic sites that actually use AMD. Don't get me wrong, I'm not opposed to AMD, I just don't think it's sparse adoption is grounds to call it a "standard".

The only negative reaction I have seen is by Node.js developers – their reasons make sense from a server-centric viewpoint, but (IMHO) less if you are considering the bigger picture of using the same language for client and server. AMD’s greatest advantage is that its core is very simple and that it lends itself to asynchronous loading (which is a must for browsers).


+1

-- 
Dr. Axel Rauschmayer


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

James Burke-5
In reply to this post by Sam Tobin-Hochstadt
Apologies to Sam, I sent this feedback to just him earlier, but meant
it also for the list, so resending:

On Thu, Jan 12, 2012 at 5:16 AM, Sam Tobin-Hochstadt <[hidden email]> wrote:

> As to your current post, I think the fundamental disagreement is all
> encapsulated here:
>  "ES harmony may be able to do something a bit different,
>   but the basic mechanisms will be the same: get a handle
>   on a piece of code via a string ID and export a value."
>
> First, there are two things you might mean by "piece of code".  One is
> "the source code for a library/script", which is necessarily
> identified by a URL on the Web (perhaps by a filename in other
> contexts, like Node).  That stays as a string in every design.  The
> other is "a library that I know I have available", and that we're not
> using strings for.   Instead, you refer to modules by name, just like
> variables are referred to by name in JS.

I believe this "var name for known modules" creates a two pathway
system that does not need to exist. It complicates module
concatenation for deployment performance. Also, it precludes allowing
things like loader plugins from being able to inline their resources
in a build, since loader plugin IDs can have funky characters, like !
in them.

For me, having (ideally native) support for loader plugins really
helps reduce some of the callback-itis/"pyramid of doom" for module
resources too (as demonstrated in that blog post).

> Second, we don't want to just stop with "export a value".  By allowing
> the module system to know something ahead of time about what names a
> module exports, and therefore what names another module imports, we
> enable everything from errors when a variable is mistyped to
> cross-module inlining by the VM. Static information about modules is
> also crucial to other, long-term, desires that at least some of us
> have, like macros.

I believe loader plugins are much more valuable to the end developer
than the possible advantages under the covers to compile time wiring.
Says the end developer that does not have to implement a VM. :)

Since loader plugins require the ability to run and return their value
later, compile time wiring would not be able to support them. Or maybe
they could? I would love to hear more about how that would work.

As mentioned in the post, some of that static checking could be
achieved via a comment-based system which optimizes out cleanly, and
would give richer information than what could be determined via the
module checking (in particular usage notes). It is not perfect, and a
very easy bikeshed, but I believe would simplify end developers' lives
more. But let's put that on the backburner, I do not want to get into
what that might look like.

The main point: the compile time semantics in the current proposal
make it harder (impossible?) to support loader plugins and do not
allow for easier shimming/opt-in. As an end developer, I do not like
that trade-off.

But this is hard work, and you cannot please everyone. Just wanted to
mention that there are concrete advantages to an API that allows some
runtime resolution. Advantages I, and other AMD users, have grown to
love since they simplify module development in an async, IO
constrained environment.

Maybe my understanding is incomplete though and loader plugins might
be able to fit into the model.

> Third, the "basic mechanisms" available for existing JS module systems
> require the use of callbacks and the event loop for loading external
> modules.  By building the system into the language, we can not only
> make life easier for programmers, we statically expose the
> dependencies to the browser, enabling prefetching -- here, the basic
> mechanisms don't have to be the same.

Dependencies as string names still seem to support giving the browser
more info before running the code, even in an API-based system. I
really like the idea behind the module_loaders and node's vm module,
and I can see those kinds of containers being fancy enough to pull
this info out.

Thanks for the feedback,
James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

James Burke-5
In reply to this post by Axel Rauschmayer
Again, I sent only to Axel, but meant for the list, resending...

On Thu, Jan 12, 2012 at 1:57 AM, Axel Rauschmayer <[hidden email]> wrote:
> I think introducing new language constructs for modules is good, because
> they are so fundamental. For incrementally migrating old code bases, it
> would make a lot of sense to allow ES.next modules to import AMDs and vice
> versa.

I don't see ES.next modules being able to natively import AMD modules,
particularly if the "compile time binding for
'module'/'exports'/'import' are in play. I'm happy to be wrong though.

What I do not like is the "just run this conversion script". I would
like today's scripts to be able to easily opt in without having to
provide two versions or force conversion work. And being able to shim
an ES module API now for trial use on the web today would be useful to
shake out the kinks. In particular, there are some choices around
module ID resolution that us folks in AMD-land are still shaking out
(more below). Although the answer for that could be just "let node and
the AMD folks test those areas and feed that back into the
syntax-based design".

I appreciate this is a hard problem. My main point is that what might
look like a simple syntax inside the module have complications outside
of it, particularly for code mixing. To be clear I'm not against new
syntax at all in the language, it is just that for being able to get
handles on code units is pretty fundamental, and being able to use
code on the web today as part of graduating into natively supported
modules would ease adoption and reduce developer swirl.

But the folks working on the module stuff here might already have
plans for all of that. I'll be happy to see it laid out at some point.

> Furthermore, npm’s ability to install modules locally and to let local
> modules shadow global ones is a very smart way out of version hell. It would
> be nice to have something similar for ES.next modules, but it’ll be harder
> to do for browsers (as opposed to for Node.js and local file access).

I expect part of the path resolution logic will not be possible to
mandate in an ES spec. Or at least, there will be different rules for
things like node vs browsers. For browsers, everything is effectively
local, and you get one network lookup path. We're still working
through some of these issues on the AMD-implement list, particularly
around multiple versions of a module in a project. Node's nested
node_modules is not efficient for the web. I think we have worked
something out though in the "map" config discussed here:

https://groups.google.com/group/amd-implement/browse_thread/thread/c36e284a7f85021a

That thread also has some details on what sort of tradeoffs there are
for baseUrl + moduleId + '.js' lookup rules vs a "package" system with
a "main".

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

John J Barton
In reply to this post by James Burke-5


On Mon, Jan 16, 2012 at 9:07 PM, James Burke <[hidden email]> wrote:

I believe loader plugins are much more valuable to the end developer
than the possible advantages under the covers to compile time wiring.

(I hope this is related; if not, just erase this line and the two quoted above).

Doesn't "Script-loader" make about as much sense as literal "XML HTTP Request"? Imagine how impoverished our Web App world would be if it had turned out that Ajax only supported valid XML. 

Shouldn't the API in http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders be split into one layer that takes URL -> buffers and another that takes buffers -> modules?  Then clever folks can do clever things with and between the two layers.

jjb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

James Burke-5
In reply to this post by medikoo
On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak
<[hidden email]> wrote:
> The point is that there are two ways of thinking of modules, first is fine
> grained, when you care about DRY then your modules are rather small, it
> means that with AMD you would need to load hundreds of such modules
> asynchronously it wouldn't work even in dev environment.

This is provably false. You normally do not need hundreds of modules
to build a site. But even then, I know of very big, webmail-class web
apps, AOL Webmail in particular, that loaded all module individually
in dev. This was with the old dojo module system, but similar idea to
modular loading. I believe the Closure library works in a similar way.
That worked fine, and given the debugging capabilities of browsers,
works the best for development. The load cost on a developer's desktop
is not a factor, particularly given the easier debugging it enables.

Could it be faster? Yes, and in the dojo case, switching to async
script tags via AMD made it faster. But building one big file and
trying to debug that is not the answer.

*But more importantly*, harmony modules also seem to be designed to
allow a separate request for each module. So your dislike of that
attribute will not go away with harmony modules. Harmony modules may
not need the function wrapper around the code as AMD does, but the
network request behavior will be similar to AMD.

In both AMD and harmony modules, you can use build tools in dev if you
like, perfectly fine. However, mandating build tools just to get
started with modules is not an easily scalable answer. It is is
favoring complexity outside an individual module to avoid a function
wrapping inside a module (in today's world with AMD -- hopefully not
required in harmony). Complexity via tool selection, installation and
configuration. Usually a different configuration when in dev vs.
deployment. It also means that developers have to make a choice, do
extra work to share their modules on CDNs.

> So @axel saying that AMD is already a browser standard and it's just Node.js
> users that don't like it, is overstatement. I don't see a need for AMD in
> ES5.next and I'll be happy to refactor my CommonJS style modules for Harmony
> implementations when it will become a reality.

I believe Axel overreached in that comment. However, AMD is looking
really strong: multiple, thriving implementations that are
coordinating on specs, support in base JS libraries, and use on real
sites. There is not another option for browsers today that has that
type of breadth and depth. "Use tooling to bundle up CommonJS modules"
does not allow for dynamic loading, even of built resources. The
"tooling+CommonJS" approach is incomplete. It does not get into some
of the harder bits of web delivery.

I am hoping for something better than AMD in the next ES, and
hopefully AMD can better inform that effort -- be the one to run
through the gauntlet and hit all the nasty bits. That was the point of
the ECMAScript feedback section in the blog post.

On that note, back to the main thrust of that feedback, mostly
summarized as: the compile time leanings and new syntax in the harmony
proposal have some disadvantages, and at least at the moment with my
current understanding they outweigh the advantages, at least for me as
an end user. Some things are just tweaks on the existing proposal
though, like always using string IDs.

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

James Burke-5
In reply to this post by John J Barton
On Mon, Jan 16, 2012 at 9:44 PM, John J Barton
<[hidden email]> wrote:
> Doesn't "Script-loader" make about as much sense as literal "XML HTTP
> Request"? Imagine how impoverished our Web App world would be if it had
> turned out that Ajax only supported valid XML.
>
> Shouldn't the API
> in http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders be split
> into one layer that takes URL -> buffers and another that takes buffers ->
> modules?  Then clever folks can do clever things with and between the two
> layers.

There are two things:

It would be nice to set up a module that can be used to resolve some
types of "module"/resource IDs that are not just a simple static
script request. This should be possible without having to have a
bootstrap script that sets up a resolver in a script file -- if I need
a specific bootstrap script before loading any modules, this does not
give the harmony infrastructure much of an advantage over what can be
done today in AMD, as far as initial developer setup. This would help
with the async callback nesting needed otherwise. Note that the
resolved resource may not be a transformed piece of text, but an image
or a CSS file that is attached to the DOM and loaded. It could also be
a resource assembled from a few text resources, like an i18n bundle.

Second, having something like node's vm module would be nice for text
targets. Or maybe it is like you mention, it gets called on completion
of the text fetch, and allows transforms, then execute and have it
interpreted as a module, optionally in a sandbox. But that starts to
feel like it is drifting from the desired compile time attributes
currently specified for harmony modules. Maybe not though, maybe the
compiling waits for those transforms to complete. Although ideally the
transformers are modules.

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

medikoo
In reply to this post by Andrea Giammarchi-2
Andrea Giammarchi-2 wrote
You are underlying my points too .. I am dealing on daily basis with highly
dependent little modules and the build procedure takes care of packing
everything together before deployment.

However, we are using a synchronous version of require, similar to the one
used in node.js but that does not scale the day we would like to go
asynchronous in order to lazy load on demand only needed code.
On our side we're using version of require that's exactly same as in Node.js (we also use Node.js and some modules are used on both sides) and asynchronous loading in our case would rather be on package level not module level (Node.js thinking) but even not exactly that way. It's more about packs of modules that are needed to run other functionality (that we prefer to load on demand) and those modules may come from various packages. That's the approach we currently feel is right. We're using modules-webmake [1] for client-side builds, but it's still limited as it doesn't support yet "intelligent split" so modules are not duplicated in two different packs, however we plan to address that soon.

Andrea Giammarchi-2 wrote
Specially on mobile HTML5 applications where the manifest file is included,
the lazy loading is handled by the browser itself and the module will be
almost instantly available once required later on if this was present in
the manifest.

What is missing is simply a common way that scales across all requirements
and I am sure you are using similar approach we do, stripping out requires,
used only to order file inclusion before minification, using synchronous
loading on demand during debug ... isn't it?
We don't strip out requires, we were thinking about that, as it would produce bit shorter and cleaner code (thinking one file) but the more we work with Node.js style modules the more we acknowledge it may be quite hard to achieve (unless you stick to some strict simple rules) but still I don't see it as big deal, footprint that is currently added by modules-webmake[1] is only 55 lines of code, and so far we don't feel it affects performance of our applications.
We debug with not minified version of generated file, output from webmake is very clear, and modules that were concatenated are not changed and usually not big so it's easy to get around.

Andrea Giammarchi-2 wrote
This is OK as long as your requirements won't change and, talking about
google, they do lazy load on demand many parts of their namespace too in
different applications 'cause a core of 1Mb does not simply scale over 3G
connections ... if you don't need that functionality instantly then why
creating such big package?

var module = require("module");

is totally fine but

require("module", function (module) {
  // is totally fine too
});

latter could be synchronous in node.js and asynchronous in the web, who
cares, as long as it scales for all scenarios ... don't you agree?
Personally I don't like the need of extra closure. I want to be able to write my code directly in a file. It may be a picking, but it's like introducing to each of your modules extra maintenance code which has nothing to do with logic of that module, I tend to avoid that as much as possible.

Andrea Giammarchi-2 wrote
About AMD, yuno is 1Kb minzipped and it resolve dependencies with parallels
downloads so you might be interested in having a look.
I looked at that with interest right when you published it, but currently I really like the way modules work in Node.js, I'm fine with modules-webmake, and I think it's currently the closest you can get to what will be introduced in future with Harmony, so I plan to stick to that.

[1] https://github.com/medikoo/modules-webmake

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
Reply | Threaded
Open this post in threaded view
|

Re: Harmony modules feedback

medikoo
In reply to this post by Axel Rauschmayer
rauschma wrote
@Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint.

[1] http://requirejs.org/docs/optimization.html
[2] https://github.com/jrburke/almond
@Axel I read about it before, when we talk about synchronous loading then Node.js style modules with help of modules-webmake[1] is simpler and more powerful. I feel it's obvious.

[1] https://github.com/medikoo/modules-webmake

--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
12