Hi, James.

Thanks for popping in.

I'm working on a Sprockets-inspired CommonJS module implementation
targeted at browsers[1].

It's more of a POC right now than anything else, but with a bit of
polish, I can very well imagine it fitting the bill for most use-
cases.

In a nutshell all it does is a recursive static analysis to collect
the dependencies of the JavaScript file it's fed with.

In production mode, the result is concatenated.

In development mode (not implemented yet as it's server-side
dependant) each file will be wrapped with code similar to your
require.def(...) call and served by it's own static SCRIPT tag thus
preserving file names and line numbers.

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.

Any reasons why you are trying to circumvent that emerging standard
altogether rather than pushing for the loader API to be standardized?

Best,

Tobie

1. http://github.com/codespeaks/modulr


On Feb 23, 2:30 am, James Burke <jrbu...@gmail.com> wrote:
> Hi,
>
> My name is James Burke, and I am usually a Dojo contributor. However,
> I have been working on a standalone, non-Dojo script/module loader,
> RequireJS,http://requirejs.org.
>
> I want to see if Prototype is interested in using it, and if not the
> actual implementation, at least agreeing on the format/API to allow
> better interop.
>
> While a Prototype project is capable of using RequireJS without doing
> any explicit integration with the Prototype Core, there are some
> things that can be done to provide a better experience, mainly making
> sure dom:loaded is not fired until any inflight modules/scripts are
> loaded. This could be accomplished by modifying
> fireContentLoadedEvent() to know if there are require()-ed inflight
> modules and to register fireContentLoadedEvent with RequireJS so it
> can be called when modules are loaded.
>
> Since RequireJS uses dynamically generated script src="" tags, loading
> of scripts/modules is async in nature, and can finish after
> DOMContentLoaded.
>
> While smaller projects may not need a script/module loader, larger
> ones do, and RequireJS has an optimization tool that can be run a
> packaging/deployment time to combine scripts/modules together.
>
> I also believe that browser toolkits should work together to make sure
> they have a loader that works well in the browser. Otherwise, as time
> goes on, we will be pressed to use a format as described by CommonJS,
> which as it stands today does not work well natively in the browser.
>
> If you are interested, I am happy to prep a fork of Prototype that
> shows the integration, with unit tests. I have been able to convert
> Dojo to RequireJS, and have a fork of jQuery with integration and unit
> tests. The jQuery fork assumes optional integration in the JavaScript,
> and I would do the same with the Prototype code, only activating the
> hooks if require is present.
>
> 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

Reply via email to