--
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
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
On Tue, Jan 17, 2012 at 3:34 AM, Mariusz Nowak
medikoo+mozilla@medikoo.com 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
On 16 January 2012 14:20, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
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
-
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
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
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
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
-
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
/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
@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
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 a...@rauschma.de wrote:
@Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be
used together with almond [2], an
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 sa...@ccs.neu.edu wrote:
As to your current post, I think the fundamental disagreement is all
encapsulated here:
ES harmony may be
On Mon, Jan 16, 2012 at 9:07 PM, James Burke jrbu...@gmail.com 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).
On Mon, Jan 16, 2012 at 9:44 PM, John J Barton
johnjbar...@johnjbarton.com 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
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
On Thu, Jan 12, 2012 at 1:40 AM, James Burke jrbu...@gmail.com 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:
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
18 matches
Mail list logo
