[adamwong246]

This is so very, very silly. Yes, there are lots of options... just like development on any other platform or in any other language. If you allow yourself to be sidetracked by all the shiny things, of course you'll never get any real work done. And if decision paralysis is preventing you from even starting the project... well, I'm sorry to say you may not have the stamina that's needed to see a project to it's full completion.

Really, it's just so simple- Write the code that does the stuff. That's it. Everything else is bullshit. Pick a framework at random. Don't write tests. Use vanilla javascript. Don't bother with a build tool. That's really all there is to it. Every other decision is premature- you likely do not know your requirements yet, much less understand the costs and benefits of gulp vs grunt. Don't even try. Just start writing. When the problem becomes apparent, then cross that bridge. Yes, you will re-write a lot of code. Pull up your pants and get it done. Re-writing code is always better than never-writing code.

You don't need to collect all your tools before you begin. Just start your work.

[edwinnathaniel]

> Yes, there are lots of options... just like development on any other platform or in any other language.

Errr, not really.

Let's pick a platform/language: Java

Build => maven (majority)

Unit-Test => JUnit (majority), Mockito (helper) Version => don't care, anything from Java 5 and above are good enough

Framework => Spring Framework or JEE (all batteries included)

Keep in mind either Spring Framework or JEE do component libraries so one does not have to use everything in there and they can mix-and-match.

spring-tests component provides stub objects for a few important JEE/Spring objects in case if you need them.

Ok, let's try one more time with: Ruby

Build => gems + rake + bundler

Unit-Test => Test::Unit or Rspec

Version => 1.8.7 or above, not a big issue, (having said that Rails do influence the version uptake)

Framework => Rails, Sinatra

I like what I'm seeing from these two ecosystems: high-quality tools that help me be more productive without spending too much time in either selecting or setting things up.

[jhall1468]

Well if we just want to pick majorities than we can do the exact same thing in JS.

Build => npm + Gulp (optional) + Webpack

Unit-Test => Karma + Jasmine or Karma + Mocha + Sinon

Framework => React+Redux+Data (modular) or Angular (all batteries included)

Same deal. High quality tools. You are pretending that there aren't hundreds of frameworks for Ruby (Cuba, Brooklyn, Scorched, Hobbit). The only people overwhelmed by choices are people afraid to make one.

[edwinnathaniel]

It's not that simple I think.

For example, in the framework front, you guys argued that React is way better than Angular. I don't even know what's going on with Ember.js, Vue.js (fine, I'll give that this one is very new and untested), Backbone+Marionette.

I don't see that kind of argument in the other communities.

Your build: why are you omitting Grunt? What about broccoli and bower? what about Yeoman? Bower is kind of a big deal for front-end dev.

There's no "majority" in the JS world unlike the other ecosystems.

Cuba? I heard Cuba _once_ in HN. Brooklyn and the rest? never heard.

There are bajillion newer Java "microservice" frameworks but the usage is just rounding error.

Also keep in mind that in other ecosystems, the major players are already established while in JS ecosystems, all of them are considered new/young. There is no _established_ players for each tool segment (except unit-testing where I think Mocha is better than Jasmine, unfortunately due to lack of exposure and whatnot, Jasmine is still lurking around)

[golergka]

> Write the code that does the stuff.

But that's far from what I usually want from my code.

I want the code that is easy to change, code that I understand, code that is reliable, code that works well with garbage data, code that will still be maintainable after I extend it. Having reasonable performance (notice, I'm not saying the best performance, just reasonable) is a must, too.

And in most other cases, when I move to a new tech, I get most of it pretty quickly. Of course, there's some learning involved, but I never aim just for code that "does the stuff". Just "doing the stuff" is so abysmally insufficient for good software that I don't expect any programmer to be satisfied with this single requirement.

[adamwong246]

And yet, having a product that just just barely holds together is the best I could have hoped for, given the time and money constraints. And my barely working stack of crap is better than most other products, because most folks can't even get that far.

Easy to change? Reliable?! Maintainable?!?

Bah humbug! Who needs it? Not me. I'll probably trash this version anyways! If I can get the thing to do one thing reasonable well, it's a winner. The code quality is always secondary to actually getting something done. Once you have a product and some customers and you've proven that it won't explode, then we can talk about performance. But I've seen too many projects strangled under the high-minded ideals of better programmers than I.