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.
I don't think that his remarks about Rails and Django should antagonize you. What motivated me to explore node.js is precisely the fact that I started to spend more and more of my time outside of Rails trying to push the envelope. Things like Cappucino from 280north showed that more and more of a web app was happening on the client and the server was being relegated to a fancy HTTP wrapper for a database.
His remarks about what node.js does well could be applied to just about any thin HTTP wrapper for Ruby, python and any other language. Rails and Django are still very productive if you're making dynamic websites. For web apps however, simply from a latency perspective it makes sense to push more stuff down to the client. At that level, you're looking at JavaScript frameworks of some sort being a far superior solution to the kind of thing that happens in Rails like this...
That's not to say Rails or Django suck, but web apps have been pushed to the next level. Rails was developed back when web apps meant more of a dumb terminal style system, with the server driving the display of the clients. Today web apps are more like 1990s style networked PCs where a fat client communicates with a server but the UX is driven client side.
There is no reason you can't write ruby or even Rails code that does this. But you'll have a ton of JavaScript (or Coffeescript or fill in the blank with something that compiles down to JS). Most frameworks treat this stuff as secondary to writing server side views and controllers, because it used to be, back when AJAX just meant dynamically update my drop down list.
EDIT: I forgot to add that Express makes the mistake of trying to apply Rails/Django/Sinatra style to node.js. Don't use node.js this way, it won't work well as just using the aforementioned frameworks.
> 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.