10 ms·

Thoughts on Rails, Node, and the web apps of today

83 points by paulbjensen 14y ago

davidw 14y ago
I'm sure Node is generally faster and consumes fewer server resources than Rails. How about speed of developing things though, that do involve a relational database on the server? Rails has so much in terms of convenience functions that it's hard to jump to anything else, outside of applications where it's clearly not suited. Erlang has been faster and better at async than even Node since before Node even existed, but it's painful to use after getting used to Rails because it feels like a lot more typing and a lot more doing stuff by hand that Rails handles easily.
- paulbjensen 14y ago
  I agree, Erlang is very interesting (especially for the hot-code swapping capability). I've been looking into it recently, specifically a project called Elixir (http://elixir-lang.org http://elixir-lang.org) which is a language built on top of the Erlang VM.
  - _nato_ 14y ago
    Also, check out Chicago Boss!
- pjmlp 14y ago
  Erlang also has the benefit of being able to compile to native code, if you wishes to do so.
  - pooriaazimi 14y ago
    Well, V8 kinda barfs out native code too... I know it's not the same thing[1], but it's not like that to run a loop in Node.js the parser has to read the line "console.log('hello');" 10 times, tokenize it, generate a parse tree, etc. I just wanted to point it out because I think most people don't know about it, and that's why they are amazed at Node.js's speed (how can a interpreted language like JS be so fast?!). [1]: It's definitely slower than native code generated by Erlang, I'm not saying it's faster or even on par; but still, it's much better than an interpreter! This StackOverflow answer is relevant: http://stackoverflow.com/a/4220550/347353 http://stackoverflow.com/a/4220550/347353
    - davidw 14y ago
      http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... Actually does show V8 as being faster than Erlang's HiPE... I guess it pays off to have someone like Google sinking all that work into making things fast.
      - pooriaazimi 14y ago
        Yes. But let's hope that Go thing doesn't distract them...
masto 14y ago
Rails developers seem to be having this revelation a lot recently. I don't think it's a particularly new idea, and I don't see why Rails vs Node vs Java has anything to do with it. MVC is ok for a backend that's "just an API" (although there are probably better ways to structure things, such as CQRS). The language is irrelevant apart from the reasons it's always been relevant (speed of development, ease of deployment, testability, etc.). I think the point at the end is worth expanding on, though: as long as your API is an API and not a thin connector to a specific backend technology, you can in theory swap out parts or the whole thing. Some time ago my company decided to build a new "web application", and there was some debate over how to structure the communication between (at the time) Flash and the backend. Some argued in favor of a proprietary protocol that makes it very easy for Flash to talk to Java and share data structures. Had we gone with that approach, we would have: 1. not had an easy path to having an "external API" by leveraging the identical internal API already built, 2. been stuck with Flash or at least had a much harder time converting to HTML when it became obviously the right thing to do, and 3. been stuck with Java on the backend and no clean service interface between the backend and fronted models. It's always necessary to take some shortcuts in development, and I believe it's very important to choose the right shortcuts. Compromising on interfaces and encapsulation is almost always a terrible idea; better to spend the time hiding an ugly implementation behind a clean interface so that you at least have the option to fix it later.
- pjmlp 14y ago
  We had this revelation already back in 2002! Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Around 2001 we reached the conclusion that it wasn't scaling any longer for the type of loads that we needed, and more a better language infrastructure was required. After some research, the framework was ported to .NET, on those days still beta, but their JIT could already yield much more performance than our home grown solution.
  - davidw 14y ago
    > Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Which Apache Tcl thing? Who are you, by the way? Your profile doesn't show anything. BTW, Rivet can be scaled, like anything else can, although you're right that given the same resources, a compiled language is going to be more efficient. These guys use Rivet successfully: http://flightaware.com/ http://flightaware.com/ - A former developer of Apache Rivet.
robot 14y ago
Can you not mix Rails with backbone.js and the like? I thought it was possible.
- jschuur 14y ago
  Not only that, but there's a whole book on the subject (I'm not affiliated with it): https://workshops.thoughtbot.com/products/1-backbone-js-on-rails https://workshops.thoughtbot.com/products/1-backbone-js-on-r...
- taterbase 14y ago
  You can, it just makes some of Rails' niceties unnecessary. Views and "Controllers" are handled up front by backbone. You just need routing and models from Rails.
  - stiller 14y ago
    Backbone controllers don't replace Rails controllers. You will still need both for a functioning app. Rails' views are largely replaced by client-side templates in a single-page app, although you can use the asset pipeline to compile and serve these.
  - irahul 14y ago
    > You can, it just makes some of Rails' niceties unnecessary. Views and "Controllers" are handled up front by backbone. You just need routing and models from Rails. backbone.js sends CRUD requests to rails app which are handled by the controller, and the main page is rails view.
- nahname 14y ago
  Backbone is built with that intension in mind. It is quite opinionated in that regard as well. Look at how Backbone collections work to understand why.
- jashkenas 14y ago
  Backbone.js was originally developed as part of the front-end of a Rails app: DocumentCloud.org ... that said, it's being used with a vast variety of different backends these days: http://backbonejs.org/#examples http://backbonejs.org/#examples
