7 ms·

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

56 points by dwynings 15y ago

gouranga 15y ago
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!)
MartinCron 15y ago
One of these things is not like the others. (Visual Basic wasn't a web-specific technology)
- randomdata 15y ago
  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.
crazygringo 15y ago
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 15y ago
  >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 15y ago
    > C# does have API's like this http://msdn.microsoft.com/en-us/library/7de1x8cb.aspx http://msdn.microsoft.com/en-us/library/7de1x8cb.aspx
    - batista 15y ago
      Which is why they scrapped it and introduced async and friends: http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.aspx http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.a...
- deleted 15y ago
  [deleted]
alexbell 15y ago
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 15y ago
  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.
olalonde 15y ago
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#Cooperative_multitasking.2Ftime-sharing http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati... [1] http://syskall.com/how-to-write-your-own-native-nodejs-extension http://syskall.com/how-to-write-your-own-native-nodejs-exten...
- edwinnathaniel 15y ago
  Seems like node.js was invented for back-end, system programming, and network communication type of software systems, not optimized for typical web-app.
- wahnfrieden 15y ago
  Why does it make lazy loading impossible?
  - olalonde 15y ago
    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); }); });
plasma 15y ago
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/asynchrony-in-c-5-part-one.aspx http://blogs.msdn.com/b/ericlippert/archive/2010/10/28/async...
nchuhoai 15y ago
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 15y ago
  ... or make mobile development a lot easier.
Sindrome 15y ago
It's scary to see VB, Rails, and Node in the same line of text.
- moonchrome 15y ago
  But very appropriate IMO.
throwa 15y ago
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 http://node-chatty.herokuapp.com/chatty See blog post on that: http://bit.ly/zorHYA 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.
AdrianRossouw 15y ago
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'.
ilaksh 15y ago
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.
gexla 15y ago
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 15y ago
  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 15y ago
    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 15y ago
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 15y ago
  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 15y ago
    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.
elchief 15y ago
What does Node have to do with forms? Does he mean backbone?
- nateps 15y ago
  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 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.

56 points by dwynings 15y ago

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

MartinCron 15y ago

One of these things is not like the others. (Visual Basic wasn't a web-specific technology)

randomdata 15y ago
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.

crazygringo 15y ago

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 15y ago
>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 15y ago
  > C# does have API's like this http://msdn.microsoft.com/en-us/library/7de1x8cb.aspx http://msdn.microsoft.com/en-us/library/7de1x8cb.aspx
  - batista 15y ago
    Which is why they scrapped it and introduced async and friends: http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.aspx http://blogs.msdn.com/b/csharpfaq/archive/2010/10/28/async.a...
deleted 15y ago
[deleted]

alexbell 15y ago

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 15y ago
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.

olalonde 15y ago

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#Cooperative_multitasking.2Ftime-sharing http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati... [1] http://syskall.com/how-to-write-your-own-native-nodejs-extension http://syskall.com/how-to-write-your-own-native-nodejs-exten...

edwinnathaniel 15y ago
Seems like node.js was invented for back-end, system programming, and network communication type of software systems, not optimized for typical web-app.
wahnfrieden 15y ago
Why does it make lazy loading impossible?
- olalonde 15y ago
  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); }); });

plasma 15y ago

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/asynchrony-in-c-5-part-one.aspx http://blogs.msdn.com/b/ericlippert/archive/2010/10/28/async...

nchuhoai 15y ago

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 15y ago
... or make mobile development a lot easier.

Sindrome 15y ago

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

moonchrome 15y ago
But very appropriate IMO.

throwa 15y ago

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 http://node-chatty.herokuapp.com/chatty See blog post on that: http://bit.ly/zorHYA 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.

AdrianRossouw 15y ago

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

ilaksh 15y ago

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.

gexla 15y ago

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 15y ago
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 15y ago
  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 15y ago

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 15y ago
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 15y ago
  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.

elchief 15y ago

What does Node have to do with forms? Does he mean backbone?

nateps 15y ago
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 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.