2010/10/19

Node.js and Express after Django

Recently i have been playing with expressjs, javascript framework on top of node.js. After working with Django for over a year this seems to be perfect choice, as similarity between those two is, on the first look, striking. If you are familiar with Django you may feel like at home. One that is still under construction, full of workers wondering if there should be 3 or 4 windows, leaking in the rain and with no furniture at all, but home.

I want to share about few things that make Express looking like a younger, underdeveloped brother of Django:

First is documentation. Express start page presents hello world example, which you can just paste and run, but after that things get dirty. There is no comprehensive documentation like in Django, which will take your hand and guide you trough all aspects of designing and maintaining web application. The fact that Express is currently still a set of different projects combined together can easily be seen. Unlike in Django each component is documented separately (and often poorly). One documentation page for Express, another for Connect (connect is a set of common web building blocks like session handling or form parsing). If you want to use classes, you can select one of dozens js libraries for that (it is really hard to get that there are no classes in js language definition for a python developer). Examples are scarce, scattered around various blog posts and i spent a lot of time trying to figure out how to combine them together.
Definitely express needs a book, or at least a single wiki page.

Second - it is much more low-level. Things that in Django are just working or require only that you learn how to use them, here must be explicitly included, turned on and configured to work.
You want cookies? add cookie middleware. Forms? Same thing. Sessions? Database access? Find right middleware/library and learn how to bind it together. There is really nothing hard in it, as express is simple to use, just requires more effort then it really should. On the plus side there is really no magick at all in express.

Third - installation. Comparing to django (aptitude install python-django, then copy and paste webserver config bits from documentation and thats all) instaling express will take much more time. Grab node.js source, compile and install. Then install npm. Then install modules (and find out which ones you need, it wasn't obvious for me that i need to install ejs separately).


There is also few other oddities. One is that you need separate method for handling GET and POST methods under the same url. Other is that with significant amount of middlewares that must be set up express does not support any form of decorator pattern (this could be easily fixed by adding list of middlewares with options to app.get method params) Also express does not have applications (views, urls and templates packed together that you can easily add it to your project), and proper handling of errors in async code is sometimes hard to achieve (but this is problem with immature libraries, express itself does it rather well so far).

Overall however working with this framework was not that bad. It does its job and allows me to combine classic web application with realtime streaming. Quick test showed that on my netbook i can have several clients exchanging stream of 1000 messages per second, with minimal load and constant memory usage during the test. I have to yet combine express and socket.io session support and make more benchmarks on better hardware, but express is already usefull. None of the things i mentioned is hard to fix i am sure they will improve soon. With a number of js libraries and async design everywhere node is right now a better choice then tornado or twisted. Once it will be packaged and documented it can easily take over significant part of Django userbase. There is a chance that growing usage of js on the server side will bring much needed development to this language.

2 comments:

  1. How did you combine express and socket.io session support?

    ReplyDelete
  2. Having separate methods for POST and GET http verbs is thought out decision that allows to implement REST applications easy. Actually this is one of the things that I don't fancy in Django :P

    ReplyDelete