Rave as a generic loader

[KidkArolis]

I was wondering about the .. purpose(s) of rave.

I can see it's primary objective is to allow very easy development of modular (amd/cjs/es6) web apps where you don't have to worry about configuring any paths, packages, shims, etc. Npm/bower modules can be effortlessly required into the project. So that's all amazing.

However, is the intention to also make rave a generic module loader - a successor of require.js and curl.js? For example, I'm currently using require.js on some third party sites, which means I can't a) leak globals b) rely on any data-attributes c) I don't actually need the package.json/bower.json crawling - instead I want to actually pass in configuration myself - the way I would do it with curl/require.js, etc. Is this out of the question for rave? That's a pity, because Rave enables CJS/ES6 module loading + extension based plugins, plus it's customizable via rave extensions, etc.

If the answer is no - rave is just for developing projects that have package.json and where env is controlled - then I suppose an alternative modern loader is System.js - however in that case - what about building rave (package.json crawling, etc.) on top of System.js and uniting the efforts.

Finally. A slightly different question, which perhaps I should have posted as a separate issue. Would it be possible to write a rave extension that instead of crawling package.jsons would work against a different "API". In particular - it would know about the jspm.io API and how to load packages from there. E.g. if the code has require("cherrytree"); it would fetch the file from https://npm.jspm.io/cherrytree@0.2.1/router.js, and deal with all subsequent nested requires similarly to how it deals with them now but by crawling package.jsons in node_modules. It could even still crawl package.jsons via this jspm.io API https://npm.jspm.io/cherrytree@0.2.1/package.json.

[unscriptable]

Hey @KidkArolis,

The stagnant RaveJS/lode project was created to be the loader behind rave. It became too tough to work on them separately because they were churning too quickly.

I'd love to separate them again, actually.

However, I seriously doubt I'd follow the same path as SystemJS, es6-module-loader, or even the current ES6 Loader spec. I respect what those guys are trying to do, but their approach is unnecessarily complicated and limiting at the same time. My difficulties creating rave -- as well as Guy's difficulties creating SystemJS -- are proof that there must be a better way.

In fact, there is a better way. I've been thinking about -- and prototyping -- cross-format, cross-language loaders for a very long time.

I've tried to communicate with the TC39 guys, but some of them have chosen to ignore me. (They've also decided to ignore James Burke and have alienated the other founding fathers of AMD and CommonJS such as Rawld Gill and Kris Kowal.) Some others on the TC39 team (who don't ignore me) can't fully understand the problems with the current spec since they don't have enough experience with general-purpose loaders.

The only other way I know how to "communicate" with them is to demonstrate and promote a better solution. Unfortunately, I don't have the time to work on both rave and a new loader, atm. Some times, I think about creating a "dream team", perhaps get Rawld, you(?), and a few others together to create something fast, efficient, and simple. At its core, it would be based on promises and streams (likely using when.js and most.js!). (John continues to dream....)

Would it be possible to write a rave extension that instead of crawling package.jsons would work against a different "API".

You can do this now by specifying a different raveMain module. The default is "rave/auto" but you can specify another via the data-rave-main attribute. Let me know if you decide to try this! :) Also, if you have a suggestion for how to make this better, please let me know. :)

[fabricematrat]

If on top of that it uses most.js, I'll join :)

On Fri, Jul 25, 2014 at 6:02 PM, John Hann notifications@github.com wrote:

Hey @KidkArolis https://github.com/KidkArolis,

The stagnant RaveJS/lode https://github.com/RaveJS/lode project was
created to be the loader behind rave. It became too tough to work on them
separately because they were churning too quickly.

I'd love to separate them again, actually.

However, I seriously doubt I'd follow the same path as SystemJS,
es6-module-loader, or even the current ES6 Loader spec. I respect what
those guys are trying to do, but their approach is unnecessarily
complicated and limiting at the same time. My difficulties creating rave --
as well as Guy's difficulties creating SystemJS -- are proof that there
must be a better way.

In fact, there is a better way. I've been thinking about -- and
prototyping -- cross-format, cross-language loaders for a very long time.

I've tried to communicate with the TC39 guys, but some of them have chosen
to ignore me. (They've also decided to ignore James Burke and have
alienated the other founding fathers of AMD and CommonJS such as Rawld Gill
and Kris Kowal.) Some others on the TC39 team (who don't ignore me) can't
fully understand the problems with the current spec since they don't have
enough experience with general-purpose loaders.

The only other way I know how to communicate with them is to demonstrate
and promote a better solution. Unfortunately, I don't have the time to work
on both rave and a new loader, atm. Some times, I think about creating a
"dream team", perhaps get Rawld, you(?), and a few others together to
create something fast, efficient, and simple. At its core, it would be
based on promises and streams (likely using when.js and most.js!). (John
continues to dream....)

Would it be possible to write a rave extension that instead of crawling
package.jsons would work against a different "API".

You can do this now by specifying a different raveMain module. The default
is "rave/auto" but you can specify another via the data-rave-main
attribute. Let me know if you decide to try this! :) Also, if you have a
suggestion for how to make this better, please let me know. :)

—
Reply to this email directly or view it on GitHub
#51 (comment).

Best regards,

┏( ＾◡＾)┛ ┗(＾◡＾ )┓ I rock RaveJS! ┏( ＾◡＾)┛ ┗(＾◡＾ )┓

http://rivieragug.org/
http://3musket33rs.github.com/
http://fabricematrat.github.io/

[treasonx]

I found this thread while looking for a type of "shim" config for rave. @KidkArolis I too have worked in the thirdparty js world for far too long. One solution to your problem of a "controlled environment" is loading your JS in a hidden same domain iframe (the same domain iframe can access the DOM of the parent frame). Its safer and you'll have a lot more freedom and less worry when working in a 3pjs world :)