Sweet baby rollerblading Jesus this misinformation is appalling.

> In Rails you would initialize all of your application when Rails is initialized. You cannot depend on a Ruby or Python process being up for longer than an HTTP request/response cycle so you use your preferred web framework’s init hooks to guide you.

This is a flagrant disregard for fact. You can in fact depend on the process for more than one response and to suggest otherwise is absurd. Rails asks you to put your initialization logic in an `initializer` because it is a useful abstraction: other people will know where to find it, you can guarantee the execution order in the presence of change, but nothing is stopping Rails developers from sticking their database connection creation in the `config.ru` file which boots their app.

> Frameworks like Rails and Django have stepped up and addressed all the needs of an application, including state initialization, because they needed to.

Once more you are incorrect. These two frameworks chose to abstract application initialization, unlike other libraries in your strawman languages like Sinatra or Goliath, or Bottle, or Flask. Let's not posit these grand assumptions without considering the whole landscape, Mikeal. They didn't do this because they were forced to by the process model: they chose to provide a useful abstraction which, if usage is a metric of usefulness, seems to have been a wise choice.

> A web framework in node.js can, and should, do far less. It’s a much easier task than Ruby/Python because the process model will never be dictated by HTTP requests.

If this is truely the case then why hasn't a node.js framework reached the staggering adoption of the frameworks you slander? I argue because it is distinctly more difficult to create as productive a platform as Rails in node because it is that much more hostile a platform than ruby. The fact of the matter is working with an error and a value from a callback is harder than working with a try/catch and a return value for a brain. You cannot get around that until you raise your children without the knowledge of return values. Web frameworks in node "can and should" do less than their Ruby/Python counter parts because it is harder for us as humans to program around the paradigm it enforces. It certainly isn't impossible, but when community members scream about adhering to the node.js aesthetic to stifle innovations like Fibers and Deferreds, it grows to be more difficult.

You must also accept that Rails in particular isn't designed to be performant over all else. Rails makes me happy because it does what I expect, and node makes me cry because I'm back to managing race conditions in my head. My teammates and I all know where I might find the instantiation of the Redis connection in Rails, but I challenge you to tell me where the authentication database is instantiated in Dreadnot https://github.com/racker/dreadnot, which is a nodejs asthetic "compliant" express app. For that matter my teammates and I know where I might find the schema for the database, or the command line tasks, or the data to populate the test database with. Whats that you say? Express doesn't do any of those things because it doesn't need to? Right.

I support your claim that an asynchronous paradigm makes it easier to tie together data from other explicitly event based data spouts like those you mentioned, but in any language you pay the complexity cost. The way we've come with to mitigate this is through middleware stacks! Again, a useful abstraction that my teammates and I can use to confer about where to find various stages of the process. Don't ditch these ideas because they are present in whatever language you hate.

> don’t box yourself in from the rest of the value being created in the node community.

How else am I to integrate that value other than through a middleware stack? More event listeners? Oh, can't do control flow like you could in middleware. Dependency injection? Good thing its easy to inherit interfaces or override function definitions in JavaScript. Hey I know, lets put them in an asynchronous stack and make them conform to a simple API? Thats better than this middleware garbage.