twinturbo 14y ago
The author is saying since Node is async by default and rails is not that, that node is better? For one, Rails neither async or sync. The programmer decides what to do. Two, Rails is a Framework, Node is a quasi language/framework. Want to do something completely async in Ruby use EventMachine. Zomg you're now async. And really, MVC is no longer a good pattern for backends? That makes perfect nonsense. V = JSON, C = Things Interacting with HTTP, M = Domain Objects. Out of curiosity, are they are any mature ORM's for Node? ActiveRecord has been around for quite a long time. You don't simply clone 8 years worth of development time.
tferris 14y ago
Great article and still wonder that not more people got the idea of Node, Mongo and related tech. Rails isn't bad and full of good ideas and a rich ecosystem but at the same time it's terribly aged in lots of areas.
- pjmlp 14y ago
  I don't get it, because I have being doing asynchronous server side programming for years in C, C++, C#, Java. It is already enough that I have to deal with JavaScript on the UI side.
  - rch 14y ago
    Could you imagine a dedicated JavaScript developer accessing your code through a messaging service? Then you wouldn't have to deal with it at all... * why the downvote? Is it for being stupid, or for sounding snarky?
_nato_ 14y ago
I am involved with a Rails project where the creative developer decided a single-page app was what we needed. We use the views/partials as fetching pieces, calling them via ajax calls and all is well. The added benefit is every unit of namespace has its own home, so SEO for everything is achieved. I am a huge advocate for the newer and better, but Rails is a great solution for single page applications. Also, it's great to write code in Ruby whenever one can; cmon, life is too short!
jroes 14y ago
I'm not sure why Sinatra was not considered in the mix here. Sinatra is great for building simple APIs in Ruby. Heck, Express essentially started out as a clone of Sinatra for Node. One challenge in the Node community is the ecosystem. There are not nearly as many libraries in npm as there are in RubyGems. Of that small set of libraries, a large portion of these have been abandoned. Of that smaller set that haven't been abandoned, there are large portions of missing functionality, are not very stable, or are constantly changing. There are certain cases that Node works really well for right now, like building real-time chat apps. But having worked on some medium-scale Node projects recently, I constantly find myself re-implementing Rails functionality or rewriting common Ruby gems due to the lack of mature libraries.
- arturadib 14y ago
  I think the author emphasized performance. Sinatra might be Express's precedent, but it doesn't have Node's runtime behind it to deliver performance (async I/O, low-memory footprint, etc).
  - gary4gar 14y ago
    Tried running Sinatra on jRuby?
  - jroes 14y ago
    Performance is one of the few legitimate arguments the Node community makes. It is wicked fast out-of-the-box compared to Ruby out-of-the-box. Unfortunately there are many other factors involved in building software that matter as well.
  - jshen 14y ago
    "deliver performance" is too abstract. I usually throw varnish in front of my ruby apps to get performance. I find this gives me a more productive programming environment (ruby), and insane performance. Node only becomes useful for me when I need to keep a lot of connections open and handle them simultaneously, and a few other rare situations like that.
  - dataminer 14y ago
jawr 14y ago
What about that old saying: "The right tool for the job"?
charliesome 14y ago
> This decoupling of MVC is well-supported, but you then find that you're using Rails as an API alongside being a web application; It's not a clean definition of responsibilities. I'm not so sure about this part. To me, it feels like the difference between a web app and an API is simply the fact that an API returns machine readable data (be it JSON, or XML, or whatever). The JSON/XML/etc is just another way of presenting the same data - you should still be able to share a lot of the M and C between your two Vs.
lucian1900 14y ago
Dammit, it's not real-time web. There are no time constants considered, designed for or proven. At best it's "live" web or "quick update" web.
- paulbjensen 14y ago
  Sorry.
  - lucian1900 14y ago
    Sorry, I didn't mean to come over as angry. No need to apologise. It just bothers me that the term real-time is being misused a lot nowadays.
    - paulbjensen 14y ago
      I understand.
    - bergie 14y ago
      Yep, I like the term Live Web.
- mcantelon 14y ago
  Realtime-ish. ;)
arturadib 14y ago
> I see a picture emerge where the back-end will become purely an API component Not so fast. That makes sense for highly interactive apps with private content (Trello, Gmail, etc), not so much for public-facing and content-driven sites. That is, unless you're OK with sacrificing that organic Google traffic to your site? If not, you have two options: do the entire rendering + biz logic on the server (in which case Rails still makes a lot of sense, though some Node frameworks are getting there), or duplicate your client-side code on the server so that Google's hashbangs work. The bigger picture is that the web + search engines are kind of broken right now: There's a tremendous opportunity to make progress and use the architecture pointed out by the OP, but as of today there is no simple solution to make the architecture play nicely with Google without duplicating the work on the server (Meteor seems to be making progress there). Until a simple solution is found, I think we're stuck with the dilemma and will have to continue to do MVC both on the client and on the server. It sucks.
- facorreia 14y ago
  I assume he's talking about web apps, not web sites.
  - arturadib 14y ago
    > I have abandoned Ruby and Rails in its entirety So I thought he was talking about both. (As I once considered doing, too). Also very frequently the distinction is rather blurry: Is Twitter an app or a site?
    - facorreia 14y ago
      When you have a content-driven site that has to be indexable while supporting user interaction, usually server-side generated HTML with client-side AJAX (preferably with graceful degradation) can be an effective pattern. For line-of-business apps or apps in general that can benefit from a rich interface and possibly local storage, full client-side presentation layer (HTML or native) coupled to server-side pure web services can be effective.
