
Visual Basic, PHP, Rails. Is Node.js next? - dwynings
http://andrewchenblog.com/2012/04/01/visual-basic-php-rails-is-node-js-next/
======
olalonde
IMHO, Node.js will not directly compete with Rails/PHP as long as it forces
programmers to program in an async style. As an example, async style makes it
impossible to implement lazy loading (a technique commonly used by ORMs).
Furthermore, Node.js is basically based on the idea of cooperative
multitasking[0] which carries a certain trust issue in large teams or projects
with lots of third party dependencies.

There is definitely a niche for Node.js but it's not likely to become a direct
competitor to Rails.

FWIW, I'm currently writing a web app with Node.js and have written multiple
Node.js modules and native extensions.[1]

[0]
[http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati...](http://en.wikipedia.org/wiki/Computer_multitasking#Cooperative_multitasking.2Ftime-
sharing)

[1] [http://syskall.com/how-to-write-your-own-native-nodejs-
exten...](http://syskall.com/how-to-write-your-own-native-nodejs-extension)

~~~
wahnfrieden
Why does it make lazy loading impossible?

~~~
olalonde
A typical ORM allows you to do stuff like this:

    
    
        var user = orm.load('User', 'some unique id...');
        console.log(user.name + ' was referred by ' + user.referrer.name);
    

where user.referrer is another User instance. Since the user.referrer object
might be a bit slow to load from the DB, we want to delay its loading until we
actually use it (lazy load it) and not load it at all if we don't use it. This
is not possible in Node.js because every I/O calls (i.e. database calls) are
async. In other words, we have no guarantee user.referrer will be loaded in
time (before console.log() outputs the result).

Every time we want to load something from the DB, we need to supply an
explicit callback which will be called one the DB query is completed.

Of course, there are several ways to achieve the same result in async style,
but none of them are _transparent_ to the programmer. You will either have to
load the referrer object upfront or supply a callback whenever you need to
load it.

For example:

    
    
        orm.load('User', 'some unique id...', function(user) {
            user.referrer.onLoad(function() {
                console.log(user.name + ' was referred by ' + user.referrer.name);
            });
        });

~~~
wahnfrieden
Ah yea - so it's not impossible, it just makes typical usage overly
cumbersome. Maybe this is something a coffeescript extension or analog could
help solve.

~~~
olalonde
Well, it is impossible to _transparently_ lazy load from a database.
CoffeeScript won't solve the problem since it is still ultimately limited by
Node.js' async libraries.

A "solution" would be to cheat and write a _sync_ database API but then, you
would break the assumption that everything is async with Node.js, making it
harder to work with other programmers or use third party modules.

~~~
xtrumanx
> CoffeeScript won't solve the problem since it is still ultimately limited by
> Node.js' async libraries.

I wouldn't be too sure about that. .net 4.5 is coming out with an await and
async keywords which will basically signal to the compiler that method should
be re-written to an asynchronous. So for the example you gave, if the await
keyword was available in coffeescript, you could just write:

    
    
        await console.log(user.referrer.name);
    

And the coffeescript compiler could then re-write callback style.

~~~
roryokane
In fact, IcedCoffeeScript (<http://maxtaco.github.com/coffee-script/>) already
implements this, using keywords called "await" and "defer".

------
AdrianRossouw
I don't think node really wants or needs to be the new VB, PHP or Rails.

Somebody might build something with node that really competes in that space,
but for the most part the node community seems to be route around
'opinionated' frameworks and fall behind very very small libraries. I find it
a breath of fresh air tbh.

There's a constant influx of people who try to turn node/js into what they are
used to (be it java, php or rails), but I don't think they are really gaining
any traction.

Learn to appreciate node for it's strengths, which are actually very difficult
to communicate and really takes a level of understanding far beyond 'oh, i can
build a blog with this'.

------
alexbell
I found the last paragraph/sentence a little weird - "Until then, I think
people will still continue to mostly build in Rails with a large contingent
going to iOS – the latter not due to the superiority of the development
platform, but rather because that’s what is needed to access iOS users."

Rails -> iOS??? Apples and oranges.

~~~
edwinnathaniel
Ditto from VB to the other tech (php, rails). I think he is after something
else; a pattern/trend regardless the platform: desktop, or web , or mobile.

------
throwa
The future is more of a continued polyglot environment. Developers will use
different programming tools/ frameworks to provide different features for
their app via a service-oriented -architecture or something like that. This is
an example: a chat app built with Rails, Socket.IO, Node.js and Backbone.js
<http://node-chatty.herokuapp.com/chatty> See blog post on that:
<http://bit.ly/zorHYA> Everything is in rails but just the chat bit that makes
sense to be realtime is served by nodejs. Redis pubsub is used to communicate
between rails and the nodejs chat server. You can use ruby based event-machine
or async sinatra or async rack to write the chat server and communicate with
them with redis and drop nodejs if you are so inclined..

In summary rails, nodejs, php, java will continue to co-exist as tools and
people will use what they are most comfortable with and what gets the job done
in each problem space.

------
gexla
I think you have your order wrong. If you are talking about web frameworks,
then Rails pretty much kicked off the bloom of web frameworks in the PHP
ecosystem. There were web frameworks available in the PHP ecosystem before
Rails, but they all sucked and none of them had gained any serious traction.

Also, I'm not sure you could ever call VB or Ruby mainstream. Of course, this
depends on your definition, but hosting issues and a lack of things like a
Ruby equivalent of Wordpress (in terms of popularity and usage) has kept PHP
at the top for web development in general.

~~~
digitalzombie
I don't believe your statement. IMO the reason why Rails was popular was
because it was the only real MVC framework for Ruby at the time. PHP have
CakePHP, Zend, CodeIgniter, Symphony, etc... Python Django was before Rail and
it failed to have as much fanbase as Rail because it was also competing with
other within Python ecosystem.

~~~
gexla
CodeIgniter was released after Rails and at that time the developer listed
Rails as being an inspiration. Zend Framework was released after CodeIgniter.
I don't know the history of CakePHP and Symfony but Wikipedia shows they were
each released in 2005, which was before CodeIgniter but after Rails. That's
why I mentioned that Rails was an inspiration for a lot of the PHP frameworks
which came out after Rails. Again, there were already PHP web frameworks
available, but nothing really took off until after Rails hit the scene.

------
gfodor
The question is, when will people tire of learning new ways to make HTML web
pages that save to a database. I know I sure have.

~~~
kylebrown
Whenever other people stop needing web pages that save to a database. Until
then, we'll continue learning better (as in quicker and easier rather than
"new") ways to lazily create what people need.

~~~
ryan-allen
I'd argue in a lot of cases the new methods are not significantly better, just
significantly different.

I cynically believe that this is what happens when you ask a reasonably
intelligent programmer to connect forms to databases. They will get bored and
invent alternate techniques and want to use 'new' tools to pretty much achieve
the same thing.

I'm guilty of doing this myself, but I now see the pattern and I'm over it.
There is more interesting things to learn than the 'next hot thing' in web
tech and there's also something to be said about maintainability.

I've had to troubleshoot bugs in years old Rails applications on Ruby 1.8.7 in
Rails 2.1 that were jam packed full of the current trendy plugins of the time.
I'm telling you I'd prefer debugging and maintaining a boring old PHP app with
hand-rolled SQL statements over it any day. To be fair these apps are still
around because they generate income, but they don't generate enough income to
justify a 3-6 month long error-prone 'upgrade' project to get it inline with
the tech of the day.

I think this is why big-co standardise on years old tech, because building
every new thing in every new tech with 1000 programmers is a recipe for
disaster. Yes we need to try new tools, new techniques, but when
overwhelmingly the corporate world have chosen the safe route I suspect it's
not because they're old and boring themselves, just they've seen through the
smoke and mirrors and no longer buy it.

It takes a number of years working in a few environments to see this for
yourself (try telling this to an 18 year old hot-shot and they'll think you're
an old fuddy duddy). I believe there's merit when an old greybeard is yelling
at all the younguns because they left out not null constraints and omitted
foreign keys. They know (and have dealt with) the impact a few years down the
track.

~~~
kylebrown
> _They will get bored and invent alternate techniques and want to use 'new'
> tools to pretty much achieve the same thing._

Yup, and plenty of re-invented alternatives will be no better or worse than
the tried and true. But occasionally the new tech will be significantly
better; that's how tech evolves.

The main advantage I expect to get from experimenting with node.js and NoSQL
is to be able to take the client-side code that's on the web page (eg instant
form validation with javascript, and saving offline to html5 localStorage
because the customer wants it to work where they don't have wifi), and re-use
it on the server (would rather not have a second codebase in php or ruby-rails
to do all the CRUD). With coffeescript I write less boilerplate. And I have to
use the latest jQuery-esque plug-ins because the customer also wants touch-
screen drag-n-drop functionality.

To be sure, there is plenty more interesting things I would rather be
learning. But customers don't really care that I might find something else
more interesting than their project.

------
nchuhoai
Rails made it ridiculously easier to write common CRUD apps. Whoever is the
next fad, a rails comeptitor or rails version, it will find a way to make
real-time apps easier. While I love node, I do not think it has the particular
same appeal as Rails had a couple years ago. As an intermediate Rails
developer, I really hope 4.0 can bring some of the freshness and magic back

~~~
edwinnathaniel
... or make mobile development a lot easier.

------
ilaksh
I agree with what this guy is saying about form-based applications.

What I have just started working on is a system built on Node.js that is
designed to make developing CRUD and other common types of applications
efficient.

Its a little bit along the lines of ASP.NET, but with an aim towards making
things simpler. There are components with a front end in
JavaScript/CoffeeScript and a back end running on Node.js and Mongodb.
CodeMirror to edit the HTML/CSS and Javascript or CoffeeScript for the front
end and also the CoffeeScript/JavaScript of the backend of each component.

Front end components (widgets) are composable. As far as CRUD goes there are a
lot of different types of forms people want and so there isn't going to be a
built-in widget for everything, but to start with, there is a record widget, a
field widget, and a list widget. These widgets would be associated with
certain collections or fields in a database and so there can be multiple list
widgets for example displaying data in different ways.

To start with I am working on the basic component framework and editor with
some type of drag-and-drop composability for the front-end widgets. Still at a
fairly early stage.

------
gouranga
To be honest, where real time collaboration apps and updates are concerned,
we're using WPF and WCF on top of .Net. There's a lot ready to roll there -
much more than any open source framework. It's conveniently the "forms
paradigm" with a nice asynchronous network backend and scary scalability
(AppFabric/Azure really does scale!)

------
plasma
It's worth mentioning the upcoming .Net 5 runtime featuring await/async
operators to dramatically simplify async programming, read more at
[http://blogs.msdn.com/b/ericlippert/archive/2010/10/28/async...](http://blogs.msdn.com/b/ericlippert/archive/2010/10/28/asynchrony-
in-c-5-part-one.aspx)

------
Sindrome
It's scary to see VB, Rails, and Node in the same line of text.

~~~
moonchrome
But very appropriate IMO.

------
MartinCron
One of these things is not like the others.

(Visual Basic wasn't a web-specific technology)

~~~
randomdata
node.js isn't a web-specific technology either. It is an event processing
framework, like EventMachine on Ruby or Twisted on Python. And then PHP and VB
are programming languages, while the other two are only frameworks atop other
languages.

Beyond them all being tools programmers use, it is tough to draw any real
commonality between them.

------
elchief
What does Node have to do with forms?

Does he mean backbone?

~~~
nateps
Comparing PHP and Rails to Node.js is not quite right, as PHP and Rails are
application frameworks and Node.js is primarily a platform for creating
application servers. There are a number of more analogous frameworks being
written on top of Node.js, but none of them have reached a similar level of
maturity and adoption yet.

I believe that the author is arguing that Node.js could reach a similar level
of popularity as Rails if there were a framework that provided some of the
ease of use for common use cases, such as creating typical CRUD apps. However,
he also states that in order to displace Rails, such a framework would also
need to offer some distinct advantages, such as better support for realtime.

Backbone, Ember, Knockout, etc. are client-side frameworks. They make it
easier to structure complex client code, but they don't include a simple
solution for creating a server or synching data among clients and servers.

It's still under active development, but I have been working on a full-stack
framework on top of Node.js that is more like what the author was envisioning:
<http://derbyjs.com>

Derby provides server _and_ client rendering, and it automatically
synchronizes data in realtime. The idea is to make writing realtime apps so
simple that any app can take advantage of advanced realtime features, fast
server-rendered page loads, and instant client-rendered page updates.

------
crazygringo
Node.js bases everything around async programming, and this is just too
difficult for mediocre programmers to wrap their heads around, and use
effectively. (But it's fantastic for good programmers.)

I don't think Node is even _trying_ to follow in the line of those other easy-
to-use languages. Why would it want to?

~~~
batista
_> Node.js bases everything around async programming, and this is just too
difficult for mediocre programmers to wrap their heads around, and use
effectively. (But it's fantastic for good programmers.)_

It has nothing to do with mediocre vs good programmers.

A good programmer maybe better able to hold an async callback flow in his mind
than a mediocre one, but he too will be hampered by it. I.e both will be MORE
productive with non-callback async style programming. Callback style async
code is needlessly more difficult compared to linear style async code --and
the keyword here is "needlessly", as this difficulty doesn't buy you
absolutely nothing, only introduces more bugs and hampers readability.

(To clear another misconception, it also shares very little with event-driven
UI code --there the callbacks are much more coarse, based on high level
tasks).

Guido, the creator of Python, a good programmer if I ever seen one, absolutely
abhors async programming. And the designers in all modern languages, from C#
to Go to Scala to Erlang etc, have also decided against using the Node style
for async programming.

Plus, it's not like Ryan Dahl is some programming of Dennis Richie
proportions, or anything like it either. Compared to most language designers,
he is just a script kiddie. Considering, also, that node isn't even a
language, it's a hack on V8, similar to what dozens of people have already
done on other platforms, from Tornado to Twister, to EventMachine etc.

~~~
artsrc
> C# does have API's like this

<http://msdn.microsoft.com/en-us/library/7de1x8cb.aspx>

~~~
batista
Which is why they scrapped it and introduced async and friends:

[http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.a...](http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.aspx)

