The 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 don't know about you, but in the field of selecting new frameworks I tend to essentially just (mindless) follow celebrities. Some people call me a sheep, but so far, I've found following wycats (rails, emberjs) and his cronies around has paid off tremendously in terms of framework stability for frontend javascript.
On the other hand, the worst way to go about selecting a framework is, in my opinion, benchmark testing (or looking at some blogger's benchmark tests). Your framework might run a million hello world programs faster than mine as of last month, but you have no idea if the people working on the framework will even be around in the next 6 months when your MVP is actually complete. And if you wind up having to solo-support your own dead framework while concurrently trying to run a small business, good luck finding time to build new features, hiring qualified programmers, and not coming around to hate javascript.
The worst part about the comments under any "JS" submission is the amount of time I have to spend to weed through all the "there are too many tools" comments.
Brunch is older than Grunt and Gulp, how is your comment in any way relevant? If this was a post about the advantages of Java over Go would you complain about the amount of time you have to spend investigating various language platforms?
The world is changing rapidly around us, whether we like it or not.
You shouldn't spend that much time obsessing over every new library or tool. If you try to drink from the firehose, you'll either dehydrate or drown.
Instead use a filter. Pay attention to the stuff that makes it to HN, Reddit or DailyJS, yes, but don't wander off reading a dozen articles about every new shiny. Think like a medic during a disaster: learn triage. Learn to quickly assess the general idea of new projects and make a mental note that it is out there and whether it is relevant to anything you're currently doing or planning to do.
If it really is useful, you'll hear about it again. There's no point in getting invested in something nobody else is using. You don't have to be an early adopter of everything. If you see something new you could immediately benefit greatly from, sure, you may want to give it a try right now and see whether you switch everything over to it. But that should happen very rarely.
Your job isn't to know everything or to understand every new technology and be fully prepared to answer any possible question about it. Your job is to get things done. If there are technologies that help you be better at doing that, sure, you should probably be aware of them. But you don't need to evaluate every single one.
If you adopted every single new technology that could be useful to you, your productivity would crash to zero. Adopting something new creates overhead -- unless you're fairly certain that adopting it will save you orders of magnitude more work than it creates, you're not missing out.
I 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.
I 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.
It'd all be so much easier if people just stuck to what's already there. If you use NPM (which, if you're doing modern JavaScript, you should be using) you already have a task runner. If you can write shell scripts (whether actual shell scripts or just arbitrary scripts with a hashbang) you can write tasks. What's more, you can combine existing tasks and everything that has a CLI is already a task:
Seeing all these grunt-* and gulp-* wrappers makes me sad. Unless your project is very complex, all you need can fit in your package.json (and, maybe, some scripts if you can't find anything that already does what you need it to do).
There are some projects that benefit from using dedicated build frameworks like Grunt, Gulp and so on. But the vast majority of projects using them just use them to run one or two tasks that already have a CLI. In those cases it's over-engineering a non-problem.
I agree that AngularJS is needlessly complex. It hides a lot of straightforward ideas behind confusing terminology ("this is a service, this is a constructor, but a constructor isn't actually a constructor, it's a function that creates a service, no not that kind of service, that one's just a function called service because reasons"). But I don't think that's representative of all libraries and frameworks.
jQuery for example, though ridiculed by many at this point, still exists and is still a go-to solution for conventional web pages. If your "app" is just a bunch of static content, it's probably just a conventional website and jQuery is likely sufficient. It's a good general solution and with some discipline you can even solve moderately complex problems with it.
Other projects are not as likely to stick around as long as jQuery has but small and specialised enough that they can be replaced relatively easily (i.e. without a major rewrite of all the code) in the future if necessary.
If you just want to build a website, you can probably get away with using jQuery. If you just want to write a node.js web server, you can probably get away with just using express. If you just need utility functions, you can probably get away with underscore.
Besides, even if you use hot spanking new technologies, you should still strive to make your code as maintainable as possible given what you have. That niche REST framework you built half the application on may need to be replaced, but if the code is readable and grokkable, maybe at least the guy who has to do it will understand what the application actually does.
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.
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/ is a popular flow that's much more plug and play than writing your own gruntfiles/gulpfiles.
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.
To paraphrase Michael Pollan: Write Javascript, not too much, mostly frameworkless.
I sympathize with trying to keep up with tools. I also sympathize with users who don't care about fancy interfaces nearly as much as they care about the information they're looking for. Load times and sluggish UI are killing the web relative to native mobile apps. We're offloading too much of the time-cost to users.
I won't make web apps any more. I use Javascript to add a little bit of ease to website functions, and I can do that with raw Javascript and if it gets complicated, jQuery.
I'm an experienced web developer but most of my projects were started a decade ago. I decided to use all modern tools and techniques for a very small (think two database tables) application. It had to work on mobile and have a good UI.
And on my god, the tools, so many tools. And so much boilerplate. And so much plumbing. I've spent only 50% of my time so far doing actual coding and the remaining 50% configuring tools, pulling down packages, pulling down tools which install other packages, and so on.
Now I will fully admit, the tools are very cool and the results are good but it still feels a bit ridiculous.
You 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.
I 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..
I 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/)
When 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.
It 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.
I 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.
I'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.
Totally 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...
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.
I 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.
I 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.
We 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!
If 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.
We 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.
have always been a huge fan of brunch but lately wanted to take advantage of Gulp and Browserify (https://github.com/mikew/browserify-brunch doesn't really cut it) so I wrote parched[1] and parched-tasks-webapp[2]
[+] [-] jorblume|10 years ago|reply
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....
[+] [-] ffn|10 years ago|reply
On the other hand, the worst way to go about selecting a framework is, in my opinion, benchmark testing (or looking at some blogger's benchmark tests). Your framework might run a million hello world programs faster than mine as of last month, but you have no idea if the people working on the framework will even be around in the next 6 months when your MVP is actually complete. And if you wind up having to solo-support your own dead framework while concurrently trying to run a small business, good luck finding time to build new features, hiring qualified programmers, and not coming around to hate javascript.
[+] [-] xixixao|10 years ago|reply
Brunch is older than Grunt and Gulp, how is your comment in any way relevant? If this was a post about the advantages of Java over Go would you complain about the amount of time you have to spend investigating various language platforms?
The world is changing rapidly around us, whether we like it or not.
[+] [-] pluma|10 years ago|reply
Instead use a filter. Pay attention to the stuff that makes it to HN, Reddit or DailyJS, yes, but don't wander off reading a dozen articles about every new shiny. Think like a medic during a disaster: learn triage. Learn to quickly assess the general idea of new projects and make a mental note that it is out there and whether it is relevant to anything you're currently doing or planning to do.
If it really is useful, you'll hear about it again. There's no point in getting invested in something nobody else is using. You don't have to be an early adopter of everything. If you see something new you could immediately benefit greatly from, sure, you may want to give it a try right now and see whether you switch everything over to it. But that should happen very rarely.
Your job isn't to know everything or to understand every new technology and be fully prepared to answer any possible question about it. Your job is to get things done. If there are technologies that help you be better at doing that, sure, you should probably be aware of them. But you don't need to evaluate every single one.
If you adopted every single new technology that could be useful to you, your productivity would crash to zero. Adopting something new creates overhead -- unless you're fairly certain that adopting it will save you orders of magnitude more work than it creates, you're not missing out.
[+] [-] zrail|10 years ago|reply
[+] [-] andrewmcwatters|10 years ago|reply
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.
[+] [-] Immortalin|10 years ago|reply
[+] [-] fsk|10 years ago|reply
[+] [-] pluma|10 years ago|reply
http://substack.net/task_automation_with_npm_run
Seeing all these grunt-* and gulp-* wrappers makes me sad. Unless your project is very complex, all you need can fit in your package.json (and, maybe, some scripts if you can't find anything that already does what you need it to do).
There are some projects that benefit from using dedicated build frameworks like Grunt, Gulp and so on. But the vast majority of projects using them just use them to run one or two tasks that already have a CLI. In those cases it's over-engineering a non-problem.
I agree that AngularJS is needlessly complex. It hides a lot of straightforward ideas behind confusing terminology ("this is a service, this is a constructor, but a constructor isn't actually a constructor, it's a function that creates a service, no not that kind of service, that one's just a function called service because reasons"). But I don't think that's representative of all libraries and frameworks.
jQuery for example, though ridiculed by many at this point, still exists and is still a go-to solution for conventional web pages. If your "app" is just a bunch of static content, it's probably just a conventional website and jQuery is likely sufficient. It's a good general solution and with some discipline you can even solve moderately complex problems with it.
Other projects are not as likely to stick around as long as jQuery has but small and specialised enough that they can be replaced relatively easily (i.e. without a major rewrite of all the code) in the future if necessary.
If you just want to build a website, you can probably get away with using jQuery. If you just want to write a node.js web server, you can probably get away with just using express. If you just need utility functions, you can probably get away with underscore.
Besides, even if you use hot spanking new technologies, you should still strive to make your code as maintainable as possible given what you have. That niche REST framework you built half the application on may need to be replaced, but if the code is readable and grokkable, maybe at least the guy who has to do it will understand what the application actually does.
[+] [-] 1235971235|10 years ago|reply
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|10 years ago|reply
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/ is a popular flow that's much more plug and play than writing your own gruntfiles/gulpfiles.
[+] [-] roneesh|10 years ago|reply
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
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.
[+] [-] jkestner|10 years ago|reply
I sympathize with trying to keep up with tools. I also sympathize with users who don't care about fancy interfaces nearly as much as they care about the information they're looking for. Load times and sluggish UI are killing the web relative to native mobile apps. We're offloading too much of the time-cost to users.
I won't make web apps any more. I use Javascript to add a little bit of ease to website functions, and I can do that with raw Javascript and if it gets complicated, jQuery.
[+] [-] wvenable|10 years ago|reply
And on my god, the tools, so many tools. And so much boilerplate. And so much plumbing. I've spent only 50% of my time so far doing actual coding and the remaining 50% configuring tools, pulling down packages, pulling down tools which install other packages, and so on.
Now I will fully admit, the tools are very cool and the results are good but it still feels a bit ridiculous.
[+] [-] bryanlarsen|10 years ago|reply
[+] [-] graffitici|10 years ago|reply
[1] https://github.com/brunch/brunch-guide/search?utf8=%E2%9C%93...
[+] [-] ville|10 years ago|reply
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/)
[+] [-] pjungwir|10 years ago|reply
[+] [-] evmar|10 years ago|reply
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|10 years ago|reply
[+] [-] plorkyeran|10 years ago|reply
[+] [-] pbreit|10 years ago|reply
[+] [-] tdumitrescu|10 years ago|reply
[+] [-] _broody|10 years ago|reply
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...
[+] [-] jonahx|10 years ago|reply
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
[+] [-] JohnSz|10 years ago|reply
[+] [-] untog|10 years ago|reply
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.
[+] [-] Ygg2|10 years ago|reply
https://github.com/paulmillr/brunch-with-chaplin/blob/master... https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-... https://gist.github.com/paulmillr/eb3ae139aadbbb87ab9b#file-...
[+] [-] paulmillr|10 years ago|reply
Check it out: http://ost.io https://github.com/paulmillr/ostio
[+] [-] xutopia|10 years ago|reply
So much simpler!
[+] [-] ajsharma|10 years ago|reply
The various Rake servers (Puma, Unicorn, etc.) have also done a great job of this.
[+] [-] JonnieCache|10 years ago|reply
nitpick: they're Rack servers. Rake is the ruby make.
[+] [-] latchkey|10 years ago|reply
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://www.npmjs.com/package/gulp-helpers
[+] [-] jypepin|10 years ago|reply
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!
[+] [-] ben336|10 years ago|reply
We do that with gulp, and after the initial file runs (~8-10 seconds), updates are instant every time.
[+] [-] Raphmedia|10 years ago|reply
[+] [-] Keats|10 years ago|reply
[+] [-] mikewhy|10 years ago|reply
[1] https://github.com/raisedmedia/parched
[2] https://github.com/raisedmedia/parched-tasks-webapp
[+] [-] cozuya|10 years ago|reply
[+] [-] digitalzombie|10 years ago|reply
[+] [-] SippinLean|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] unknown|10 years ago|reply
[deleted]