ef4 14y ago
Node is maddening for one simple reason: asynchronous code shouldn't need to look like asynchronous code, and in fact it's much safer and less verbose if it doesn't. The whole performance argument is completely beside the point. Yes, we get it, in-process asynchronous parallelism is where its at. But it simply doesn't follow that we need to live in inversion-of-control hell. Even the simplest node program ends up drowning in error-handling code, because there's no way to automatically propagate errors back to the right place. Every function needs to handle error conditions immediately, because you can't throw an error up the stack, because your stack is completely meaningless. This is a huge step backward. It feels like coding directly against system calls in C. It doesn't need to be this way. There's no reason your language runtime can't be smart enough to switch contexts automatically, so that your code gets to be "blocking" even though the actual OS-level process is never blocked. Erlang does this, Stackless Python does this, any Lisp with good old call-with-current-continuation does this.
- equark 14y ago
  It's absolutely a step back and the Node community is way too harsh on those that point this out. But they are probably making the right call by not forking JavaScript. If you want a synchronous style its easy enough with node-fibers. The problem is mostly that there isn't a cultural consensus around a node-fibers based ecosystem of libraries.
  - scriby 14y ago
    For those interested in the fibers way of doing things, I recommend checking out https://github.com/scriby/asyncblock https://github.com/scriby/asyncblock. It provides an easy-to-use abstraction to get the best of both worlds (straight-line code without blocking). I don't think there really needs to be a fibers based ecosystem. Isn't it best if modules don't rely on fibers such that they can be reused in either context?
  - ef4 14y ago
    This is absolutely correct. The lack of consensus is the heart of the problem. There are several nice solutions (node-fibers being one), but none of them is dominant, so none of them work out of the box with everything else. I'm convinced the only way you get this kind of consensus is by building a feature into your language's standard library. This is one big reason that languages with robust "batteries included" standard libraries have been successful. It makes it so much easier to interoperate when everyone can just assume the same abstractions are always available.
tubbo 14y ago
The reason why Rails is going to continue being awesome even in the API-dominated web apps of tomorrow, is the asset pipeline. There's just nothing else out there that manages your assets quite the same way. In fact, the asset pipeline makes it dead-simple and even efficient to program big, high-performance apps in CoffeeScript. Sure, it doesn't force asynchronous behavior, but I feel that's more of a feature than a flaw. Sometimes, asynchronous calls are just not possible (like in the case of Authorize.Net's API), and you need to build something a little more robust, and easy to test when things go wrong. Therefore, I feel Rails is actually the best choice for an API backend, because it has so many drop-in monitoring tools available as well as ways to enhance performance by dropping frameworks you don't need, plus you can code asynchronously with it but you don't have to.
- deleted 14y ago
  [deleted]
drharris 14y ago
Am I the only one out there that _doesn't_ think single-page apps are the future? It reminds me of the mid-2000s, "AJAX all the things!" I might be wrong about it, just not on this bandwagon at all. I still find the true power in the internet is hypertext, and single page apps seem to break it. Of course, I also prefer articles over video and not having a firehose of information thrown at me. Can someone point me to a way to use Node that actually makes sense for something that doesn't have to be near-real-time?
- strudles 14y ago
  yes, you are wrong.
  - strudles 14y ago
    I'll stop being mischievousness, but basically the single page app replaces the desktop app of the past, this means: - We build for the browser not the OS, no dependency in an organisation on windows, linux etc, it will even work on your ipad and mobile. This simplifies desktop support. - server can easily publish updates frequently, very agile and responsive to change - Takes advantage of the cloud and collaboration, your web app now has an API (your desktop app didn't!) so you can share data, link to other services and other web apps. Think of google docs, why would you create a word document and email it around or save on a share when you can share it in a web app and even have multiple people edit the document at the same time! I believe the browser is replacing the OS, not surprisingly it doesn't do a very good job and it's a pain to work with but the end result is so much better for your users. lastly I don't understand that suggestion ajax was a fad from mid 2000's ?? it's used everywhere and to mostly :) good effect !
    - drharris 14y ago
      > basically the single page app replaces the desktop app of the past Yes, and I am saying this is shortsighted. We went from silos of information and data on a single computer and evolved into creating information in the public internet. Why go backwards? Outside of a small niche or two is there really a need for desktop apps hosted online? If they don't interact with the larger web, then just leave them on the desktop. > - Takes advantage of the cloud and collaboration I find this particularly ironic, since single-page apps actually break the standard of collaboration that has been around since the birth of the internet. I should be able to refer someone to a specific piece of information, they should be able to share it to others. And I'm not talking about hashbangs, just good old HTTP links. > I believe the browser is replacing the OS I don't. Browsers can't exist without an OS, for one. We're always going to need an OS of some fashion, and it's always going to have opinions and lock us in to certain paradigms. And that's actually a GOOD thing. I sure hope this misguided fad of the OS-less world will fade soon.
