
Where is the platform? - johns
http://www.mikealrogers.com/posts/where-is-the-platform.html
======
hbrundage
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.

~~~
9oliYQjP
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...

<http://railsforum.com/viewtopic.php?id=47404>

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.

