$ npm install -g mocha

$ mocha -w -R min

The -w option means watch (look in the directory and whenever a file change, rerun the tests) and the -R min means use the 'minimal' reporter. Below is an example of what the output may look like

If I change a file, I'll immediately know if I broke something.

If you're used to work in Java, your parser (assuming you used an IDE) would most likely have picked up your trivial errors immediately. In JavaScript, your parser will not be able to pick up as many errors because of the weak typing. Constantly executing through your code compensates for this.

Study not only experiment

If I pick up some library online in Java, my typical work pattern is as follows:

1. I'll download the library (say by adding it to some maven pom file)
2. I take a look at the documentation (typically read through the Quick Start to get an idea of how I'd like to use the library
3. I explore the library by looking at the API
4. I start programming. In most cases, I'll be OK as the autocompletion available in my IDE will help me get the spelling correct and show me my options.

When you move to Node, you just can't work this way! You have to take the time to study the library. You may of course experiment as well, but I suggest you do this in a sandbox far away from your production code. Only when you have built up some degree of proficiency can you start using the library.

I kept making this mistake in the beginning. I was following my usual routine, however, without autocompletion and the ability to command-click into the source (or ctr-click on windows), you'll be wasting your time.

Here is my new routine:

1. Set aside some reasonable amount of time.
   I typically set aside 1-4 hours to learn a new library.
2. Make sure you picked a library that is wide-spread.
   I can't tell you how many times I found a JS/Node library that looked promising in its description. Started to use it then to discover that it has serious flaws and that there is a single contributor and had to back out. Spend some time researching how many others are using it, what are the alternatives, etc. The JS library market is in its infancy. There seems to be more libraries than there are programmers. I fully expect this chaos to subside (I don't know if you where around when we had the same problem in Java, but it quickly resolved itself through a darwinistic process).
3. Skim through the documentation from A to Z.
   You don't have to read every word, but build a picture of what ALL the features can do for you and ensure that it is a good match for your problem. Developers aren't always the best writers and reading through the documentation can be painful, but if you focus on skimming it's not too bad. I usually follow this up with a quick mind map (there are plenty of mind-mapping tools out there if you don't like pen and paper). This often exposes gaps in my understanding and I have to go back and reread some section.
4. Create a sandbox project and start with their tutorial.
   Most library have some kind of quick-start, or perhaps a sample application that you can run. I usually also go to GitHub and see if I can find some projects using the library.
5. Create a throwaway application solving what you want to solve with the library.
   Create another sandbox project and make a simplified implementation of what you're trying to solve (the reason you wanted to use the library in the first place)
6. Produce some documentation/notes explaining the library in your context.
   Finally, I usually write up a summary of the key features and the API's of the library (showing age here… I do this so I can remember).

Often I bail from the library in step 2 saving myself a lot of time.

Understand and accept the node philosophy

I often hear developers complain about various programming paradigms. Sometimes, this is because they haven't bought into (or simply not gotten used to) the style or philosophy of a new environment.
When moving from Java to Node, there are a few things that you have to learn to accept. In particular, node seem to shy away from transitional object-oriented frameworks (the kinds that are built on the Hollywood principle: "Don't call us, we'll call you").

As an example, in Java if you built web applications, you would know where to find the source code,, where to place your files, how to configure filters, etc. JEE defines this, your web server implementation will follow the rules of the JEE specification and you as a programmer would simply 'plug in code where specified'.

Not so in Node, in Node you have the ultimate freedom (freedom coming with a tremendous amount of responsibility). There are no Tomcat, no JBoss etc. You're on your own. In fact, I hear people compare Node to JEE (or Play, Django, PHP, …) which is actually a bad comparison. Node is just a Java Script interpreter. Node doesn't understand the web. To get Node to do something with parity to the frameworks it is being compared to, you'll have to add libraries. Your program will have to configure these libraries and now you have parity (or perhaps more than parity).

So if you want to compare Java artifacts to Node artifacts, it'll look more like this:

• Java --> JavaScript
• JVM --> Node
• JEE Web Server --> Tons of libraries, perhaps the most popular being Express.js, but there are many alternatives

The node approach has advantages and disadvantages. In the beginning, I found the lack of consistency between various applications (developers are free to configure their file structure as they please) to be a mistake. I was trying to learn by looking at various projects using some of the most popular libraries, however, it seemed every developer had their own idea of how to organize their code making it very difficult to learn.

However, later, I had some unique requirements where I had to combine technologies that would have been really hard to do in Java. In Node, this was easy because I have full control.

You may not like this philosophy, but if you want to be efficient in Node, you'll have to understand it and accept it.

Conclusion

The transition from Java to Node (or more generically from strongly typed/standard rich environment to a loosely typed/few standard) can be frustrating. If you are to be successful in this transition, you'll may have to change the way you work. I recommend using TDD, to spend more time study the various libraries you encounter and embrace the philosophy.

I started out being very uncomfortable and inefficient when building Node applications. By changing my routine, I think I've managed parity in terms of productivity of that I experience in more rigid environments (e.g. Java)..