programminggeek 14y ago
Having built with node, ruby, python, php and even did a web services framework in node, I can say that the author is both right and wrong. Right - node is fast/faster and that rails is probably overkill for making web api stuff. Wrong - single page apps are the future. I write single page apps, especially mobile JS apps, BUT rails style frameworks are still incredibly important for 1 huge reason - search engines. If you have a content site, you will have a web front end that is indexible for at least the next 5-10 years. Single page apps are not as indexible/crawlable yet. So, will you write some single page apps? Yes, are they the one true future, no. The future is probably a combination of native apps on various devices, a traditional web front that is indexable, and probably some single page javascript stuff powering admin panels and highly interactive portions of your site that don't need to be indexable. For example, in creating ReMeme (http://reme.me http://reme.me) it has a web front that is indexable by google, it has mobile apps and the whole thing is backend API driven by a sinatra app. At this point I have potentially 4 different platforms talking to the api, not just a "single page web app". If it ever gets on more mobile platforms or even on the desktop, that's even more. The web's a big deal and will stay that way, but you'll probably find yourself writing a bunch of interfaces in different languages, platforms, etc. before you know it. Rails vs. single page isn't the debate. Pick a tool and ship your API, it doesn't matter if it's rails or node or python or php. Once you ship your API, your bigger problem will be how do you manage the complexity of developing for so many platforms?
- stdbrouw 14y ago
  > BUT rails style frameworks are still incredibly important for 1 huge reason - search engines. A project I toyed with a while ago, but never finished (because I don't need it right now), was an app server that can render and serve Backbone views on the server, for search engines and to speed up the first page load (after which most clients would switch to client-side rendering.) See https://github.com/stdbrouw/backbone-express https://github.com/stdbrouw/backbone-express. https://github.com/developmentseed/bones https://github.com/developmentseed/bones does something similar. There's a ton of reasons why people would want to stick with Rails or another server-side framework, but searchability isn't necessarily the big problem.
jondot 14y ago
I heard the first call for "Rails is dead" around 7-8 months ago. While then I completely disregarded it, now I'm even more so disregarding it. I choose the right tool for the right task. Linger on that over-used saying for a moment. I use Rails when I'm not familiar with the domain enough (this is the business of Software Engineering, we never are as familiar with the domain as the domain experts) and it provides me a platform for radically fast development, in the end I may also have a product that can withhold 2-3 years of evolution, before we need to scale, if even needed (premature optimization..). I also use Rails when the quality levels are set high, and when I need tons of libraries, and I need those fast. In node, the quality level of such libraries are much worse (if you haven't seen it, you're not doing Node enough time - because I haven't seen it at my first half a year on Node). The number of quality libraries / npm modules are probably several magnitudes of order less than that of Ruby gem world. You're going to need to wait 4 years until you get that level of diversity and quality and it sets up in a comparable way. And I use Ruby when I don't care about slow clients, or doing system-level work. At any given time, I keep myself the option to use JRuby, which has comparable to MRI (the "normal", C implementation of Ruby) performance and better on a considerable number of criteria. IMHO DynamicInvoke on the JVM will be a game changer in terms of people considering JRuby against, Groovy, or Scala. I use node.js when I know the domain will remain small, non-complex, and I'll be dealing with slow clients (real users). To top all of that, backend systems will NOT turn into thin api servers. Not by any chance. Twitter themselves are rolling back their SPA and bringing back server side template rendering. The number of problem you get into while moving all of your logic and rendering to the client requires a huge blog post which I'll probably make one day. Most people are not aware of that because they never came from full-fledged enterprise level desktop apps -- I used to design CADs and pretty familiar with complex client-side architectures, there are so many dragons there, I'm very happy I now live on the server side, where things are much more predictable. So no, Rails is not dying and neither is Ruby. With the advent of progress on the JVM and JRuby they never will -- this whole discussion reminds me of "Java is about to die" when Scala came around and "Java is about to die" when Oracle came around. And guess what - it didn't (go read about Java 8). tldr; I use both, and I'd recommend anyone would, too. Server-side will never be just a thin api, Ruby or Rails will not die (at least not by that sword), and the only thing one might want to work on is a good foundation of intuition of when to use which of those. @jondot
js4all 14y ago
Very good article and exactly how I experienced my last projects. There have been other articles lately on HN about the changing role of the MVC pattern. The views and models are now on the client. This is ideal because this way the client can respond to several actions without calling the server. The server's role changes to a data driven backend via an API. The API however can also be built using MVCs on the server. Node.js is an ideal candidate for the server, because it is very well suited for building APIs.
Void_ 14y ago
How big an application have you built with Node.js? How complicated was the business logic?
- js4all 14y ago
  I see where this question is going. The logic was rather simple and even though the client-side minimized JS code was already more than 200KB. The optimum cut probably lies some where in between and having logic on both sides.
scrozier 14y ago
Paul has articulated clearly what I had as a visceral reaction after attending this year's RailsConf: Rails is being relegated to being an API machine, and DHH et al are none too happy about it: http://amillionbetterthings.com/2012/04/26/the-rails-times-they-are-a-changin/ http://amillionbetterthings.com/2012/04/26/the-rails-times-t...
radagaisus 14y ago
We've been using both NodeJS and Rails for the last 4 months. Javascript is an amazing language, and coffee makes it even better. After writing a lot of Resque jobs today I have to say my Ruby-fu is not strong, and yet - NodeJS ecosystem is so so so so not mature enough for prime time. The reason I wrote my jobs in Resque? Confidence. If shit will break - it will be on my side, not inside a package required by another package somewhere deep inside node_modules. I'm reading the source of almost every node package I use. I check all the issues on GitHub before trying to play with it. While node core is stable, and everything is so damn fast (thanks Redis) and I enjoy every minute of developing with this stack, I find myself too many times inventing the wheel all over again - instead of focusing on my product.
VeejayRampay 14y ago
Ilya Grigorik is the man. He had all the best ideas, he had implementations and presentations about asynchronous Rails, about how Node was nothing special, nothing that could not be done with Rails. I wish he would still an integral part of the Rails community. Huge loss.

83 points by paulbjensen 14y ago

I'm sure Node is generally faster and consumes fewer server resources than Rails. How about speed of developing things though, that do involve a relational database on the server? Rails has so much in terms of convenience functions that it's hard to jump to anything else, outside of applications where it's clearly not suited. Erlang has been faster and better at async than even Node since before Node even existed, but it's painful to use after getting used to Rails because it feels like a lot more typing and a lot more doing stuff by hand that Rails handles easily.

paulbjensen 14y ago
I agree, Erlang is very interesting (especially for the hot-code swapping capability). I've been looking into it recently, specifically a project called Elixir (http://elixir-lang.org http://elixir-lang.org) which is a language built on top of the Erlang VM.
- _nato_ 14y ago
  Also, check out Chicago Boss!
pjmlp 14y ago
Erlang also has the benefit of being able to compile to native code, if you wishes to do so.
- pooriaazimi 14y ago
  Well, V8 kinda barfs out native code too... I know it's not the same thing[1], but it's not like that to run a loop in Node.js the parser has to read the line "console.log('hello');" 10 times, tokenize it, generate a parse tree, etc. I just wanted to point it out because I think most people don't know about it, and that's why they are amazed at Node.js's speed (how can a interpreted language like JS be so fast?!). [1]: It's definitely slower than native code generated by Erlang, I'm not saying it's faster or even on par; but still, it's much better than an interpreter! This StackOverflow answer is relevant: http://stackoverflow.com/a/4220550/347353 http://stackoverflow.com/a/4220550/347353
  - davidw 14y ago
    http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... Actually does show V8 as being faster than Erlang's HiPE... I guess it pays off to have someone like Google sinking all that work into making things fast.
    - pooriaazimi 14y ago
      Yes. But let's hope that Go thing doesn't distract them...

masto 14y ago

Rails developers seem to be having this revelation a lot recently. I don't think it's a particularly new idea, and I don't see why Rails vs Node vs Java has anything to do with it. MVC is ok for a backend that's "just an API" (although there are probably better ways to structure things, such as CQRS). The language is irrelevant apart from the reasons it's always been relevant (speed of development, ease of deployment, testability, etc.). I think the point at the end is worth expanding on, though: as long as your API is an API and not a thin connector to a specific backend technology, you can in theory swap out parts or the whole thing. Some time ago my company decided to build a new "web application", and there was some debate over how to structure the communication between (at the time) Flash and the backend. Some argued in favor of a proprietary protocol that makes it very easy for Flash to talk to Java and share data structures. Had we gone with that approach, we would have: 1. not had an easy path to having an "external API" by leveraging the identical internal API already built, 2. been stuck with Flash or at least had a much harder time converting to HTML when it became obviously the right thing to do, and 3. been stuck with Java on the backend and no clean service interface between the backend and fronted models. It's always necessary to take some shortcuts in development, and I believe it's very important to choose the right shortcuts. Compromising on interfaces and encapsulation is almost always a terrible idea; better to spend the time hiding an ugly implementation behind a clean interface so that you at least have the option to fix it later.

pjmlp 14y ago
We had this revelation already back in 2002! Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Around 2001 we reached the conclusion that it wasn't scaling any longer for the type of loads that we needed, and more a better language infrastructure was required. After some research, the framework was ported to .NET, on those days still beta, but their JIT could already yield much more performance than our home grown solution.
- davidw 14y ago
  > Back then, I was working for a startup that had a product similar in concept to Rails but based on Apache/TCL developed around 1998. The initial architecture ideas were taken from AOL Server, in case anyone still remembers it. Which Apache Tcl thing? Who are you, by the way? Your profile doesn't show anything. BTW, Rivet can be scaled, like anything else can, although you're right that given the same resources, a compiled language is going to be more efficient. These guys use Rivet successfully: http://flightaware.com/ http://flightaware.com/ - A former developer of Apache Rivet.

robot 14y ago

Can you not mix Rails with backbone.js and the like? I thought it was possible.

jschuur 14y ago
Not only that, but there's a whole book on the subject (I'm not affiliated with it): https://workshops.thoughtbot.com/products/1-backbone-js-on-rails https://workshops.thoughtbot.com/products/1-backbone-js-on-r...
taterbase 14y ago
You can, it just makes some of Rails' niceties unnecessary. Views and "Controllers" are handled up front by backbone. You just need routing and models from Rails.
- stiller 14y ago
  Backbone controllers don't replace Rails controllers. You will still need both for a functioning app. Rails' views are largely replaced by client-side templates in a single-page app, although you can use the asset pipeline to compile and serve these.
- irahul 14y ago
  > You can, it just makes some of Rails' niceties unnecessary. Views and "Controllers" are handled up front by backbone. You just need routing and models from Rails. backbone.js sends CRUD requests to rails app which are handled by the controller, and the main page is rails view.
nahname 14y ago
Backbone is built with that intension in mind. It is quite opinionated in that regard as well. Look at how Backbone collections work to understand why.
jashkenas 14y ago
Backbone.js was originally developed as part of the front-end of a Rails app: DocumentCloud.org ... that said, it's being used with a vast variety of different backends these days: http://backbonejs.org/#examples http://backbonejs.org/#examples

twinturbo 14y ago

The author is saying since Node is async by default and rails is not that, that node is better? For one, Rails neither async or sync. The programmer decides what to do. Two, Rails is a Framework, Node is a quasi language/framework. Want to do something completely async in Ruby use EventMachine. Zomg you're now async. And really, MVC is no longer a good pattern for backends? That makes perfect nonsense. V = JSON, C = Things Interacting with HTTP, M = Domain Objects. Out of curiosity, are they are any mature ORM's for Node? ActiveRecord has been around for quite a long time. You don't simply clone 8 years worth of development time.

tferris 14y ago

Great article and still wonder that not more people got the idea of Node, Mongo and related tech. Rails isn't bad and full of good ideas and a rich ecosystem but at the same time it's terribly aged in lots of areas.

pjmlp 14y ago
I don't get it, because I have being doing asynchronous server side programming for years in C, C++, C#, Java. It is already enough that I have to deal with JavaScript on the UI side.
- rch 14y ago
  Could you imagine a dedicated JavaScript developer accessing your code through a messaging service? Then you wouldn't have to deal with it at all... * why the downvote? Is it for being stupid, or for sounding snarky?

_nato_ 14y ago

I am involved with a Rails project where the creative developer decided a single-page app was what we needed. We use the views/partials as fetching pieces, calling them via ajax calls and all is well. The added benefit is every unit of namespace has its own home, so SEO for everything is achieved. I am a huge advocate for the newer and better, but Rails is a great solution for single page applications. Also, it's great to write code in Ruby whenever one can; cmon, life is too short!

jroes 14y ago

I'm not sure why Sinatra was not considered in the mix here. Sinatra is great for building simple APIs in Ruby. Heck, Express essentially started out as a clone of Sinatra for Node. One challenge in the Node community is the ecosystem. There are not nearly as many libraries in npm as there are in RubyGems. Of that small set of libraries, a large portion of these have been abandoned. Of that smaller set that haven't been abandoned, there are large portions of missing functionality, are not very stable, or are constantly changing. There are certain cases that Node works really well for right now, like building real-time chat apps. But having worked on some medium-scale Node projects recently, I constantly find myself re-implementing Rails functionality or rewriting common Ruby gems due to the lack of mature libraries.

arturadib 14y ago
I think the author emphasized performance. Sinatra might be Express's precedent, but it doesn't have Node's runtime behind it to deliver performance (async I/O, low-memory footprint, etc).
- gary4gar 14y ago
  Tried running Sinatra on jRuby?
- jroes 14y ago
  Performance is one of the few legitimate arguments the Node community makes. It is wicked fast out-of-the-box compared to Ruby out-of-the-box. Unfortunately there are many other factors involved in building software that matter as well.
- jshen 14y ago
  "deliver performance" is too abstract. I usually throw varnish in front of my ruby apps to get performance. I find this gives me a more productive programming environment (ruby), and insane performance. Node only becomes useful for me when I need to keep a lot of connections open and handle them simultaneously, and a few other rare situations like that.
- dataminer 14y ago

jawr 14y ago

What about that old saying: "The right tool for the job"?

charliesome 14y ago

> This decoupling of MVC is well-supported, but you then find that you're using Rails as an API alongside being a web application; It's not a clean definition of responsibilities. I'm not so sure about this part. To me, it feels like the difference between a web app and an API is simply the fact that an API returns machine readable data (be it JSON, or XML, or whatever). The JSON/XML/etc is just another way of presenting the same data - you should still be able to share a lot of the M and C between your two Vs.

lucian1900 14y ago

Dammit, it's not real-time web. There are no time constants considered, designed for or proven. At best it's "live" web or "quick update" web.

paulbjensen 14y ago
Sorry.
- lucian1900 14y ago
  Sorry, I didn't mean to come over as angry. No need to apologise. It just bothers me that the term real-time is being misused a lot nowadays.
  - paulbjensen 14y ago
    I understand.
  - bergie 14y ago
    Yep, I like the term Live Web.
mcantelon 14y ago
Realtime-ish. ;)

