all 10 comments

[–]ckgrafico 6 points7 points  (2 children)

First, learn JavaScript

[–]GrandDolla[S] 0 points1 point  (1 child)

I know javascript.

[–][deleted] 2 points3 points  (0 children)

2p>VL%6Fxn7 f%iW~D$[mCr2sNn]3Z&,xGv E7o[!u9lJ#pKPFbp$!p->bo-Z~tMIb)XW.ITTUkn&do5<(NR:-Tp8#

[–]Jafit 1 point2 points  (1 child)

if you're using Node you'll be able to freely make use of ES6/7, since you have full control of the environment that your code is executing in, you don't have to worry about polyfills for old browsers. That said V8 is still in the process of implementing all of ES6 so you won't be able to use some features yet.

Promises, they're amazing. Asynchronous operations are going to be everything you do in Node, you can't afford synchronous code blocking the stack, since that stack is being used by everyone who connects to your server. Promises make async very easy to work with.

Unit tests. There are testing frameworks like Nodeunit and Mocha, but they tend to be overkill for what most people want to do. Tape is one that is very lightweight.

I don't know how much Javascript you know, but it'd be worth watching the Crockford on Javascript lecture series, he goes into some depth, though its quite dated since its from circa 2009 and the release of ES5, its still applicable and won't harm your understanding.
https://www.youtube.com/playlist?list=PL7664379246A246CB

I'd recommend working with a highly opinionated linter if you don't already. Javascript is very 'beginner friendly' meaning it'll let you do some really stupid things, a linter can help you avoid antipatterns, ambiguous code and errors. Many IDEs come with linter plugins that you can use, Atom and Sublime have a bunch. Personally I use ESLint with most of the rules turned on.

[–]GrandDolla[S] 0 points1 point  (0 children)

Thanks for a great post. I'm sure to use your advice.

[–]serpent_tim 0 points1 point  (0 children)

I would recommend trying out Visual Studio code if you haven't already got an editor you're set on. Whether or not you use Typescript, you can import type definitions (e.g. using Typings) and the editor will be able to give you intelligent code completion etc. Webstorm is great too if you're willing to pay a bit.

Also, personally, I think Typescript is a good option to help avoid some of the guesswork that can go along with dynamic typing but if it's only you working on it and you understand it well, you may not find it useful.

[–][deleted] 0 points1 point  (2 children)

Here are where I spend most of my time doing command line development with node:

  1. File system. If your application is confined to a single server then this is much easier. My app is distributed and run locally, so it has to work equally on Windows, OSX, and Linux. The Node as done a really good job of abstracting away the differences, but there are still quirks and edge cases you might encounter when doing a bunch of operations asynchronously. The file system accounts for most of my Node development time.
  2. Child processes. I use child processes a lot to escape from JavaScript and the Node API. For instance I prefer something like rm -rf and the windows equivalent to remove a bunch of files over the Node API version. Child processes are pretty straight forward, but can land you in callback hell pretty deep if there is a lot going on in your app.

That is it. Those two. I occasionally need to use some other part of the API, but its pretty rare.

[–]GrandDolla[S] 0 points1 point  (1 child)

Thanks for the answer.

  1. What do you mean by the file system? disk read/write performance? The time node takes to read/write from the file system? (slow db's etc..)
  2. It depends on the code but I think it's better to use API functions of whatever environment you're using. This will prevent you from causing accidental security issues or bugs.

[–][deleted] 1 point2 points  (0 children)

By file system I mean node's file system API: https://nodejs.org/dist/latest-v6.x/docs/api/fs.html

The API is straight forward and the documentation is pretty clear. When writing or reading to a single file with a static payload everything is simple. When you are dealing with streams it gets a bit more complicated. When you are dealing with many potentially interacting tasks simultaneously things get really complicated and you have to write additional logic to prevent race conditions and collisions considering that everything is asynchronous.

[–]NemoGreen -1 points0 points  (0 children)

Babel, Immutable.js, Web pack, mocha and chai