unscriptable
commented
10 years ago 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
treasonx
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 ofSystem.jsand 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.