arturadib 14y ago

> I see a picture emerge where the back-end will become purely an API component Not so fast. That makes sense for highly interactive apps with private content (Trello, Gmail, etc), not so much for public-facing and content-driven sites. That is, unless you're OK with sacrificing that organic Google traffic to your site? If not, you have two options: do the entire rendering + biz logic on the server (in which case Rails still makes a lot of sense, though some Node frameworks are getting there), or duplicate your client-side code on the server so that Google's hashbangs work. The bigger picture is that the web + search engines are kind of broken right now: There's a tremendous opportunity to make progress and use the architecture pointed out by the OP, but as of today there is no simple solution to make the architecture play nicely with Google without duplicating the work on the server (Meteor seems to be making progress there). Until a simple solution is found, I think we're stuck with the dilemma and will have to continue to do MVC both on the client and on the server. It sucks.

facorreia 14y ago
I assume he's talking about web apps, not web sites.
- arturadib 14y ago
  > I have abandoned Ruby and Rails in its entirety So I thought he was talking about both. (As I once considered doing, too). Also very frequently the distinction is rather blurry: Is Twitter an app or a site?
  - facorreia 14y ago
    When you have a content-driven site that has to be indexable while supporting user interaction, usually server-side generated HTML with client-side AJAX (preferably with graceful degradation) can be an effective pattern. For line-of-business apps or apps in general that can benefit from a rich interface and possibly local storage, full client-side presentation layer (HTML or native) coupled to server-side pure web services can be effective.

