Why we moved from NodeJS to Ruby on Rails

I really do think that, as time wears on, we will see more of these incidents of people switching from Node to another, more familiar development environment. It seems to me that a lot of people started using Node simply because of the amount of hype that surrounded it, and many of these decisions were not as well researched as they should've been.<p>Reading through this gentleman's blog post, it seems that, originally, Node was chosen for just one reason – he wanted to develop the entire application in JavaScript. Other than this, it does not seem that he took the time to research the Node development environment before deciding to develop his application in it.<p>With respect to the author of this post, the testing environment and the ease of developing a CRUD web application are things that should have been looked into before a single line of code intended for production had been written.<p>In addition to this, as several other commentators have already noted, Node is not directly comparable to Rails. Node is basically an event framework and standard library that bolts onto JavaScript. Node would be more comparable to something like Python's Twisted or Ruby's EventMachine. The author was probably using one of the frameworks available in Node such as Express.js, Railway.js, or Geddy.

I only played with Node.js and I didn't like it. The event loop is cool for long-lived requests. It scales and so on.<p>However for the project I worked on, I decided to go with Ruby on Rails + Java Servlets.<p>You see, only some parts of an API needs to scale. But what about simple web pages like the viewing/editing of a user profile? What about viewing some stats that are auto-generated? What about the freakishly boring admin interface that every web app must have? What about deployment automation? What about just searching for a library that already does what you want and actually finding a good one?<p>Therefore I've built a Ruby on Rails app. Everything except the API that needed to scale was built on top of Rails. Then the API with scalability concerns was built as a couple of Java servlets. And I deployed the whole thing on top of Jetty.<p>The wonderful thing about Jetty is that it has support for continuations, so requests don't have to block on processing in case you're doing something expensive. You can just push that processing in an Akka actor and release the request until a response is ready. And Jetty may not scale as well as something custom built on top of JBoss Netty or Apache Mina, however a single Jetty server does scale to ten thousand requests per sec easily. And in case that doesn't satisfy me at some point, Netty and Mina are there, waiting for me to tap their potential.<p>And then with the wonderful JRuby-Rack integration, I could configure Jetty to select between the pure Java implementation and Ruby on Rails for serving, based on the URL. So everything, like the Rails server, the Java servlets for the API and the queue processing (Akka) is running in a single process. Which really, is freaking awesome.<p>So why use Node.js, when I can get the Rails maturity and ease of use, while escaping to Java in case I have special needs, such as extreme scalability or flexibility?

I could write a similar post, having used Node on a couple of projects before nodding to reality and switching back to Rails for a larger project.<p>For a "typical" web project, Rails simply has a ton of mature libraries that don't exist in Node, or are very early days. Sure, there might be a basic data mapper, but does it have support for testing? Automatic counter caching? Workaround on StackOverflow for a hundred things the framework doesn't cover by default?<p>Rails versus NodeJS isn't apples-to-oranges. Rails is an opinionated framework for web development, Node is a low-level evented framework. This is important because right now, Node has no Rails equivalent. It has Express as the equivalent of Ruby's Sinatra, but for a higher-level web framework, there are several possibilities and none of them the outright leader. This is the situation Python found itself in circa 2006, before Django became the de facto standard for web apps, and (speaking as a mostly-outsider) its seems to me the Python community is better for it. I truly hope a high-level framework establishes itself as the clear standard for Node development, presumably one which embraces the benefits of dual-side JavaScript.

When it comes to prototyping, anything goes - you should be optimizing for the speed with which you can deliver and market-test a product, and you should choose the tools that allow you to do so. The trick is having the discipline to pay back the technical debt that accumulates as a result of the fast, informal prototyping work.<p>I think the OP did exactly that, realizing that Rails is the better long-term solution for their engineering activity. I wouldn't say they "moved" from NodeJS to RoR, because that implies that that they chose a new technology to solve the same problem - they didn't... they chose NodeJS for prototyping and RoR for production.<p>I had the same experience transitioning from a prototype RoR app to a production app also written in RoR - I still did significant rewriting to improve testability/test coverage and make it more RESTful, but I didn't need to switch frameworks to do that.

&#62; NodeJS is suitable for apps that do plenty of short lived requests.<p>I'm confused. Isn't Node's event-loop style programming ideal for long-lived requests? I.e. ones that, under a synchronous i/o, block other requests?

This post would benefit from concrete examples rather than vague complaints. For example, if something is "very immature", why not include specific examples of bugs or issues that required upgrading to "the latest version"? Likewise, if Node's testing frameworks are "good" but "no match for … Django", explain what's missing or how other testing frameworks are better. Being precise with your criticism helps the reader put them in context, and also helps maintainers improve their projects. Unsubstantiated criticism merely generates fear, uncertainty and doubt.

