elarson’s posterous

Kevnin Dangoor mentioned Jack, a Rack implementation in Javascript. While I'm a fan of Rack, I don't get Jack. Why you ask? Well, I'll tell you!

The reason Rack works as it does is because Ruby doesn't support functions as first class citizens. Yes, I realize that many Rubyist fancy their language as an entry to functional programming (I'm assuming b/c of blocks), but Ruby is far from functional. Python, on the other hand, while also far from functional, does allow passing functions as arguments. The WSGI specification, where Rack draws its inspiration, in fact works via passing callables (a duck type for functions) along with an environment. This is very similar to XSLT in how the "." represents the current context, the environment represents the current state of the request. Secondly, WSGI allows two places to adjust the request response. Again, this is very functional. You either adjust the input (the environment) or the output. Basically, through passing functions, you nest them together using the WSGI spec and when the last one calls the start_response function, the output bubbles back through the function hierarchy.

Based on how WSGI works then, it makes no sense whatsoever to implement a WSGI copy in a similar fashion to Rack. Javascript already supports the necessary tools to make a rather pure WSGI implementation (lets call it JSGI) using the same patterns. One distinction the Jack docs make is that Jack is meant for server side Javascript. Again, I don't think this is a problem whatsoever.

I don't want to suggest that Jack is a bad idea, but it seems like basing it on Rack lacks foresight into the actual use of the design. WSGI has proven itself in a very powerful way. There are a multitude of applications, libraries and middleware that all make it clear WSGI is successful technology. Rack on the other hand does not have the same track record. Including Rack in Rails 3 doesn't really count either as Rails 3 is not released and there are no examples of sites or services using it. It also seems like a shame that the functional features of Javascript are not being utilized. The sucess of jQuery, I believe, is largely a function of its functional approach and respect for the language. It seems that a similar functional approach should be taken implementing something like WSGI in Javascript.

Ok, that title is terrible... But as Sam mentioned, Rails has adopted Rack! I've managed to avoid Ruby in favor of a superior language (which I type with my tongue firmly in my cheek), but when I did use Ruby and Rails, Rack was of definite interest. Of course, my understanding of Rack came from direct exposure to WSGI. The big difference between the two is that Rack is effectively an API at the object level, whereas WSGI is really at the langauage level. This distinction is primarily because Python has functions as first class objects, which allows passing callables around. This should be familiar to anyone using Javascript who has passed a function to an event handler or ajax call. The WSGI pattern is effectively the same. Since I haven't used Rack outside of basic experiements, I don't know how the idea of middleware translates. My guess is that it could be somewhat optimized in a similar fashion that tools are optimized in CherryPy.

Wild and inaccurate assumptions aside, WSGI has been a huge factor in the growth and development of the Python web development landscape. I can only imagine that it might help promote similar evolution within the Ruby community.