This is originally an email that I wrote to a developer friend of mind, in response for his request for my experiences and advice regarding working with Node for a few months.
I wrote it at a time that I should have been sleeping, but I couldn't, because I was too excited/nervous for my upcoming A1 driving test.
I'm a software developer with 10 years of experience of shipping stuff in Java, Python, C++, Objective-C and now Node.
After 6 months of working for a client with Node I can say I'm pretty decent with Node, and "Oh, I think I'm starting to get it" in React. I would not choose Node for long term projects of more than 1 person, unless it's a POC/demo. Why? Because even with the best setup with Node (which takes a while to create) is still far inferior to the productivity you get with Java + IntelliJ. And I suspect that Kotlin + IntelliJ is even better <- so this would be my recommendation for a server side language. It's not just the language, is the whole experience. It's the tools, the ecosystem and the other developers on your team. There's a chance that if I had been using a type system with Node like Flow or TypeScript, my opinion would change, but probably not drastically.
- Debugging sucks. I managed to make it work with VSCode, but sometimes I just resort to console.log, like many other node developers (you know I'm right).
- No static types = waste of time, more bugs, intellisense/autocomplete sucks or nonexistent.
- Testing sucks: JUnit5+AssertJ+Mockito are far superior than anything that JS offers. Good luck figuring out why your tests fail. I believe this is mostly a result of the previous point.
- The ecosystem is a mess. Too many frameworks, too many libraries, toolchains, just too many options. And the ones that do exist are usually lacking. Lots of opinionated developers who built unopinionated libraries. For example, there is no all-in-one user system with authentication library/framework in JS. The closest I found is with Meteor, which is an opinionated framework. I had to implement my own reset password flow (and you will too).
- Another side effect of the previous point: less chance of your setup being common -> less chance of finding solutions in SO. Give me boring, working, complete libraries, so I can focus on the interesting stuff. The client doesn't care about your toolchain or whether you use Atom or VSCode.
- Unresolved promise rejections. It's kind of like an exception inside a thread, that just gets lost. I found a way to deal with this eventually, but it's still not fun.
- Async IO by default = web scale? Possibly, but until you reach a point when it matters, you suffer. Blocking IO might be wasteful but it's damn easy and predictable. When it's finally slowing you down - congratulations! You have a real, interesting problem. Talk with your teammates, understand the culprit, maybe use a library. Now you will complicate your solution because it had to be done.
- Also, because of the async nature of node, you can't do stuff like attaching a request/user id to logs down in the call chain. There is no easy way to store a global context. That was a long way of saying that logging kinda sucks too.
- Fast feedback loop. Hot reload. That's awesome.
- Shorter syntax, deconstructing, etc.
- Functions as 1st class citizens, and no need for classes (both of these are true for Kotlin).
- Can use cool functional programming libs like Ramda
- Looks good in a Resume
I really don't remember, I probably tried a few tutorials on YouTube and egghead.io. Egghead are pretty good. The official docs are important to read as a lot of content can be outdated (usually in some minor details). Node is very simple, once you figure out callbacks, then forget about them because there are Promises + async/await. For simple stuff ("I need to wait for this IO call, then do something") - async/await. For more complicated stuff like parallelism/coordination - Promises. Bluebird.js is a popular promise implementation and even if you are using native Promises, its docs are still relevant because they match the native API.
In my project I didn't use a type system, but I think I'd choose TypeScript because of better tool support (plays well with VSCode I read).
React is fun. Composition is fun. Unidirectional data flow is awesome. I learned React from egghead, because it's free, and it's pretty good. Just start writing code. It will start to make sense. Later, I discovered that the official docs are pretty good and are a MUST read IMO, especially because React is changing so fast, thus making lot of resources outdated.
If you ask yourself - wtf is state management? They don't bother with this yet. Play around with React first, and later learn this too. Two very important article in this regard:
- https://www.robinwieruch.de/redux-mobx-confusion/
- https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 I learned Redux from egghead.io. There's a good video series by Dan Abramov, the guy who created Redux.
Editors - The most popular editor is probably VSCode. WebStorm/IntelliJ is actually smarter but feels a bit slower. Maybe try both. Atom is very popular too. I use VSCode. Project structure - doesn't matter that much really. The default is thing-type based, as in "routes/services/libs/components/etc". I actually decided to choose a feature-based project structure. I feel it makes the most sense. So I have high level folders for each feature. Again, not very important. Start with something, change later. Build tools - I really don't understand much in that, except for the beginning when I worked with Babel. Later I was convinced that I don't really need Babel, because the latest Node supports almost everything I need (except I need to use require instead of import, but that's minor (and has advantages too)). So right now in the server there is no build toolchain at all. It's just "node app.js" In the client, just use create-react-app. It hides all the complexity of webpack/etc. Linters - prettier + eslint with airbnb.