Saturday, June 16, 2012

Node.js

Teague at #austincodecamp on Twitpic

I saw John Teague speak on Node.js at Code Camp one week ago today and came away concluding that I do not want to try to learn Node.js. At this point in time it just seems like it is too much of a mountain to climb. Nonetheless, thank you to John Teague for giving a great talk! Here is the bird's eye view which will show off why this is hard stuff in an unrefined infancy:

  • Elevator Speech: Node.js offers server side JavaScript. What makes Node a little different is that it uses events instead of threads. Node starts one event loop and waits for events to be triggered. I/O (file input/output) costs are heavy and if you build an application (not of Node) on a single thread it can run slow and keep the user waiting when struggling through I/O morasses. Using an event-driven, server-side architecture can alleviate this pain and this is the whole reason to use Node.js as JavaScript is very good at "eventing." If there is another way to go, I don't know what it is. The subtext of John's talk was that you should use Node to solve this problem and that it was THE way to go. Node's non-blocking I/O model sets it apart.
  • Still Listening? ASP.NET and Java are NOT asynchronous. They fake asynchronous behavior through threading calls which are abstracted away. There can be starvation situations in which one thread dies while waiting for a resource which can lead to pain. Use event callbacks in Node to make the magic happen, i.e. play to JavaScript's strengths. Instead of worrying about whether or not customers can find what they are looking for in your store, just be ready for them to come up to the register. Sound harsh? Think about how much time you might spend in vain otherwise, for example:
  • Even versions of Node are stable. Odd versions are development versions. PM is the Node package manager. Think: NuGet
  • What's not to like? Node does not run on IIS on Windows 7. It has its own web server. I could not understand how "it" is set up or found via Port 80 or how one gets an A record to resolve to it. Also, by "it," I mean something that YOU write yourself in a few lines of code. Express and Railway (MVCesque) which is built on top Express are third-party tools for empowering routing that the "it" you write yourself will not have standalone. Derby is another routing framework yet. Headspring's Steve Donie was in the audience at the talk and piped up about how many random things one had to learn tangentially in name of spinning up a Node project and how, moreover, the grocery list was nebulous given that one could use Express or could use Railway or could use Derby. The Express/Railway/Derby decision dilemma is just of routing. There are other decisions like this to make for other frameworks for other fill-in-the-gaps work to do in the name of getting Node.js to cough up "Hello World" in a web browser, but once I realized that I stopped scribbling down notes on Node.js. :( I'll check back on Node in... two years.

3 comments:

  1. It's really not as bad as you think ;) but it is a very new technology and there are some rough spots still. There are some good boilerplate projects on github that can get you started quickly. I'll do a blog post listing some.

    Just a few corrections. You can run Node on Windows 7. I use Win7 as my windows dev machine and created several apps on that OS. You do not need IIS to run Node. There is a project called IISNode that will use IIS to host your node applications, restart them if they crash and direct http traffic to them.

    If you want to run on port 80, then make sure nothing else is running on that port. As for pointing your dns to the executable, I'm not sure either. I have not done that yet.

    ReplyDelete
  2. I did some file IO work in Node today and it was awesome and easy. You were right. It is not as bad as I thought. I don't know that I want to run an actually web site in Node, but it seems neat for CI stuff.

    ReplyDelete