11 ms·

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude s

I have no idea if you're familiar with the java ecosystem, but I am, so I'll use that as an example: Node libraries are typically several orders of magnitude smaller and more single purpose than java libraries. Java libraries like Guava and Spring are typically quite large. A practical example is from unit testing: In Java, you might use JUnit+Mockito for your test dependencies. In Node, to get similar functionality, I have the following deps: Mocha, Sinon, Sinon-As-Promised, Chai, Chai-Moment, Chai, Chai-Things, Chai-Shallow-Deep-Equal, Chai-Datetime, Sinon-Express-Mock, Supertest. Many Javascript applications both client and server functionality, and there is different tooling for both. Webpack is currently popular for building stuff that will run in the browser, whereas server side stuff is different. It's a much newer technology than java and there is quite a lot of churn around tooling in general as the nature of the way applications are built change.

tigershark 10y ago
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?
- l1ambda 10y ago
  In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape 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/ 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.
  - tigershark 10y ago
    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.
    - shados 10y ago
      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.
  - pcsanwald 10y ago
    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.
- rickhanlonii 10y ago
  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.
  - tigershark 10y ago
    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.
    - rickhanlonii 10y ago
      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.
  - imtringued 10y ago
    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.
crucialfelix 10y ago
> 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.

tigershark 10y ago

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?

l1ambda 10y ago
In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape 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/ 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.
- tigershark 10y ago
  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.
  - shados 10y ago
    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.
- pcsanwald 10y ago
  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.
rickhanlonii 10y ago
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.
- tigershark 10y ago
  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.
  - rickhanlonii 10y ago
    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.
- imtringued 10y ago
  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.

crucialfelix 10y ago

> 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.