Wow, Node is being turned away from because it's too new, and Rails is the destination because it's established?<p>I remember a few years ago Rails using the argument of re-inventing the wheel was the only way because there was presumably no other capable web framework out there.<p>We all know better now and I hope celebrate choice that's relatively equally capable :)

<i>The data is being written to the db, or being crunched, while the request is ending, and the browser can continue with the important stuff.</i><p>It sounds like a good fit for NodeJS for sure, but for what it's worth, even in a synchronous web framework nothing forces you to keep the connection open until the request has been processed.<p>I don't know off-hand how to do it in Rails, but say in Java Servlet-based frameworks you'd just call HttpServletResponse.close().

I suspect -- and I may be wrong -- that the advantages of using Node differ between large teams and small teams. For my first startup, I had the budget to hire a single full-time developer. The was a substantial amount of work to do on both the frontend and backend -- with the backend development needing to get underway first, but the frontend work being much more experimental and needing to go through many more iterations as part of the development process (we understood this upfront).<p>My developer did his homework, and came to exactly the same conclusions about Node that this article highlights. So he began developing the backend in Python/flask. I'm sure that was a good choice for the backend, on general principle.<p>However, we began hitting problems when it came time to start developing and iterating the frontend in parallel with the backend: it proved to be almost impossible for a single person to handle the task-switching between two completely different languages, testing frameworks, etc. So backend development lagged a little, and frontend development lagged a <i>lot</i>. I'm fairly sure this set the project back by 3-4 months. It wasn't until we brought on a dedicated front-end programmer that development was able to pick up pace a bit.<p>So I can see how for larger companies, it is probably best to optimise the backend with something other than Node -- you will have enough people working for you that backend and frontend programmers can specialise. But for companies with two (or fewer) developers -- which know that they also have to be doing a quite substantial amount of javascript on the front-end -- then I suspect that Node's comparative small task-switching penalty is probably <i>hugely</i> valuable.<p>That's just my hunch, but it's lasted a long while. So as I get ready to hire a couple of developers for my second startup, I'm leaning towards using Node. It's a frontend-intensive application which is unlikely to ever have to deal with "web-scale" issues that more mature backends are needed to handle. And if it <i>does</i> ever approach "web-scale", then it'll <i>certainly</i> have the budget to hire additional programmers to re-implement the backend in something else -- or maybe, by then, Node will have evolved into something sufficiently robust. Either way, it seems better than causing ourselves a bunch of task-switching pain upfront.<p>I'd be really curious to see a critique/comparison of Node which addresses the relative merit (or lack thereof) of its low task-switching barrier -- particularly for small teams.

I read this post as "your mileage may vary", gravitating toward "it doesn't work like we expected". One particular line caught my eye:<p>"NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously."<p>There is a lot to this statement that implies how an application is architected. Node.js is async at heart, and one can only build a successful application if you follow the programmatic model as it's designed. It doesn't matter how simple or complex an application may be, if a framework is being bent to work in ways in which it wasn't designed, the application may not work so well.<p>Reading between the lines, what I'm getting is a picture of a team that has encountered productivity issues with the current stack and is migrating to a more familiar stack to increase productivity. Nothing wrong with that tradeoff, but I always look to what future tradeoffs are being made: "cache everything and gets the work done ASAP" is great <i>until</i> you need finely-grained control of your queries.<p>I'm sure they thought well about their decision, but if asked to make a wager -- I'd guess that certain problems are being traded from one framework to another.

This is why it's good to have a lot of tools in your toolbox. Everything has its strengths and weaknesses.

The author seems to be confused about what Node.js is.<p>&#62; NodeJS is a very young framework, and packages around it are very immature.<p>Node.js is not a framework. It is a JavaScript engine and standard library. Node is comparable to the MRI.

Maybe I'm missing something but isn't node for chat/messaging, API's and other stuff that you might have used something like Twisted for?<p>Why would you use it over Rails/Django etc. for a content-heavy site (i.e. 95% of websites)

The important point in posts such as these is that execution matters, not the tool you use. If the tool you decide to develop with fits, then use it. If you find out later it doesn't work, then switch. Sure, the tool you use can affect your execution, but that only means you have to understand how you want to execute before even selecting a tool.<p>I think it would be a big mistake to read such a post and come to the conclusion that Rails is somehow superior to node.js.

