Martini vs Node.js vs Rails

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Martini
Martini

14
18
+ 1
15
Node.js
Node.js

34.7K
28.6K
+ 1
7.9K
Rails
Rails

9.2K
5.8K
+ 1
5.3K

What is Martini?

Martini is a powerful package for quickly writing modular web applications/services in Golang.

What is Node.js?

Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

What is Rails?

Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose Martini?
Why do developers choose Node.js?
Why do developers choose Rails?

Sign up to add, upvote and see more prosMake informed product decisions

    Be the first to leave a con

    Sign up to add, upvote and see more consMake informed product decisions

    What companies use Martini?
    What companies use Node.js?
    What companies use Rails?

    Sign up to get full access to all the companiesMake informed product decisions

    What tools integrate with Martini?
    What tools integrate with Node.js?
    What tools integrate with Rails?

    Sign up to get full access to all the tool integrationsMake informed product decisions

    What are some alternatives to Martini, Node.js, and Rails?
    ASP.NET
    .NET is a developer platform made up of tools, programming languages, and libraries for building many different types of applications.
    Django
    Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.
    Laravel
    It is a web application framework with expressive, elegant syntax. It attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as authentication, routing, sessions, and caching.
    Android SDK
    Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment.
    Spring Boot
    Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run". We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
    See all alternatives
    Decisions about Martini, Node.js, and Rails
    No stack decisions found
    Interest over time
    Reviews of Martini, Node.js, and Rails
    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: https://medium.com/@mihaigeorge.c/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3

    How developers use Martini, Node.js, and Rails
    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)[http://edgeguides.rubyonrails.org/caching_with_rails.html#page-caching]. 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

    The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was h