Is the world ready yet to get a cross-platform build tool? One that can compile Java, lint Ruby and concatenate JavaScript? Seems like there's a core set of tasks that are pretty common across platforms.
Grunt and RequireJS are out, it's all about Gulp and Browserify
121–130 of 163 posts
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#122Earlier quoted context omitted.
Why even use Make? I just use shell scripts for automation. 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.
Build utilities like Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. I'm not too familiar with Node's support on various platforms, but I'd wager that it's probably decent. Gruntfiles and Gulpfiles are in javascript too, which lowers the barrier for entry for developers who aren't as versed in linux. Is there a shell script equivalent to npm? Sidenote, that could be really u…
> Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be.
On your own stack and dev environment, why would you care about compatibility of shell scripts? Do you change your stack much?
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#123Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#124Earlier quoted context omitted.
To further clarify, RequireJS also allows you to bundle all JS into a single file via the r.js build step. If you're planning on going that route with RequireJS, you should also look into AlmondJS: https://github.com/jrburke/almond
If you do end up using RequireJS, using r.js is practically a requirement. Declaring asynchronous dependencies in a production build is murder for performance. Grunt's grunt-contrib-requirejs[1] does a good job of traversing your dependency graph with r.js and building out a single bundle, but it is not especially quick; it takes about a full 3-5s on my current build. But it's a hell of a lot better than the alternat…
Well you are right for most front-end application, but what is nice to have is modules, and you don't want almond for that. And by modules I mean you have major pieces of application code that you don't want to load until the user triggers an intent to need that stuff. If you have a single page application and most of your users are just consuming content, why load all the config and editing tool JavaScript? Make modules for pieces of your app, and then if needed load the JavaScript for those things. User clicked edit? Ok now load the JavaScript for that stuff.
Browser caching is nice, but if you're doing a continuous integration/deployment type, you're probably invalidating your cache often. If you use a single build you may be invalidating all of your JavaScript for each tiny deploy even though maybe 1% of your JavaScript changed. Another reason to want modules.
I don't know if Browserify can do that.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#125How often do you have so many dependencies in a web app that you actually need something like RequireJS or Browserify?
100,000 lines of JS is best divided into smaller parts.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#126Oooh, look at the shiny keys.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#127And again I'll remind people what happened in Java land: ANT -> Ivy/Maven -> Gradle I'll state it clearly: Grunt. is. Ant. It's a mess to follow a build script and a ritual to make it work in a real life project. I expected a tool like gulp to come sweeping in and it did, I'm extremely happy about that and started migrating away from the horrible tooling that is Grunt. I never understood how people can tolerate Grunt…
I'd say Grunt is Maven because IDEs have no way to figure out beforehand what the build process will do.
That's the opposite of Maven. IDEs know exactly what a maven project will do (unless you're using plugins the IDE doesn't know about), because a maven build only does a very limited set of things (it mostly just compiles the source in src/main/java into target/). Which is what makes it great.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#128Is the world ready yet to get a cross-platform build tool? One that can compile Java, lint Ruby and concatenate JavaScript? Seems like there's a core set of tasks that are pretty common across platforms.
There's not really a lot that's common, and most devs seem to prefer to have their build tool written in the same language they're writing.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#129And 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.
Why even use Make? I just use shell scripts for automation. 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.
Your post just punched me in the gut.
I've spent the last couple of weeks playing the "front end build tool dance" (primarily a back end dev) to find a system I like and it simply never occurred to me I could write my own as a quick bash script or python if I think it'll grow.
That's an embarrassing oversight.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#130Earlier quoted context omitted.
I agree with all but will point out that a benefit to a framework or any extensible tool is community contributions and opting out to native means that you don't get that benefit. That being said, when javascript ES6 modules land it'll be much easier to reuse code and dependency on big libraries would be unnecessary, meanwhile you can use Browserify or Component that have a lot of community contributions with minimum…
We are programmers. Our job is to create abstractions and remove repetition. I understand you're making a general point but what happens when you take your argument further? Machine code? Writing bits to a magnetic platter with a magnetised pin? No. The goal is to find the right abstractions - the right libraries/frameworks/patterns etc. If your tools end up costing you time then the tools are flawed - not the concep…
Having opinions is fun but you misunderstood me with passion :)
I'm simply saying when we have better way to package up software on the frontend there will be less reliance on monolithic libraries and frameworks, the right abstractions will be easier to write, find, and maintain. One of the greatest things about Unix is the modularity and compose-ability and Node.js adopted that philosophy, that's why I recommended Browserify and Component. They are a way to package and distribute the abstractions you speak about.