ef4 14y ago

Node is maddening for one simple reason: asynchronous code shouldn't need to look like asynchronous code, and in fact it's much safer and less verbose if it doesn't. The whole performance argument is completely beside the point. Yes, we get it, in-process asynchronous parallelism is where its at. But it simply doesn't follow that we need to live in inversion-of-control hell. Even the simplest node program ends up drowning in error-handling code, because there's no way to automatically propagate errors back to the right place. Every function needs to handle error conditions immediately, because you can't throw an error up the stack, because your stack is completely meaningless. This is a huge step backward. It feels like coding directly against system calls in C. It doesn't need to be this way. There's no reason your language runtime can't be smart enough to switch contexts automatically, so that your code gets to be "blocking" even though the actual OS-level process is never blocked. Erlang does this, Stackless Python does this, any Lisp with good old call-with-current-continuation does this.

equark 14y ago
It's absolutely a step back and the Node community is way too harsh on those that point this out. But they are probably making the right call by not forking JavaScript. If you want a synchronous style its easy enough with node-fibers. The problem is mostly that there isn't a cultural consensus around a node-fibers based ecosystem of libraries.
- scriby 14y ago
  For those interested in the fibers way of doing things, I recommend checking out https://github.com/scriby/asyncblock https://github.com/scriby/asyncblock. It provides an easy-to-use abstraction to get the best of both worlds (straight-line code without blocking). I don't think there really needs to be a fibers based ecosystem. Isn't it best if modules don't rely on fibers such that they can be reused in either context?
