6 ms·
Brunch: Replace gulp, grunt and increase your dev speed
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- digitalzombie 11y agoHuh, I always thought Brunch was more of a Yeoman competitor than Grunt or Gulp.
- ajsharma 11y agoI do appreciate when tools/libraries take the time to explain the problem and how they differ from their competition. Especially in cases like this, where it's an underlying architecture difference. The various Rake servers (Puma, Unicorn, etc.) have also done a great job of this.
- JonnieCache 11y ago>The various Rake servers (Puma, Unicorn, etc.) nitpick: they're Rack servers. Rake is the ruby make.
- tdumitrescu 11y agoI've used brunch for a few years now and found it to be quite performant for my personal projects. Once it's set up it just works smoothly. Getting it set up though with the various plugins you need for your own build process can be a bit of a headache sometimes, and I've felt hedged in at certain points by its largely declarative config. I do think the benefits of its building and caching system are worth it for the standard frontend workflow needs and wish it had more mindshare/general community love.
- _broody 11y agoTotally agree with you here. Brunch is fantastic for its minimal config requirements and super-fast performance. Oddly enough, in the JS world I've found it best to ignore all the hype around the latest and newest framework, and just go with something that has a small and loyal following and stick with it. I mean, look at all the people who moved to working with Angular because it was "made by Google, so you could trust it to stick around". Now those people are using React, and soon they'll move to Angular 2. I've found that hyped technologies almost never have a fraction of the robustness and staying power that they claim to...
- pluma 11y agoAt the time I'd been as long with AngularJS as I have been with React now, I despised AngularJS and wanted to violently murder past-me who decided to use it. With React I'm still as confident in my choice as I was a week into using it. In fact, the more I get to know it, the more confident I grow. With AngularJS, it was quite the opposite. If anything I'd say that AngularJS being promoted by Google only made me more cautious about technologies promoted by Google. Google doesn't actually dogfood AngularJS. I know, they have some tool somewhere that uses it and apparently there are people using that tool, but it's not nearly as customer-facing as the code in which Facebook and Instagram use React. But I didn't chose React because of the hype. In fact, AngularJS was still being hyped when I decided to try React. I tried React because someone recommend it to me and told me to give it five minutes of suspended judgement. If I had gone by my first impression, JSX and Facebook both would have scared me off.
- agrippanux 11y agoI wrote Angular for 18 months and this is 100% the process I went through and the decisions I came to.
- mikewhy 11y agohave always been a huge fan of brunch but lately wanted to take advantage of Gulp and Browserify (https://github.com/mikew/browserify-brunch https://github.com/mikew/browserify-brunch doesn't really cut it) so I wrote parched[1] and parched-tasks-webapp[2] [1] https://github.com/raisedmedia/parched https://github.com/raisedmedia/parched [2] https://github.com/raisedmedia/parched-tasks-webapp https://github.com/raisedmedia/parched-tasks-webapp
- cozuya 11y agoI haven't seen anything that matches what gulp can do to make both browserify and babel have working sourcemaps.
- mikewhy 11y agoIt's a great combo. For a while though, Brunch did very similar things, sourcemaps et al, with very little configuration (which is still very clever when you need it). With parched, the idea is very similar: npm install parched parched-tasks-webapp parched-babel And you're good to go.
- jypepin 11y agoWe use grunt at work, and it starts to pain us. Now that our assets pipeline got pretty big, our whole grunt built takes ~30 sec (+10s just for sass and browserify, each). I do feel like most of the slowness is the actual compile time though, not because of grunt or whatever runs the compilation. I'll try to implement brunch and see how it can outperform grunt on this. Hopefully it will make it better!
- Keats 11y agoAre you using libsass? The latest release is pretty much at the same level in terms of features than the ruby one and should be much faster
- ben336 11y agoIf you're doing the whole thing every time, that would be your biggest problem, regardless of tools. It sounds like Brunch does incremental builds out of the box, which would definitely help you, but you can setup Grunt or gulp to do the same thing. It just takes a little work. We do that with gulp, and after the initial file runs (~8-10 seconds), updates are instant every time.
- Raphmedia 11y agoWe switched to gulp and changed the workflow so that it's very fast now. Brunch sounds nice, but we just changed from grunt to gulp, so I doubt anyone has the energy to make the switch once again.
- evmar 11y agoIt looks like this document is a work in progress. Were you looking for feedback on the document? I have used build systems like this (and webpack) so I think I am the sort of person you're looking to win over. The heavy use of bolding makes this read like a pyramid scam and made it hard for me to take it seriously. In all documentation, my main feedback is: the more words you use, the less you're respecting your reader. Your goal should be to wordsmith your text down to convey the maximal information in the least space. You spend a lot of words talking about things about your product rather than talking about your product itself. I was also flabbergasted to discover that popular build systems are not incremental but it'd be more useful to just highlight the distinction and move on. I think it's ok to include a bit of that in your blurb, but even in chapter three you're saying stuff like "We’ve been preaching JS modules for six years" (again with the superfluous bold) which is irrelevant to someone looking to understand what your system does. For another example, you're asking your users to read three paragraphs of "should I use a skeleton" discussion before ever even giving them any insight into whether your system will work for them. I think you could shave that section down to a sentence or two: (1) to get started, I recommend [X]; (2) more experienced users will prefer a skeleton via the [Y] command [link here to the full documentation]. Writing useful documentation is really hard. Good luck.
- paulmillr 11y agoThanks for feedback! We'll adjust some wording. We are always looking for ways to improve the docs / product.
- plorkyeran 11y agoI agree strongly with everything here. I'm a fan of Brunch and would use it again if I ever work on another project where it'd be relevant, but if it wasn't for that I would have instantly written off Brunch after reading this introduction.
- pbreit 11y agoYep. Way, way, way too verbose. Trim it by 90%.
- jonahx 11y agoAlso relevant, How to use npm as a build tool: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
- JohnSz 11y agoI'm rather impressed, especially after using npm for some 4 years without considering this. Thanks.
- bryanlarsen 11y agoYou definitely need a comparison with webpack. As far as I can tell from a quick scan, webpack has all of the capabilities that brunch does. More importantly, it's much more popular, so the plugins and help you need are likely to be available.
- pjungwir 11y agoWhen I read about JS build tools online all I see is grunt/gulp, but when I talk to JS folks in person I keep hearing about webpack and how it does everything they need. Lately my frontend work has used ember-cli for all this stuff, but the next chance I get I'll give webpack some attention.
- wldcordeiro 11y agoIf you're working in Ember there isn't really a use for anything aside from the ember-cli, the community is putting its weight behind it and other tools will be lacking in integration. That said, I've used Webpack lately and Grunt in the past and I've really liked the way Webpack does things.
- ville 11y agoI felt the same way. I'm already sold on the idea of using a proper build tool instead of a generic task runner (happy webpack user for 1.5 years). Instead of telling why it is better than Grunt or Gulp, I'd like to know how it compares to webpack (or browserify, which seems to be quite close to webpack in functionality nowadays, http://reactpodcast.com/2015/06/webpack-vs-browserify/ http://reactpodcast.com/2015/06/webpack-vs-browserify/)
- graffitici 11y agoI agree that Webpack is a serious competitor, and it's rather odd to not even mention it [1]. But I don't think Webpack does incremental compilation, since it usually takes quite a long time for me to compile my modestly-sized assets.. [1] https://github.com/brunch/brunch-guide/search?utf8=%E2%9C%93&q=webpack https://github.com/brunch/brunch-guide/search?utf8=%E2%9C%93...
- jorblume 11y agoThe worst part about web dev is the amount of time spent investigating every little new tool that comes out. It could be useful, it could not, how do you know unless you investigate it yourself? You could easily spend 20+ hours a week just evaluating tools. And not only that, but some of the most adopted tool aren't performant. Grunt sucks. It really does. Angular is needlessly confusing and overly complex for what it actually does. It also doesn't scale and you need to get super hacky with it to perform properly. You spend more time trying to learn new tools than you do actually coding, then find out the tools aren't even well thought out. Then what happens when you leave your position and someone comes in a year later? Oooh, that sass preprocessor doesn't work? What's an angular, some kind of measuring tool? The entire system has a "doesn't matter I'll be at the next startup in 2 years" kind of feel to it. I should really move into Java or C....
- zrail 11y agoI picked a niche awhile back and basically ignore everything outside of that particular light cone. It turns out, this strategy is incredibly lucrative and as a bonus I dont have to worry about learning the tool of the week until it crosses that boundary.
- Matachines 11y agoThat sounds like an interesting strategy. What niche did you end up on? I'm still a young developer so I have time/patience to try new stuff, but I'd love to focus on a niche someday.
- zrail 11y agoRuby/Rails/PostgreSQL, rendering on the server as much as possible, jQuery for client-side stuff as much as possible. I occasionally niche down even further to Stripe integrations within that sphere, but there's not as much work there as I would have hoped.
- andrewmcwatters 11y agoI judge design by how little thought I have to put into using it. I don't need to think through the process of using a hammer. Software tooling is a more complex process than hitting something, but the process never fundamentally changes. The allure of using this is that it's faster, but there is a lot of text talking about itself and it really puts me off. It indicates to me that the author doesn't consider these factors, and possibly ignores others, too. These tools should be concise, and I should be able to get started off a single README.md. Anything less wastes my time.
- 1235971235 11y agoCreated an account for this post only. As a novice javascript programmer, I am hugely confused by the variety of tools being recommended on Hacker News. Choosing and setting up tooling was harder than writing my first app in React. Not a new complaint, I know, but: Is there anything like a best practice in modern javascript development that someone can point me to? Or is there a site that gathers the setups used by prominent front-end developers? Thanks for any advice.
- anabranch 11y agoWelcome to hell. The relentless creation of new javascript frameworks never ceases to amaze. They're all over the place and every one of them claims to be a magic bullet. My recommendation would be to choose one that is extremely stable that underlies a lot of the core principles of other systems. Backbone comes to mind because it's fairly unopinionated about how the system should be built - this makes you understand how data can be tied together, how systems can be structured (because you have to make your own choices) and which ones seems to make the most sense to you. Couple that with something like react and I, personally, think that you've covered a lot of the front-end principles. http://yeoman.io/ http://yeoman.io/ is a popular flow that's much more plug and play than writing your own gruntfiles/gulpfiles.
- roneesh 11y agoThere are few best practices, and the ones we have aren't explicitly stated in one universally agreed upon place. My advice to you is this: 1. Focus on learning Javascript firs and foremost. Kyle Simpson's "You Don't Know JS" series is amazing: https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS 2. Best practices are hard to come by, they essentially are: Crockford's Javascript The Good Parts, The Mozilla JS docs, and some styleguides on Github. Also lint your code through JSLint or JSHint. 3. Don't worry about build tools like Brunch, Gulp, Grunt etc. unless your job forces you to use one. If you're building small sites and apps, you won't need one. 4. When it's time to use a Framework, pick one and stick to it until you know it quite well. Frameworks are very different from one another. Backbone, Angular and Meteor.js are all quite different, but in the end they all do one thing, serve a web app.
- 11y ago
- untog 11y agoShow me the code! There is a lot of documentation here - which isn't a bad thing - but when I'm assessing new tools like this I want to see the code I'll be using with them. My reasons for disliking Grunt can be summed up just be looking at how confusing/verbose the average Gruntfile is. An example of how I declare my Brunch build would be invaluable.
- paulmillr 11y agoHow about a full web application for REST API in Brunch? Check it out: http://ost.io http://ost.io https://github.com/paulmillr/ostio https://github.com/paulmillr/ostio
- Ygg2 11y agoDo these help? https://github.com/paulmillr/brunch-with-chaplin/blob/master/brunch-config.coffee https://github.com/paulmillr/brunch-with-chaplin/blob/master... https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-gulp-js https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-... https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-grunt-js https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-...
- xutopia 11y agoLook at the examples at the bottom of http://brunch.io/ http://brunch.io/ in the section "Why Brunch and not Grunt and Gulp". So much simpler!
- SippinLean 11y agoThe odd bold emphasis on phrases, especially those deserving citation, makes this feel and read like a spam site.
- latchkey 11y agoI like the configuration over code approach, but I feel like brunch swings too much into the direction of configuration without being able to code. There needs to be a middle ground because there will always be a need for specialized tasks without having to rely on creating plugins. I stuck with gulp, but got rid of the repetitive nature of declaring the same task code over and over again by creating a centralized set of functions which generate the tasks for me from configuration and a simple API to execute those functions. This had some other positive side effects, such as making my package.json and gulpfile much smaller. I can also create fixes / features to tasks and all my projects benefit immediately. The main downside to this centralization is that if you need a specific version of a dependency, you have to fork my project and update separately. That said, brunch effectively has this same issue. A lot of the OP's complaints such as slow build times and incremental builds can be solved with a proper pipeline in gulp, but it is harder than it should be to do and really hard to do if you are copying a bunch of random tasks from projects strewn all over the web. wtf is plumber? =) Anyway, I published my little project if you're interested in using it. I use it on a daily basis so it will be actively maintained for a long time to come. I welcome PR's for additional tasks that you think others could use. https://github.com/lookfirst/gulp-helpers https://github.com/lookfirst/gulp-helpers https://www.npmjs.com/package/gulp-helpers https://www.npmjs.com/package/gulp-helpers