Node.js vs Rails vs Yesod





What is Node.js?


What is Rails?


What is Yesod?



Why do developers choose Node.js?
Why do developers choose Rails?
Why do developers choose Yesod?
What are the cons of using Node.js?
What are the cons of using Rails?
What are the cons of using Yesod?
    Be the first to leave a con
    What companies use Node.js?
    What companies use Rails?
    What companies use Yesod?
    What are some alternatives to Node.js, Rails, and Yesod?
    See all alternatives
    What tools integrate with Node.js?
    What tools integrate with Rails?
    What tools integrate with Yesod?
      No integrations found
      Decisions about Node.js, Rails, and Yesod
      No stack decisions found
      Interest over time
      Reviews of Node.js, Rails, and Yesod
      Avatar of mihaicracan
      Web Developer, Freelancer
      Review ofNode.jsNode.js

      I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here:

      How developers use Node.js, Rails, and Yesod
      Avatar of StackShare
      StackShare uses RailsRails

      The first live version of Leanstack was actually a WordPress site. There wasn’t a whole lot going on at first. We had static pages with static content that needed to be updated manually. Then came the concept of user-generated content and we made the switch to a full on Rails app in November of last year. Nick had a lot of experience with Rails so that made the decision pretty easy. But I had also played around with Rails previously and was comfortable working with it. I also knew I’d need to hire engineers with a lot more experience building web apps than I do, so I wanted to go with a language and framework other people would have experience with. Also, the sheer number of gems and tools available for Rails is pretty amazing (shout to RubyToolbox ).

      I don’t see us ever having to move away from Rails really, but I could be wrong. Leanstack was built in Rails 3. For StackShare we decided to upgrade to Rails 4. Biggest issue with that has been caching. DHH decided to remove the standard page and action caching in favor of key-based caching (source)[]. Probably a good thing from a framework-perspective. But pretty shitty to have to learn about that after testing out your new app and realizing nothing is cached anymore :( We’ll need to spend some more time implementing "Russian Doll Caching", but for now we’ve got a random mixture of fragment and action caching (usually one or the other) based on which pages are most popular.

      Avatar of Karma
      Karma uses RailsRails

      We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.

      It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.

      So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project.

      Avatar of MaxCDN
      MaxCDN uses Node.jsNode.js

      We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:

      • Go, the server-side language from Google
      • NodeJS, an asynchronous framework in Javascript

      We built prototypes in both languages, and decided on NodeJS:

      • NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
      • NodeJS acts as an HTTP-based service, so exposing the API was trivial

      Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.

      Avatar of Trello
      Trello uses Node.jsNode.js


      Avatar of AngeloR
      AngeloR uses Node.jsNode.js

      All backend code is done in node.js

      We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.

      We've written a few internal modules including a very simple api framework.

      I ended up picking Node.js because the game client is entirely in JavaScript as well. This choice made it a lot easier for developers to cross borders between being "client side" game developers and "server side" game developers. It also meant that the pool of knowledge/best practices is applicable almost across the company.

      Avatar of Tony Manso
      Tony Manso uses Node.jsNode.js

      Node.js is the foundation for the server. Using Express.js for serving up web content, and for synchronizing communications between all clients and the server, the entire game runs as Javascript in Node.js.

      I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.

      As for why I chose Node.js... I just love JavaScript! My code is all original, meaning that I didn't have to inherit anyone's bad Javascript. I'm perfectly capable of creating my own bad Javascript, thank you! Also, npm rocks!

      Avatar of Tarun Singh
      Tarun Singh uses Node.jsNode.js

      Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.

      Avatar of Instacart
      Instacart uses RailsRails

      Web has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.

      Avatar of Tim Lucas
      Tim Lucas uses RailsRails

      Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.

      Avatar of Ngakkan Nyaagu
      Ngakkan Nyaagu uses RailsRails

      For this project rails was ideal due to new features introduced in Rails 5 that allowed us to build a lightweight "API only" project. Developer familiarity and the ability to rapidly iterate, as well as providing an accessible testing framework were additional factors.

      How much does Node.js cost?
      How much does Rails cost?
      How much does Yesod cost?
      Pricing unavailable
      Pricing unavailable
      Pricing unavailable
      News about Yesod
      More news