- ef4 14y ago
  This is absolutely correct. The lack of consensus is the heart of the problem. There are several nice solutions (node-fibers being one), but none of them is dominant, so none of them work out of the box with everything else. I'm convinced the only way you get this kind of consensus is by building a feature into your language's standard library. This is one big reason that languages with robust "batteries included" standard libraries have been successful. It makes it so much easier to interoperate when everyone can just assume the same abstractions are always available.

tubbo 14y ago

The reason why Rails is going to continue being awesome even in the API-dominated web apps of tomorrow, is the asset pipeline. There's just nothing else out there that manages your assets quite the same way. In fact, the asset pipeline makes it dead-simple and even efficient to program big, high-performance apps in CoffeeScript. Sure, it doesn't force asynchronous behavior, but I feel that's more of a feature than a flaw. Sometimes, asynchronous calls are just not possible (like in the case of Authorize.Net's API), and you need to build something a little more robust, and easy to test when things go wrong. Therefore, I feel Rails is actually the best choice for an API backend, because it has so many drop-in monitoring tools available as well as ways to enhance performance by dropping frameworks you don't need, plus you can code asynchronously with it but you don't have to.

deleted 14y ago
[deleted]

drharris 14y ago

Am I the only one out there that _doesn't_ think single-page apps are the future? It reminds me of the mid-2000s, "AJAX all the things!" I might be wrong about it, just not on this bandwagon at all. I still find the true power in the internet is hypertext, and single page apps seem to break it. Of course, I also prefer articles over video and not having a firehose of information thrown at me. Can someone point me to a way to use Node that actually makes sense for something that doesn't have to be near-real-time?

strudles 14y ago
yes, you are wrong.
- strudles 14y ago
  I'll stop being mischievousness, but basically the single page app replaces the desktop app of the past, this means: - We build for the browser not the OS, no dependency in an organisation on windows, linux etc, it will even work on your ipad and mobile. This simplifies desktop support. - server can easily publish updates frequently, very agile and responsive to change - Takes advantage of the cloud and collaboration, your web app now has an API (your desktop app didn't!) so you can share data, link to other services and other web apps. Think of google docs, why would you create a word document and email it around or save on a share when you can share it in a web app and even have multiple people edit the document at the same time! I believe the browser is replacing the OS, not surprisingly it doesn't do a very good job and it's a pain to work with but the end result is so much better for your users. lastly I don't understand that suggestion ajax was a fad from mid 2000's ?? it's used everywhere and to mostly :) good effect !
  - drharris 14y ago
    > basically the single page app replaces the desktop app of the past Yes, and I am saying this is shortsighted. We went from silos of information and data on a single computer and evolved into creating information in the public internet. Why go backwards? Outside of a small niche or two is there really a need for desktop apps hosted online? If they don't interact with the larger web, then just leave them on the desktop. > - Takes advantage of the cloud and collaboration I find this particularly ironic, since single-page apps actually break the standard of collaboration that has been around since the birth of the internet. I should be able to refer someone to a specific piece of information, they should be able to share it to others. And I'm not talking about hashbangs, just good old HTTP links. > I believe the browser is replacing the OS I don't. Browsers can't exist without an OS, for one. We're always going to need an OS of some fashion, and it's always going to have opinions and lock us in to certain paradigms. And that's actually a GOOD thing. I sure hope this misguided fad of the OS-less world will fade soon.

programminggeek 14y ago

