Connect is a misguided effort IMHO, but as the creator of JSGI/Jack (http://jackjs.org/) I'm of course biased.
JSGI is a lot more elegant. It's more of a functional style (apps are just functions, middleware are functions that return another app, a function), asynchronous support is handled via promises. Connect is very much tied to the Node stream APIs, and ends up being more convoluted and difficult to understand, IMO.
I like how it abstracts a server down to just a chain of modules that can be either a response provider or filter. This reminds me of the architecture of Nginx.
If someone could create a FastCGI implementation as a provider, this would be awesome. Then certain routes could be passed off to Ruby, PHP, Mono, (whatever) and simple things like static files, pub-sub, cache, etc can be handled by node.
I definitely like where they're going with the project and with the ExtJS team behind it, it should be a success.
4 comments
[ 3.0 ms ] story [ 24.8 ms ] threadJSGI is a lot more elegant. It's more of a functional style (apps are just functions, middleware are functions that return another app, a function), asynchronous support is handled via promises. Connect is very much tied to the Node stream APIs, and ends up being more convoluted and difficult to understand, IMO.
Here's an analysis of Connect vs. JSGI by Kris Zyp: http://www.sitepen.com/blog/2010/06/11/jsgi-vs-connect-for-n...
If someone could create a FastCGI implementation as a provider, this would be awesome. Then certain routes could be passed off to Ruby, PHP, Mono, (whatever) and simple things like static files, pub-sub, cache, etc can be handled by node.
I definitely like where they're going with the project and with the ExtJS team behind it, it should be a success.