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.
Yes, the endless complaining that something new-to-the-poster exists is the most tedious aspect of HN. Nobody has time to look at anything new, but they have plenty of time to bitch about it at length.
If people said to themselves, "Nope, don't have time to read some docs," and went about their business without dropping coder angst-bombs, there might actually be useful comments to read that would help someone decide whether looking into Brunch or whatever was worth the time.
I'd also like to point out that even as a Java or C++ programmer you can easily fall behind. I've had the pleasure of working with a "dark matter" Java programmer who had been doing practically the same thing for ten years. He was contemplating reading into some "new technologies" -- none of which was any younger than five years and even so there was no viable upgrade path from where he was.
Go and Java are two entirely different languages so I'm not sure what that comparison was about.
Furthermore, the age of the tool has nothing to do with the fact that there are literally 10 tools that do almost the same thing. But are syntactically and dependency different. It's a huge pain when someone new is hired or you leave for somewhere else. Too many cooks in the kitchen type of thing.
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.
That 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.
Ruby/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.
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.
You're correct that there is probably more excitement for them then there ought to be, considering the simplicity of bash. People ought to create more programs following the UNIX philosophy, which can be chained together using simple pipes.
There are, however, cases where you simply need to use code. In these cases I'd rather use the language I'm developing in rather than bash. I haven't used Brunch for more than a simple project, so I can't really comment on it too much. I have used Gulp though, and I commend its authors for creating great abtractions following the UNIX philosophy in this context.
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.
I feel your pain; try this starter project I created in response https://github.com/mindeavor/node-catapult . It only has three dependencies, yet it gives you a starting point to "npm install" in any direction you need (in the front end too, since browserify lets you require npm modules).
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.
If 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.
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...
At 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.
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]
It'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).
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....