pushred
commented
10 years ago I'm all about gulp myself now, but from my interactions with Soldius devs even Grunt is pretty mysterious/magical. I still blame this largely on the size of our Gruntfiles post-fingerprinting: they’re intimidating. This could be improved with modules, which gulp more readily supports. But I think it’s also about setting too much of this up from the start. Even the choice of gulp vs. Grunt is pretty opinionated. What if the developer prefers configuration over code? What if they really want to use certain plugins? What if they don’t want to deal with streams and stream-related weird behavior at all? Is Sass the best choice in a node.js environment? The added complication of Bundler/Gemfiles that’s important for dealing with managing the Sass version and keeping that in lockstep with grunt-contrib-sass has also been problematic.
Aside from gulp there’s also these on my radar:
Hell, maybe you’re fed up with all this CLI stuff and want to just buy an app to do it for you: https://incident57.com/codekit.
We can be super opinionated and make these choices for sparkart projects in our fork, but even that can be contentious, i.e. Bower. If someone doesn’t understand the value of something or just straightup doesn’t have a need for it, I’d rather not force it on them. The node way is to compose a solution one problem at a time. Rather than some all-encompassing template that’s ever growing in complexity and opinions we really need a way to add these sorts of capabilities over time as they’re needed. This would provide the flexibility we intended when we removed assets from Solidus while giving developers the opportunity to make the decisions on their own.
There’s at least a couple ways to accomplish this:
- Splitting this repo up into a bunch of examples (or making separate repos) that cover the most common patterns, sort of like TodoMVC.
- Make developers hook everything up on their own, and strive to make things more modular so this is abstracted better.
- Add generator/scaffolding features to either vagrant-solidus or the Solidus CLI. Or just defer to something like yo/Yeoman or Slush.
The latter approach is tempting, and could be quite extensible combined with file-based task loading. But I’m not sure it will make things less magical. Sure there’s the Git diff, that’s one way to see what happens when you run a generator. But some curiosity and desire to learn is still required.
Doing everything manually is the way to really learn how it all works. We could totally gut this repo. But then we end up with projects that are completely different from one another and have all sorts of potential issues.
Would really like to hear everyone’s thoughts on this one.
/cc @monika @krackydile @josiahsprague @joanniclaborde
Related: #10 and https://github.com/solidusjs/vagrant-solidus/issues/5
localjo
Gulp.js is the new big name in asset compilation with node.js. It leverages Streams to greatly increase the speed of compilation, while using a more direct (less giant-object-of-config) approach. I think it's worth investigating a transition to Gulp for the speed increase alone; many people have reported compilation times going from seconds to milliseconds after switching. With our require.js compilations sometimes taking upwards of 4 or 5 seconds, I think it's important that we try and get them speedier to make development easier.