cowboyrushforth.com

on node.js, trendy technology, and the development community

• Posted: 11 months ago
• Tags:node.js
• 0 comments

Ok, so I have dived into node.js, as seen on my recent entry on building a realtime, web based, minesweeper clone. I dove into this mostly to just see what all the fuss is about, but I would be lying if I said I was not pleasantly surprised.

This seems to be a topic that one must tread lightly about as node is getting quite a bit of flack as well as quite a few praises and success stories. Seems like a love/hate relationship with no counselor! Why the great divide?

My goal in writing this is to just outline both sides of the story and hopefully give a fairly neutral opinion on the matter but shining some light on all angles. So here goes: (continued after break)

1. Development Community:
There is a divide here as there is with almost all new technologies that pick up momentum. Whether its perl, php, ruby, or node.js, there is always 2 sides to the coin. You wind up with the early adopters saying that its the best technology ever created, and these people become evangelists and specialists, swearing by it and throwing it into production as soon as possible.

Then you have the other side of the community, who is extremely hesitant, can find a way to solve the problem in another language or technology, and basically speak negatively of all of the momentum and try to find holes in the young and immature new and shiny technology.

Sigh how come few people seem to be in the middle of the road? Personally I feel like node is a great step forward, but is not the end-all-be-all in the development world, nor is any other language or technology. There is nothing wrong with enthusiasm, and there is nothing wrong with using another tool for the job, but ultimately, that is what it comes down to. Is node.js the right tool for the job sometimes? The answer can be yes if approached carefully. The right answer can also be no. To make this decision one must properly research what the right tool is for the job, given their project's goals, and remove emotion from the equation.

2. What Node Does Well
While node is not awesome in all areas, lets review what its good at:

• a.) building non-blocking network applications
  By nature of Node's design, it is unnatural to block an application in node. You end up with a lot of callbacks as a side effect of this, but takes a ton of complexity away from the developer, therefore you end up with less code, which is usually a good thing. Just because the developer is able to skip some of the complexity, this should not reflect poorly on the developer.
  
  
• b.) its fast and lightweight
  Node has a great foundation this department. It runs on google's v8 javascript engine, which is basically a VM built from the ground up without any legacy cruft and a small memory footprint. This is the same javascript engine embedded in the Chrome web browser. A lot of work has gone into this, and therefore its exceptionally fast.
  
  
• c.) momentum
  I feel that momentum is heavily underrated by many in the development community at large. Often a new technology comes out, and often it needs a lot of polishing. Some developers as said above will squawk at this and not use it, but as more and more people hop on the bandwagon, more and more code becomes vetted, more and more eyes see it, and before you know it, the technology has matured, and the industry moves on. Node has so much momentum right now that the bad parts are going to become good, and this is happening rapidly.
  
  There is a healthy amount of libraries already available, so most used network technologies already have a module available to work with.
  
  
• c.) javascript isn't so bad for this job
  Some people simply reject node because of the fact that its javascript. This is completely absurd. Some of the reasons given is that the barrier to entry has been set to low, since everyone knows javascript. This too, is completely absurd. Especially if you realize that sharing code between the client and the server really doesn't add up. (see point below)
  
  Just because the possibility exists to write server-side javascript, doesn't mean that every web developer that knows javascript is going to start writing high performance messaging components in node. It may intrigue some of these people to actually start learning how server applications and components are built, but there is still a learning curve. People happily using node, are not using it just because its javascript.
  
  Javascript is a neat language with a c or php like bracket like syntax. Sure it might not be the most beautiful language out there, but with regards to building event based systems, it seems to lend itself well to this task. Yes, there is multiple ways to extend an object, and some of the OO stuff in it is simplistic, but considering that node applications are intended to be small and lightweight server based network applications, not having all of this baggage is not a bad thing, and with the adoption of things like CommonJS, the ecosystem and established patterns are improving.
  
  

• a.) security is immature
  Being so new, there is more possibility of attack vectors. This is also changing rapidly, but is a real concern. Nodester in the beta phase of its node.js hosting solution had their entire database compromised. Who's to say if they built it in .net, java, php or ruby the same thing wouldnt have happened, because it surely could have, but the fact is node is young. Production deployments almost always involve a chroot at this stage. Extra precaution needs to be taken when using 3rd party libraries and things of this nature.
  
  
• b.) no threading
  Node is run in a single thread with one big event loop. This in practice works well for building network applications that need to respond rapidly to many clients and/or have many clients waiting for data. It really doesn't work too well for applications that need to do heavy processing. Node is going to address this with the web workers api which behind the scenes will be something like threading, but really is not the point of node, and for most people won't buy them much. People that have multiple cores on their boxes can simply run multiple processes. If your app is not designed to run many versions of it self and cooperate between different processes, then you haven't even thought about scalability yet. Having many single processes spread out over many servers is going to be much easier to scale horizontally than many multithreaded applications spread out over many servers.
  
  Personally, I feel that node is just not the right tool for the job if you need to do heavy processing. It simply doesn't lend itself to this, and there is limitations on its memory footprint and things of this nature. This doesn't mean that you couldn't offload heavy processing to another component in the application stack, and still use node for what its good for, this is probably going to be a pretty common trend going forward. Someday node may be a better tool for this, but ultimately, exploit node for what its good at. Threading is not one of them.
  
  
• b.) client/server code sharing
  There has been a fair amount of hype specifically related to sharing code between a web browser, and its node.js backed server. I feel like this is hype for a few reasons, but ultimately it all comes down to why? Why would you ever want to have your backend code be the same as the front-end code. I understand and practice the concept of being DRY (don't repeat yourself) but I don't see any use case to re-use code in both places, not to mention the inherent security risks that when addressed, would mean that your code diverges and is now different because you had to add security measures to the backend code.
  
  At the end of the day, I think the idea of sharing a model or something is novel, but in practice sort of silly. If you want to have a dynamic application that does fancy things there is nothing stopping you from building that and having all the client code be client code and the server code be server code.
  
  There is surely a level of simplicity and coolness that you can use the same language in your backend code as client code, and that one doesn't have to do as big of a mental context switch, but I wouldn't list this as a feature of node, and wouldn't be upset about not being able to share code, as it doesn't make sense for any use case I have heard of yet.
  
  

Comments: