> It's a much newer technology than java

Strangely enough both Java and JavaScript were first released in May 1995. Server side JavaScript was released the same year just after the browser version.

Though I get that you are referring to the js eco systems (commonjs, npm) compared to the much more mature Java ecosystem.

Why is that? In the Java ecosystem there is Spock framework that gives you everything required for testing, you don't even need junit+mockito. In which scenario would be better to use 11 different libraries for doing the same thing as a well written framework?

In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape is what I prefer. Small little library. Its API has everything I need and nothing I don't. Those other test libraries listed are pretty much overkill.

Similar with http://mithril.js.org/ over React, Angular and Ember. A single drop-in library with 13 functions in it's API. The library itself is a single, understandable source code file. Mithril is pretty much the exact opposite of Angular and Ember.

A lot of front end devs are eschewing frameworks completely. With modern DOM and web APIs, you can do a lot with "just" vanillajs.

But, this is exactly what I'm saying. you start with a small, focused library that contains everything you need, which is usually fairly minimal, so that library is small. but then, along the way, you find yourself wanting, so you add a library that adds support for that specific thing.

I didn't add sinon-as-promised for fun, I added it for in-memory sequelize integration tests. same for all the other libraries I mentioned.

My point is that by keeping libraries small, you will end up with either more dependencies, or a lot more hand-rolled code. Neither of these things are inherently bad or good, and I'm not defending them. What I am trying to do is explain to the commenter why the node ecosystem seems to have such an emphasis on package management and the tooling around that.

From the readme I can't really see how to write extensive unit tests with that thing.. If I need to test something I want only one tool that works perfectly and does all the Stubbing, Mocking, verification, data driven test and behaviour driven test. I still haven't found in any language/ecosystem anything comparable to Spock in completeness, readability and ease of use. Honestly I can't really see how to do BDD with tape.

its not that hard. That being said, the current all in one turnkey testing framework for javascript is Jest, and that will pretty much do it all in one tool.

The benefit of what's happening in JS is that a lot of libraries are reasonably compartmentalized for a specific purpose.

As an example: you _could_ have one SpockJS framework that gives you React + Redux + ReactRedux, but instead each of these libraries are separate so you can use them without each other. This allows you to, say, move from React to Angular without changing the state of your application.

With everything moving so quickly in JS, this separation turns out to be valuable enough to tolerate a lot of packages and dependencies. It also makes it easier for communities to exist for solutions to specific problems, which at least in theory results in better solutions.

It's not necessarily better, just a different approach.

For testing it doesn't make any sense. I want a coherent and expressive framework that does everything. If I'm doing BDD I know that I will need everything from the start. And from the little that I have seen about jest..well it seems really a jest. I can't really think to do any serious BDD with that.

Even for testing I think it make sense. If you want to switch from Mocha to Jest and still use Chai for your assertions, you can.

Like I said, it's not better just different.

I guess you could call it "diversification" of dependencies. If one dependency stops being maintained or is not the best approach you can jump to another one.