31–40 of 58 posts
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] [1] https://github.com/raisedmedia/parched [2] https://github.com/raisedmedia/parched-tasks-webapp
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 i…
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 testi…
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 i…
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 r…
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.
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 i…
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.
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…
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...
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 i…
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.
Show 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.
So much simpler!
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.
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.
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…
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 tr…
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.