Having built with node, ruby, python, php and even did a web services framework in node, I can say that the author is both right and wrong. Right - node is fast/faster and that rails is probably overkill for making web api stuff. Wrong - single page apps are the future. I write single page apps, especially mobile JS apps, BUT rails style frameworks are still incredibly important for 1 huge reason - search engines. If you have a content site, you will have a web front end that is indexible for at least the next 5-10 years. Single page apps are not as indexible/crawlable yet. So, will you write some single page apps? Yes, are they the one true future, no. The future is probably a combination of native apps on various devices, a traditional web front that is indexable, and probably some single page javascript stuff powering admin panels and highly interactive portions of your site that don't need to be indexable. For example, in creating ReMeme (http://reme.me http://reme.me) it has a web front that is indexable by google, it has mobile apps and the whole thing is backend API driven by a sinatra app. At this point I have potentially 4 different platforms talking to the api, not just a "single page web app". If it ever gets on more mobile platforms or even on the desktop, that's even more. The web's a big deal and will stay that way, but you'll probably find yourself writing a bunch of interfaces in different languages, platforms, etc. before you know it. Rails vs. single page isn't the debate. Pick a tool and ship your API, it doesn't matter if it's rails or node or python or php. Once you ship your API, your bigger problem will be how do you manage the complexity of developing for so many platforms?

stdbrouw 14y ago
> BUT rails style frameworks are still incredibly important for 1 huge reason - search engines. A project I toyed with a while ago, but never finished (because I don't need it right now), was an app server that can render and serve Backbone views on the server, for search engines and to speed up the first page load (after which most clients would switch to client-side rendering.) See https://github.com/stdbrouw/backbone-express https://github.com/stdbrouw/backbone-express. https://github.com/developmentseed/bones https://github.com/developmentseed/bones does something similar. There's a ton of reasons why people would want to stick with Rails or another server-side framework, but searchability isn't necessarily the big problem.

jondot 14y ago

I heard the first call for "Rails is dead" around 7-8 months ago. While then I completely disregarded it, now I'm even more so disregarding it. I choose the right tool for the right task. Linger on that over-used saying for a moment. I use Rails when I'm not familiar with the domain enough (this is the business of Software Engineering, we never are as familiar with the domain as the domain experts) and it provides me a platform for radically fast development, in the end I may also have a product that can withhold 2-3 years of evolution, before we need to scale, if even needed (premature optimization..). I also use Rails when the quality levels are set high, and when I need tons of libraries, and I need those fast. In node, the quality level of such libraries are much worse (if you haven't seen it, you're not doing Node enough time - because I haven't seen it at my first half a year on Node). The number of quality libraries / npm modules are probably several magnitudes of order less than that of Ruby gem world. You're going to need to wait 4 years until you get that level of diversity and quality and it sets up in a comparable way. And I use Ruby when I don't care about slow clients, or doing system-level work. At any given time, I keep myself the option to use JRuby, which has comparable to MRI (the "normal", C implementation of Ruby) performance and better on a considerable number of criteria. IMHO DynamicInvoke on the JVM will be a game changer in terms of people considering JRuby against, Groovy, or Scala. I use node.js when I know the domain will remain small, non-complex, and I'll be dealing with slow clients (real users). To top all of that, backend systems will NOT turn into thin api servers. Not by any chance. Twitter themselves are rolling back their SPA and bringing back server side template rendering. The number of problem you get into while moving all of your logic and rendering to the client requires a huge blog post which I'll probably make one day. Most people are not aware of that because they never came from full-fledged enterprise level desktop apps -- I used to design CADs and pretty familiar with complex client-side architectures, there are so many dragons there, I'm very happy I now live on the server side, where things are much more predictable. So no, Rails is not dying and neither is Ruby. With the advent of progress on the JVM and JRuby they never will -- this whole discussion reminds me of "Java is about to die" when Scala came around and "Java is about to die" when Oracle came around. And guess what - it didn't (go read about Java 8). tldr; I use both, and I'd recommend anyone would, too. Server-side will never be just a thin api, Ruby or Rails will not die (at least not by that sword), and the only thing one might want to work on is a good foundation of intuition of when to use which of those. @jondot

js4all 14y ago

Very good article and exactly how I experienced my last projects. There have been other articles lately on HN about the changing role of the MVC pattern. The views and models are now on the client. This is ideal because this way the client can respond to several actions without calling the server. The server's role changes to a data driven backend via an API. The API however can also be built using MVCs on the server. Node.js is an ideal candidate for the server, because it is very well suited for building APIs.

Void_ 14y ago

How big an application have you built with Node.js? How complicated was the business logic?

js4all 14y ago
I see where this question is going. The logic was rather simple and even though the client-side minimized JS code was already more than 200KB. The optimum cut probably lies some where in between and having logic on both sides.

scrozier 14y ago

Paul has articulated clearly what I had as a visceral reaction after attending this year's RailsConf: Rails is being relegated to being an API machine, and DHH et al are none too happy about it: http://amillionbetterthings.com/2012/04/26/the-rails-times-they-are-a-changin/ http://amillionbetterthings.com/2012/04/26/the-rails-times-t...

radagaisus 14y ago

We've been using both NodeJS and Rails for the last 4 months. Javascript is an amazing language, and coffee makes it even better. After writing a lot of Resque jobs today I have to say my Ruby-fu is not strong, and yet - NodeJS ecosystem is so so so so not mature enough for prime time. The reason I wrote my jobs in Resque? Confidence. If shit will break - it will be on my side, not inside a package required by another package somewhere deep inside node_modules. I'm reading the source of almost every node package I use. I check all the issues on GitHub before trying to play with it. While node core is stable, and everything is so damn fast (thanks Redis) and I enjoy every minute of developing with this stack, I find myself too many times inventing the wheel all over again - instead of focusing on my product.

VeejayRampay 14y ago

Ilya Grigorik is the man. He had all the best ideas, he had implementations and presentations about asynchronous Rails, about how Node was nothing special, nothing that could not be done with Rails. I wish he would still an integral part of the Rails community. Huge loss.