The first thing that rave must do is simplify module loading: AMD, node, and ES6 modules. There's almost enough metadata in package.json and bower.json files to eliminate loader configuration. We can provide heuristics and conventions to fill-in the missing data.
If a developer wants to add a new capability to an application's loader, she should install a third-party integration package. The third-party package, called a "rave extension" will provide the capability, as well as enough metadata to configure the capability automatically. In cases that require configuration, the rave extension should choose a mildly opinionated default config.
We've already got this working fairly well. There are almost a dozen rave load extensions available on bower and npm at this time.
No developer should be forced to configure a build process, a file watcher, or a compiler before embarking on a new app. However, no app can go to production without being built. Therefore, we have to allow the developer to start developing without a build process, and then adopt one at any time. If she/he decides to go back to the unbuilt application, she/he should also be able to do that without effort.
It needs to be this easy:
; transition from dev mode to production mode
rave build; transition from production mode back to dev mode
rave unbuildThe shell commands above are just to illustrate a concept. It doesn't make sense to recreate what gulp and grunt already provide. We should leverage gulp and grunt as much as possible (likely starting with gulp).
As with loading, we should eliminate configuration. If there were a way to drive gulp programmatically (i.e. without a gulpfile), then we could provide build processes through rave extensions.
Would something like this be possible?
gulp rave buildThere are so many build patterns and build tools available. It's likely
that we can't provide one pattern "out of the box" that will satisfy more than
a minority of developers. For this reason -- as well as to make rave feel as
lightweight as possible -- we should consider not providing any build
patterns out of the box. Instead, if a user invokes the build process
(via gulp rave build, or however it will come to be invoked), we should
display a message suggesting that they investigate their options and then
choose their favorite rave build extension.
Fwiw, our favorite build pattern is not bundling! If we've learned anything from AMD, it's that module bundles are problematic. We've been leaning towards alternatives such as modules-over-websocket or Zip Archives. We are prototyping a Zip Archive shim called zurl.js and it seems to eliminate 90% of the problems innate to module bundles.
Both the SystemJS folks and the TC39 team have devised a way for ES6 loaders to load bundles. Unfortunately, these bundles have most (if not all) of the same problems as AMD bundles. Let's try to avoid bundles, if at all possible.
Inherent in most build processes is a deployment step. Once the modules, css,
templates, etc. have been transformed, minified, and concatenated, they must
be saved to a certain location. In a SPA, the location is likely in the same
folder, a.k.a. "in place". In a Java-backed app, the location is typically
in a temporary build/ folder where the artifacts can be moved to their
ultimate location.
In most deploy scenarios, certain files need to be modified to reflect the
new location of the artifacts. For instance, some devs prefer to modify the
HTML document(s) to point from the development location to the production
location. For instance, a script element's src could change from
"/client/boot.js" to "/boot.js".
Another method is to leave the HTML intact and replace the files referenced
by script.src (or link.href) attributes with the built artifacts.
I think we prefer the latter method, so rave will likely provide this deploy pattern "out of the box". Other deploy patterns, such as HTML rewriting, will be installed as rave extensions.
Perhaps it will be crystal clear later, but I haven't spent enough time to know what rave test patterns might look like. However, it seems rave isn't complete if it doesn't assist in unit testing and continuous integration. This aspect of rave must be explored in the future.