volo feedback
jrburke opened this issue · 16 comments
Seems fairly accurate for volo's points, some small details:
- Right now volo only does zipballs, not tarballs. Although this is easily fixed now that it is a plain node/npm package.
- multiple "baseUrl" values: they are a result of me feeling out the best thing to use. I have settled on volo.baseDir more recently. The baseUrl thing comes from AMD loader configs, but in this context where a project is getting a dependency in its file system, baseDir makes more sense. I'm learning as I go, and will likely deprecate the other options over time.
On volo doing too much, I left this comment going more into that, but basically, creating a new project or downloading a dependency can both benefit from the github ID lookups and installs, so I really see them as the same thing. Similarly, it is useful to have some sort of makefile capability for setting up dependencies/new projects. It looks like component also has something for this. I am open to limiting the scope of it though for volo.
In #1, @visionmedia mentioned:
jam / volo / ender and the twitter thing coming soon are unfortunately all nearly identical and don't really solve any new problem, pretty much the same as https://github.com/visionmedia/asset
I see volo and component to be very similar, except volo assumes the same conventions that an AMD loader might use for a convention-based project layout, so the loading of installed dependencies is easy with that type of loader, and the build step handled by something like r.js optimizer. It is a decoupled system that I also thinks fits in well with ES harmony modules, which will allow dynamic loading.
So, volo create with a project that uses an AMD loader/builder gets whatever component may additionally add, particularly since many AMD loaders support loader plugins for things like text/html template loading. However, volo does not enforce a particular build philosophy on the runtime code, so still usable as a way to get code even if you do not use AMD or commonjs-style.
But these things are highly style driven. I'm hoping that if we get a good module support in ES harmony, then it will clear up some of these choices. My feeling right now: ES modules will behave at a high level similar to AMD, just without needing a function wrapper, and builds will not be required for doing front end dev.
I am definitely warm on the volo create sugar now. I've updated the comparison to reflect this. I've learned so much about volo by doing this. Thanks for clearing things up.
I also feel like with ES harmony on the way, require being able to shim over that syntax will be helpful. I'm currently writing my modules in the "define + require" style which is basically CJS wrapped in a define. Short of ES harmony, that seems like the best compromise for me. Ultimately, I love that component(1) mimics the NodeJS/CJS unwrapped style, but I can go either way.
The build step does suck but it's not the end of the world, everyone
already loves coffeescript and goes through the same thing, most devs are
really into these --watch flags for TDD etc as well so it's effectively
just another one of those tools, and you can produce stand-alone builds for
non-component users, though you'll have a lot of duplicated deps if you do
that a lot... but that's a fundamental flaw with the js community in
general right now. The ES board is pretty terrible at making decisions IMHO
but I guess we'll see what they go with :s
On Thu, Sep 6, 2012 at 1:42 PM, Wil Moore III notifications@github.comwrote:
I also feel like with ES harmony on the way, require being able to shim
over that syntax will be helpful. I'm currently writing my modules in the
"define + require" style which is basically CJS wrapped in a define. Short
of ES harmony, that seems like the best compromise for me. Ultimately, I
love that component(1) mimics the NodeJS/CJS unwrapped style, but I can go
either way.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-8346794.
The build step does suck but it's not the end of the world
I don't necessarily mind the build step if it buys me something interesting.
I'm starting to wonder if component(1) should actually only sit at that higher application level.
For instance, let volo or jam handle small JS libs like component/mime. Those can be done in CJS or AMD style. Whatever works for the dev.
Then, in your app, you use component(1) to build higher-level reusable widget-like components out of JS libs + HTML + CSS + whatever.
Does that even make sense or is that just completely missing the point?
welll component build is only a convenience thing, we do on-demand builds that take ~300ms or so in our app with Stylus etc so it's more complex in that sense, but otherwise we don't notice the build step is there at all, it "just works"., it's definitely a barrier to entry though I wouldn't deny that.
that would be fine, but personally that's the exact thing I want to get away from, I don't want any more globals, I dont want stupid plugins hanging off of $, I dont want AMD codesmell (i'd rather trade for build codesmell haha). Doing component build --standalone and adding that to the git repo would allow other people to use mime etc just fine, but that's not my primary concern, if you want something to work for everyone it still requires that awkward amd/exports/global dance that everyone does anyway
hell we could have component build --amd as well, I just don't think developing with AMD in mind is a very enjoyable thing, for myself at least personally. To me that's an implementation detail, something more declarative is nicer to work with
The build step does suck but it's not the end of the world, everyone already loves coffeescript and goes through the same thing [snip]
Right, and AMD users can use coffeescript via loader plugin, no need to do builds. By starting with the design goal of making sure a browser-based system could work without a build, it better solves the problem. Whatever ES decides for modules, it seems very unlikely that it will be a system that requires builds to use them.
For instance, how will dynamic loading of the next layer of functionality work with component? Not every app wants to load all of its resources in one script file, they prefer to delay loading until the functionality is needed. What if I want to use a CDN-hosted library for jQuery?
cajon might be useful to consider. It can do CJS style and AMD dynamic loading, falling back to XHR+eval for the dynamic CJS case. If you format the build output to use AMD modules, since they will be wrapped anyway, that may allow better code/tooling reuse. You could even use almond if you wanted a require/define API that was fairly small and supports loader plugins that inline their resources in the build, like the text, coffeescript, handlebars templating plugins can do. The r.js optimizer can build CJS modules into AMD for the built files via cjsTranslate: true.
Anyway, you may already be aware of these things, I am unlikely to provide any more useful feedback, and this is getting outside the scope of this thread, so I'll leave it at that.
well you could still use components without a build step, you effectively just do the build in the browser, not a whole lot different for development than just loading them, maybe a few milliseconds slower.
you could easily have (and we do this) a subtree of the component deps built / shipped off much like AMD. I'm not saying it's "better" than AMD it's just a different solution, still capable of the same things, much like coffeescript is hacked into most things require() in node etc
Sorry for being totally off topic but @visionmedia how could one do a component build "in the browser"? I would really like to just reload the browser and see the effects immediately without calling the build command.
@alexlawrence we use the builder in our app to re-build on request in development mode, however as a quick alternative if you dont want to integrate the builder with a bit of code you can simply background it $ watch make & then fg when you're done, and its as if there is no build at all
I forgot to say thank you @visionmedia ! :) While I haven´t had a look at the source code (or I´ve forgotten it again) I had the impression the the builder in component is a lot like browserify. Is that right?
@alexlawrence similar conceptually yeah, we're just taking it further with assets, and none of the node core boilerplate
I promise I stop being offtopic after this post :D
component seems like a really cool project! I´ve been reading a lot about the different (frontend) package managers. I like the fact you´ve chosen CommonJS Modules as module format. I will definitely give it a try. Only thing I didn´t get so far is why you aren´t using the package.json with some additional section. But I don´t want to start discussion here. Just let me know if you have additional resources/infos on that. Thank you.
yeah i've been documenting some of decisions in https://github.com/component/component/wiki/F.A.Q
Thanks!
Good discussion. Just as an FYI, I'm probably stuck with AMD for a current client project (other devs are convinced AMD is the way; I'm not so sure anymore), but likely going to be using component for the next.