Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.
Grunt and RequireJS are out, it's all about Gulp and Browserify
21–30 of 163 posts
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#22And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#23Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#24This helps with the principle of minimizing divergence between development and production environments.
It's worked well for me for small projects, but maybe there are issues scaling up? Has anyone else tried this approach?
One interesting possibility is make use of the Gulp ecosystem. You could imagine "gulp-middleware" that lets you use any Gulp compatible module on the fly.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#25And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.
Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#26Inside package.json, this will look something like:
scripts: {
"dev": "npm install && make && node lib/server.js"
}
The cool part about putting this in package.json is that it will install first so you get all the dependencies and devDependencies, and then npm sets up the PATH so that you can use all the binaries from all the dependencies you have installed. So you could replace `make` with `grunt` or `gulp` or whatever. And the `npm install` step only makes external requests if you're missing dependencies; when you already have everything you need, it quickly exits.Then getting new developers up and running, even if the build setup changes is the same one and only step. In addition, if you pull new code and the dependencies change, you don't have to remember to run `npm install` because you're doing it every time the server starts.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#27Gulp looks very interesting. Browserify vs. RequireJS seems more complex to me, though - it isn't difficult to use RequireJS in the CommonJS pattern. When I tried Browserify it was incredibly slow to build - but that might have been me setting it up wrong in Grunt...
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#28And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.
The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#29Source maps may help, but many browsers don't support them, and I want to be able to debug everywhere. Plus, when the browserified js actually came from Coffeescript or TypeScript or the likes, I already have source maps in place. Can browserify source map my source maps?
Is there a solution to this? How do browserify fans do this?
I guess what I'd like is for browserify to have a mode that removes the require()s from my .js files and generates a bunch of script tags in the right order.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#30There have been numerous posts stating that Gulp is faster than Grunt. However, the "faster" argument needs to be qualified with "under these conditions ____". Even better, here's my configuration. Here's the processing time of x and of y. With JavaScript builds in particular, it's important to separate when the task running is used. At least in my workflow, I have two distinct times: 1. Development time 2. Build tim…
Gulp seems snappier overall to me for tasks that watch a source directory with coffeescript or sass files in it. Maybe it's grunt-watch vs gulp.watch().
I think Grunt touches the filesystem more than Gulp which could potentially be a bottleneck. The creator (IIRC) of Gulp made a slideshow[0] .
Here's an example Gruntfile[1] generated with Yeoman and generator-angular. And a Gulpfile[2] which does fewer things (no production build yet).
[0]: http://slid.es/contra/gulp
[1]: https://github.com/jjt/dramsy/blob/master/client/Gruntfile.j...
[2]: https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js