[jorblume]

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 should really move into Java or C....

[ffn]

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.

[andrewmcwatters]

There's a lot of validity to this, and it's quite wise advice, really.

[xixixao]

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.

[Semiapies]

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.

[pluma]

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.

[jorblume]

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.

[pluma]

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.

[zrail]

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.

[Matachines]

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.

[zrail]

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.

[andrewmcwatters]

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.

[Immortalin]

Relevant Xkcd link: https://xkcd.com/927/

[fsk]

I never understood the excitement for grunt/gulp/etc. People are reinventing Makefiles.

[andrezsanchez]

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.

[pluma]

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:

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.

[amelius]

> It'd all be so much easier if people just stuck to what's already there.

You mean like... make?