Visual Basic, PHP, Rails. Is Node.js next? | Hacker News Reader

Visual Basic, PHP, Rails. Is Node.js next?

andrewchenblog.com

56 pointsdwynings37 comments

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...

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

Seems like node.js was invented for back-end, system programming, and network communication type of software systems, not optimized for typical web-app.

Why does it make lazy loading impossible?

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);
        });
    });

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.

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.

> 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.

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

Yes, there is already a CoffeeScript fork that makes asynchronous code less cumbersome by making it look like synchronous code. It's called IcedCoffeeScript and is at http://maxtaco.github.com/coffee-script/.

You can get the best of both worlds: a synchronous programming model combined with the low memory memory usage of Node by using fibers. The trust issues relating to cooperative multitasking that you mention are still valid, but I haven't run into these problems in practice.

There are some benchmarks in the README to Common Node, a library that I wrote that makes using fibers easier: https://github.com/olegp/common-node#readme

Lazy loading becomes very straightforward and something I do fairly often when using e.g. https://github.com/olegp/mongo-sync

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'.

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.

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.

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.

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.

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.

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.

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.

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.

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.

It's not that they've seen through the smoke and mirrors; old projects have significant momentum. I never, ever want to hand-roll SQL statements ever again, unless I _really_ need to.

> 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.

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

... or make mobile development a lot easier.

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.

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!)

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...

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

But very appropriate IMO.

One of these things is not like the others.

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

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.

What does Node have to do with forms?

Does he mean backbone?

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.

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?

>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.