Hi Tobie, nice to meet you. Some responses inlined below...
On Wed, Feb 24, 2010 at 3:16 AM, Tobie Langel <tobie.lan...@gmail.com> wrote:
> I'm fully aware of the limits of CommonJS at the time being (sync vs.
> async, etc.).
>
> From what I understand, there are plans to address these issues via a
> module loader of some sort.
Right, so what would that module loader look like? It will need to be
one of two things:
1) Use XHR to load the modules.
2) Use a server transform to wrap the module in a function, with
dependencies specified outside that function.
1) XHR to load modules is a net negative for developers. To execute
the code from XHR, either eval() or a script tag with the body set to
the XHR-retrieved text will be used.
Eval:
- Developers have been taught eval is bad. I do not think that is
entirely true, but most of the time, it should be avoided. But we have
anecdotal evidence from Dylan in the Dojo world of Dojo not being
considered because we use eval in our baseline loader
- eval-based debugging is harder. There are some conventions in
Firebug and the latest WebKit debugger to make this easier, but it is
not universal, and I have found the Firebug support to be hit and miss
sometimes.
- Some environments like AIR do not allow eval.
Scripts with inlined body:
- Line number errors are totally off when an error occurs. This is
very hard to use in debugging.
In Dojo, our net experience with XHR+eval has been less than great. We
have created a tax on our developers because of it. Also, it does not
work across domains, which is a common desire for improved
performance. So in Dojo we have a separate XD loader that requires a
build step to wrap all the modules in function wrappers. This is more
machinery, more things to go wrong, and more places for the
abstractions to leak.
2) Server transforms require specific server gear for the developer.
More things to set up. Browser development should be possible with
static text files. It is fine to have server processes to help
bootstrap performance, but it seems like a backwards step in developer
work flow to require it.
The server transform will work by wrapping the module in a function
with its dependencies outside the module. So why not just make that
the module format?
When I bring this up in the CommonJS group, they reject it because I
think it is too much boilerplate typing[1].
However, the delta in boilerplate is not that much more than what is
there now (at least for the syntax I prefer). Also, I consider it a
premature optimization: they are trying to save some keystrokes, but
it makes debugging harder. All that extra time spent in debugging cost
wipes out the savings in typing.
Also, I believe having the function wrapper fits better with
JavaScript. To me, it is more natural to allow a return value from a
function to define the module vs some magic "exports" keyword. And
right now in the CommonJS module spec, you cannot return a function as
the definition of a module. So this means a constructor function
cannot be the definition of a module. That seems like a ridiculous
restriction for JavaScript code. It introduces more typing in module
consumers to get to a constructor function. To me, "exports" is a
wart.
>
> Any reasons why you are trying to circumvent that emerging standard
> altogether rather than pushing for the loader API to be standardized?
Because the traditional CommonJS module format is not browser
friendly. Their target is specifically non-browser JS environments.
Yes, there are things you can do to get it to technically run in the
browser, but it comes at a cost to browser developers. While the
CommonJS group feels that is sufficient for their needs, I do not like
it since I mainly work in the browser.
All that said, I am trying to work with the CommonJS group as much as
I can. I proposed a transport format[2], Transport/C, (maybe that is
what you mean by a loader API?) that can be the output of a server
transform process. I want it to be a format I can hand-author. I have
a script that can convert CommonJS modules to that transport format. I
put in extra support for "exports" and "module" in RequireJS to
accommodate CommonJS modules wrapped in that transport format.
I really am interested in interop. Even if Prototype does not want to
use the RequireJS implementation, if we can at least use the same
"transport format", hopefully something like Transport/C, that would
still be a huge win.
I appreciate the work CommonJS is trying to do, but the group
considers the browser "uncommon" or legacy. I am all for trying to
make a better future, but I do not want to treat the most common JS
environment today as second class -- it should be possible to use some
of the CommonJS work in a way that works well in the browser, and
works how browser developers have worked before, with just plain text
files that do not require extra server gear.
Right now the CommonJS groups is mostly server devs that do some
browser work. I do not believe they are representative of the larger
browser-based JS community. By making sure we give input into the
module format as a baseline, we can hopefully make it better. At the
very least, we should work together to make sure we have something
that works for us.
So I am trying to actively engage, but to me implementations speak
louder than words. RequireJS is an implementation. I have other things
in RequireJS that are not in Transport/C, and I probably need to add
more to Transport/C, like the top-level require([dependencies],
function(){}); type of call. But some of it, like require.modify() in
RequireJS is negotiable, that does not have to be part of any baseline
format.
So hopefully this is the start of a conversation about module formats
that work best in the browser. RequireJS implementing Transport/C is
the way that I wanted to start the conversation. I do not believe the
regular CommonJS contributors are very motivated to finish off the
transport spec, but if we work out what we want from it, then we can
participate and have it ratified.
[1]
http://groups.google.com/group/commonjs/browse_thread/thread/57a46efdcdfce122
[2] http://wiki.commonjs.org/wiki/Modules/Transport/C
James
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
