Brunch: Replace gulp, grunt and increase your dev speed
github.com
github.com
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....
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.
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.
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.
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.
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.
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.
You mean like... make?
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.
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.
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.
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.
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.
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.
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/)
[1] https://github.com/brunch/brunch-guide/search?utf8=%E2%9C%93...
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 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...
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.
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
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.
Check it out: http://ost.io https://github.com/paulmillr/ostio
So much simpler!
The various Rake servers (Puma, Unicorn, etc.) have also done a great job of this.
nitpick: they're Rack servers. Rake is the ruby make.
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.
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!
We do that with gulp, and after the initial file runs (~8-10 seconds), updates are instant every time.
With parched, the idea is very similar:
npm install parched parched-tasks-webapp parched-babel