Re: Harmony modules feedback
I can have lay load too with yuno ... nobody prevents you to do this
function Whatever(){}
Whatever.prototype.loadModule = function (callback) {
yuno.use("requiredModule", callback);
};
// it could also be directly ...
Whatever.prototype.load = yuno.use;
// in order to be able to load anything needed later
// this won't be compatible with the smart builder though
Above code is already compatible with yuno for browsers ... I keep saying
that both CommonJS require and AMD define do not scale well with all
scenarios:
1. smart build with possibility to create single package "all included"
without code size overhead
2. interoperability between formats
3. backward compatibility with older script that do not export anything
yuno can be shimmed for node.js without effort and be used as AMD loader
with few changes ... the missing part I am working on is the smart builder
but I believe I'll do this in two steps ... still in progress, that's why
I'd like to have feedbacks now
br
On Tue, Jan 17, 2012 at 6:28 PM, Wes Garland wrote:
> On 16 January 2012 14:20, Andrea Giammarchi
> wrote:
>
>> 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?
>>
>
> One fundamental difference between how AMD modules and CommonJS modules
> (presumably Node) load is that CommonJS modules have lazy initialization,
> whereas AMD modules have eager initialization.
>
> This is probably where some of the Node<>AMD "impedance mismatch" is
> coming from -- in CommonJS with Modules/1.0 on the server side, developers
> expect to be able to perform certain types of initialization when the
> module is loaded, and they do not expect to need to pre-declare their
> modules.
>
> It will be interesting to see how the addition of ES.Next modules plays
> out with the server-side JS communities.
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On 16 January 2012 14:20, Andrea Giammarchi wrote:
> 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?
>
One fundamental difference between how AMD modules and CommonJS modules
(presumably Node) load is that CommonJS modules have lazy initialization,
whereas AMD modules have eager initialization.
This is probably where some of the Node<>AMD "impedance mismatch" is coming
from -- in CommonJS with Modules/1.0 on the server side, developers expect
to be able to perform certain types of initialization when the module is
loaded, and they do not expect to need to pre-declare their modules.
It will be interesting to see how the addition of ES.Next modules plays out
with the server-side JS communities.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Tue, Jan 17, 2012 at 3:34 AM, Mariusz Nowak
wrote:
> James Burke-5 wrote:
>> This is provably false. You normally do not need hundreds of modules
>> to build a site.
>>
>
> I wasn't theorizing, I was talking about real applications that are already
> produced.
What I was objecting to is the characterization that an app that loads
hundreds of module would not work and therefore builds are always
needed for all-sized apps. Finding one or two pathological cases does
not prove the need for builds for all people, and I have experience
that points otherwise, even for larger apps. Maybe you did not mean to
take the connection that far, but that is how I read it.
> I think Harmony modules have more in common with CommonJS than with AMD, and
> transition from CommonJS will be easier than from AMD. See slides 86-89 from
> http://www.slideshare.net/medikoo/javascript-modules-done-right (it's
> presentation I've done once on local Warsaw meetup)
CommonJS modules have an imperative require, that is not something
that will work in Harmony modules. AMD does not, which matches the
current harmony proposal more closely. In other words, you can do this
today in CommonJS, but this is not translatable directly to harmony
modules:
var a = require(someCondition ? 'a' : 'a1');
In the current harmony proposals, you would need to use the
callback-style of the module_loaders API to load the module. This
implies an async resolution of the dependency, which likely changes
the above module's API to the outside world.
I agree that the surface syntax of CommonJS looks more like Harmony
modules, but the transform of AMD to harmony modules is really not
that much harder, and translating from vanilla AMD modules (ones that
do not use loader plugins) does not have the kinds of conversion where
the module needs to be manually re-architected, as mentioned above.
> Of course Harmony will allow you to load each module separately, but with
> default syntax I understand it will work synchronously, I'm not sure we will
> do that for large number of modules. For asynchronous loading you may use
> dynamic loader which I think would be great to load bigger module
> dependencies.
Harmony modules will parse the module code, pull out the module
dependencies, load them, do some compiling/linking, then execute the
code. This is similar to what AMD does with this form:
define(function(require) {
var a = require('a');
});
AMD loaders use Function.prototype.toString() and then parse that
function body to find the 'a' dependency, fetches and executes 'a',
then execute this function. Of course this is a bit "low-tech" and
having an JS engine get a real parse tree before code execution is
better. But the end behavior, as far as network traffic, is the same.
James
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
James Burke-5 wrote: > > On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak > 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. > I wasn't theorizing, I was talking about real applications that are already produced. James Burke-5 wrote: > > *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. > I think Harmony modules have more in common with CommonJS than with AMD, and transition from CommonJS will be easier than from AMD. See slides 86-89 from http://www.slideshare.net/medikoo/javascript-modules-done-right (it's presentation I've done once on local Warsaw meetup) Of course Harmony will allow you to load each module separately, but with default syntax I understand it will work synchronously, I'm not sure we will do that for large number of modules. For asynchronous loading you may use dynamic loader which I think would be great to load bigger module dependencies. -- 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-tp33125975p33153466.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153338.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153281.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Mon, Jan 16, 2012 at 9:44 PM, John J Barton 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Mon, Jan 16, 2012 at 9:07 PM, James Burke 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
Again, I sent only to Axel, but meant for the list, resending... On Thu, Jan 12, 2012 at 1:57 AM, Axel Rauschmayer 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Jan 16, 2012, at 1:02 PM, Axel Rauschmayer > > 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 > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 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 > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
@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 -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 <
medikoo+mozilla@medikoo.com> wrote:
>
>
> Mark S. Miller-2 wrote:
> >
> > On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak <
> > medikoo+mozilla@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
> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
Mark S. Miller-2 wrote: > > On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak < > medikoo+mozilla@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 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
> 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 a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
> 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 a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
I have posted about a "better approach" to load modules too talking about
an early state library that already works like a charm:
http://webreflection.blogspot.com/2012/01/y-u-no-use-libraries-and-add-stuff.html
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak < medikoo+mozilla@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. 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33148342.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Thu, Jan 12, 2012 at 1:40 AM, 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 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 sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
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 a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Harmony modules feedback
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