My take on this is that it is more about getting the MVP out with "whatever" (in this case Node), than anything else.<p>I do this all the time. Some ideas get mocked up in python, others PHP, some in C#, etc. Then if it sticks, I look at the needs it has and pick the best tool for the job. Sometimes it Rails, others its .NET.<p>Though it is quite interesting to read about it from someone else's point of view.

This reminds me of Derek Sivers switching from Rails back to PHP 5 years ago :-)<p><a href="http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html" rel="nofollow">http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...</a>

The argument he makes is that it boils down to maturity. One framework is still evolving and the other is more mature.

I'd be curious which things were missing in Node. I realise gratuitous detail doesn't make for a great blog post but if Node.js is missing things that stopped development of an app it would be useful for the Node community to know what they are.<p>Mentioning "immature packages" and "testing" is fine, but I'd really like to know what makes testing on RoR better than, say, testing with Mocha.<p>I'd also be really interested in the experiences of trying to cache with Node. I think while it's possible to do it's definitely a place that could be improved.

Anyone else find it ironic that this post is about moving from Node to Ruby in order to produce the admin interface to a <i>Java</i> hosting service? (This was a blog post written by "Jelastic" devs, who make a Java PaaS product).<p>We seem to be seeing more of this "don't eat your own dogfood" approach to software development lately. The other example that comes to mind is the Play Framework, written in Python and also targeted to Java devs.

First of all I would like to say that I'm no fan of these 54/whatever hour coding rushes, I think it makes people go too fast with poor planning and NO time for testing anything, even for developing looks short, I would rather take my time to plan anything before writing a single line of code.<p>About Node I have played with it and it looks nice but at the end of the day I just returned to Java and PHP (can't talk about ruby never tried and not sure when I will), why? First, all the Node talk seems to revolve around the hype it generated recently, why I don't know. The idea of the async is nice but stall it with something that takes long to process (and needs to send a response) and you are screwed just like any other language, but I think node may be worse as far as my understanding goes its a single thread dispatching stuff (am I right? please correct me on this if I'm wrong).<p>Libraries for it, there seem to be too many of the same kind all of them with different ways of working that is not easy, and when I tried it none did what I wanted.

Does anyone know 1 major consumer-facing site that was able to scale with Rails?<p>I know Twitter kind of had to move away from Rails due to scalability issues.<p>GameBattles.com also had to back away from Rails after their uptime dropped to 80%.<p>I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.

It saddens me that so many developers need to learn why it's a mistake to build a system in node.js right now, just because it's "cool" right now. A variation of this post showed up on HN about 20 times already.<p>The lesson is simple - don't use node.js to build big apps, it's still immature.

This reads like my life story. Falling in love with a new technology, trying to use it in production, only to find out that it just isn't there yet :)<p>Node.js will become a great option for web development, but I don't think that node, at this moment, is ready for "mainstream" use.

I wonder what testing functionality, specifically, they see missing in the Node ecosystem...

If you think how the whole web development has been changing from server-side generated views to more "produce data and send it over as JSON" style services, Node.js and others start to make a lot more sense. That said, the post has point that on more established platform you can expect to be more productive since you have more established work flows and standard libraries.<p>Btw. note the terminology: Node.js should not be called "framework", it's a platform. "Framework" is something that runs on platform and you extend/modify it's functionality by writing code. "Library" is something which you call/use from your code.

<i>Since our stack involved MongoDB, it only made sense to live in a JS only environment. </i><p>I've never used MongoDB; can someone explain to me why this would seem like an advantage, and/or what it has to do with MongoDB?<p>Is the MongoDB API simply JavaScript?

Basically they switched for... personal opinion. That's all I can really gleam from the post. You can do it all in Node JS, they just didn't want to.<p>Screw all the frameworks, I am working with bare-metal Node and loving every minute.

&#62;I am huge fan of NodeJs and I believe it’s a very technology and we will see it getting<p>I think you accidentally word.

Ok. So for a beginner coder looking to build web sites and mobile apps on weekends. They are not looking for a career or job coding. What language?<p>Assume they know html, CSS, Javascript, SQL. Where do they go and spend their next 12 months?<p>When do the differences matter?

i think what i'm enjoying most about node.js and the new frameworks, is that they require me to think differently. i'm also optimistic about coding end-to-end in the same language (client, server, database). this is a big learning curve for many folks. i remember when folks transitioned from C to C++ and from C++ to Java -- it takes awhile. i think this is going to be a lot of fun to see where it takes us. also i think work like coffeescript and future IDEs might make this really interesting. Also meteor -- lots of creativity and cool things.

I'd love some elaboration on these points, especially the one about testing as it's an area that interests me.

For anybody wanting to learn about node the NodeUP podcast is excellent.