Rails vs Ruby: What are the differences?
Developers describe Rails as "Web development that doesn't hurt". Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. On the other hand, Ruby is detailed as "A dynamic, interpreted, open source programming language with a focus on simplicity and productivity". Ruby is a language of careful balance. Its creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming.
Rails can be classified as a tool in the "Frameworks (Full Stack)" category, while Ruby is grouped under "Languages".
"Rapid development", "Great gems" and "Great community" are the key factors why developers consider Rails; whereas "Programme friendly", "Quick to develop" and "Great community" are the primary reasons why Ruby is favored.
Rails and Ruby are both open source tools. Rails with 43.6K GitHub stars and 17.5K forks on GitHub appears to be more popular than Ruby with 15.9K GitHub stars and 4.26K GitHub forks.
According to the StackShare community, Ruby has a broader approval, being mentioned in 2531 company stacks & 1143 developers stacks; compared to Rails, which is listed in 2322 company stacks and 798 developer stacks.
Currently working on my company's new saas, the main goal is to manage content and user. I'm familiar with the rails framework and how it is easy to code and deploy. The thing is I'm the only dev on the project, and in terms of the tech stack, there is no preference. However, because Node.js is everywhere and there is enough dev on the market, I am stuck between choosing Rails or Node.js. I don't mind implementing Vue.js or React on the frontend, but I need a solid argument to explain to people that aren't necessarily tech-savvy as to why we should choose Rails over Nodejs.
I'd use the following metaphor to non-technical people. Rails is like a prepackaged toolkit, which can get most of the common tasks done fairly with ease. Whereas, node.js with whatever backend framekwork of choice, is like a DIY toolkit assembled by mix-and-match different tools in a large tool shop. Of course, at times DIY toolkit can do better on specific tasks. Given that you are the only dev on the project, I'd assume that the resource is fairly limited. And looks like you are not building some next-gen super duper fast smart application. So Just go with the prepackaged toolkit then. Rails is a very opinionated framework, there're pros and cons to it. But thanks to that, many of the gems are coded with it in mind. For example, they are all designed with same naming convention. Many will work well together out-of-box, for example devise and cancancan. Besides, many stuff are built in the framework. For example, logging utility, csrf protection, session encryption, etc. Yes, many of those stuff may not be useful or necessary at the beginning of the project life-cycle. However, down the road, there is a good chance you will need some of those. And the moment you realize that you already have it, it's so delightful. In addition, it's usually easier to debug a rails app than a node app in my experience. Personally, the cases where I would pick node.js over rails would be projects either require a) high-performance, or b) certain core functionality that has been implemented by some node packages but not by any ruby gems. In term of performance, node has a clear advantage over any other major web frameworks, except the ones built with go. It's simply a language feature. Node allows developer to easily write code that runs db query, external api calls, or other stuff of that nature in parallel. And that is THE MOST COMMON performance bottleneck of web applications.
Rails is currently a very mature and feature complete framework.
It's the ideal one if you're the only dev for your project because you get so many things already baked-in the framework that you'd only need to deeply care about specific stuff.
And you know? In the early stages of any project we have to validate it first with real users/customers. With Rails you can get to production real quick and fast.
I'm going to mention some of the features you get from day 1 when you run
rails new app_name:
- File uploading with Active Storage
- Rich text editor with Action Text
- Emailing with Action Mailer
- ORM, migrations, validations with Active Record
- Web sockets with Action Cable
- Modern frontend stuff with Webpacker
I suggest you to go with Rails because is a good choice, gives you less things to worry about and it's a very good and mature framework.
I hate to admit it, because I loved my time with Rails (and I still love the framework), I have a hard time justifying new Rails applications these days. Core team has made some tragic design decisions, and developers just don't perceive it as being "cool" any more. The latter is a terrible metric for which to base a technology decision, but I think you'll find it more difficult to recruit additional engineers if you choose Ruby on Rails.
Without knowing too much of the details, Node/Express (ideally with Typescript) seems like a better solution here, given you'll be building out the front-end in Vue or React. It might be worth looking at NestJS, as it's the closest I've seen to a well-formed opinionated framework on the Node side of things. We're also fans of Objection ORM.
I hope that's helpful!
I need a solid argument to explain to people that aren't necessarily tech-savvy as to why we should choose Rails over Nodejs
Hi Max, it sounds like that you are proficient in both stacks and probably have a higher expertise in Rails (correct me if I am wrong) and since you are the only dev on a project, a good argument that comes to mind is probably the velocity and maturity (enterprise grade, battle tested in production) that Rails provide with proven success stories in the tech industry such as Airbnb, Stripes, Shopify to name a few. You can also make the argument that Rails is great to run the backend and React+Vue (and nodejs for tooling) is ideal for the front-end development (see or find companies example that use both). You can also build and show a prototype using both and share your experience which could help you find and forge the selling points to those non tech savvy folks, why not.
Eventually, are you going to have other developers on your project? if yes then you will need to take in account, onboarding and ramp up to contribution time when they are hired.
IMHO, I am not a fan of the debate Rails vs Nodejs, they are just tools at the disposal of the developer it's just a matter of figuring out what makes the most sense.
Let me know if you wanna discuss further, happy to help out!
ps: markdown preview on stack share... no good.
Hi Community! Trust everyone is keeping safe. I am exploring the idea of building a #Neobank (App) with end-to-end banking capabilities. In the process of exploring this space, I have come across multiple Apps (N26, Revolut, Monese, etc) and explored their stacks in detail. The confusion remains to be the Backend Tech to be used?
What would you go with considering all of the languages such as Node.js Java Rails Python are suggested by some person or the other. As a general trend, I have noticed the usage of Node with React on the front or Node with a combination of Kotlin and Swift. Please suggest what would be the right approach!
Use the language which works well for the developers you have or have available. If you're starting, building a first iteration is far more important than worrying about what language might be best to solve a problem you may never have.
When hiring, look for developers, not "node developers" or "java developers" having people who recognise and are willing to adapt means you can have the flexibility you will need to solve as-yet unforeseen issues. Hire people who are wed to a specific language and you will be bound to that language, regardless of whether it's most appropriate or not.
You can checkout this link :- https://softwarebrothers.co/blog/companies-that-use-node-js/
Since it's a banking app, I'd advice you go with Python for the backend because of the data analysis you'd be doing in your app. I see you doing some data analysis since it's a banking app. Python is a powerful language for data analysis. And for web, yes I'd advice Node with React, and for mobile, Node with a combination of Kotlin and Swift. Don't even try going hybrid for this kind of application. It's best going native.
As others mentioned, the problem domain is around data. From my experience, data means strongly typed entities. It might be good however to start off with a dynamic language such as Python (with Django) just to build a prototype, but once the models have been proved to be valid I'd go with statically typed language such as java/Go (I prefer Go but that's a whole different conversation) as you get compile time guarantees for type safety.
An alternative (or addition) to all of the above is the use of 'strong protocols', such as Protocol Buffers, Avro, Thrift and the likes. In this case you get type safety and stability between communicating backend services, while deciding and changing on whatever backend service language you want. That goes to say that your problem is not related to programming language decision but to a much profound understanding of what's important for the business to be created and be valuable.
As a general note, I don't think you should go, if you've got commercial aspirations, with any language that you'd have hard recruiting people who actually know what their doing. In Israel it would mean take Kotlin out of the equation
The reason why companies are switching to nodeJS is because it unifies all development under a single language.
If you are a one man team you can start developing anywhere on the stack without the overhead of switching languages at each layer. If you have a large team, your DBAs, your core service team, your application team can all read each others code.
You should not go with react,kotlin and swift those are very colourful languages but java ,node.js etc are colourful yet they have depth. You should only go with kotlin if you want to use android studio it is highly compatible. So its your choice . May you choose the best
12 Ruby Gems We use at SourceLevel and Why:Text Handling & Formatting
We are heavy Markdown users! We produce internal documentation in Markdown. The docs page is a static site entirely written in it (and built with
In the main app, we use
markerb to parse markdown content and convert it to HTML. Comments to Github, issue explanations and repository badges are examples of markdown usage. Although its repository is archived and doesn’t accept contributions anymore, it does a pretty good job. It works with both
redcarpet. We chose
redcapet as our processor.
Another useful gem is
charlock_holmes. As accurate as Sir Arthur’s character Sherlock Holmes, this gem detects character encoding for given files or chunks of text. Under the hood,
charlock_holmes benefits from the set of libraries from ICU.
We love PostgreSQL! It is reliable, open-source and has lots of functionalities that make it attractive. The ability to create materialized views is one of them.
Working with views in
Rails is kind of messy. That’s why we added
scenic to the SourceLevel main app. This gem adds methods to
ActiveRecord::Migration that allow managing views in migrations.
We use materialized views to scope content. If you don’t know what it is, here it goes: it’s a SQL query whose results work as stored in a regular table. Long-running queries or segmented results can be fetched from appropriate views reducing both time and code complexity.
pghero gem, besides the ability to kill them if you need, also ships with a UI for you to monitor other performance indicators.
Another essential dependency is
dalli. It does an incredibly good job of storing and retrieving memcached records. It’s thread-safe and allows us to run
Rails.cache smoothly throughout the codebase.
Read more in our blog post :)
In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.
To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.
Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.
That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.
We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.
As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.
I have used both the tools . Both of them are super awesome , very reliable and their learning curve is also super easy. But, the reason I choose Ruby on Rails over Django is the fact that the dependency injection is super easy in Rails than Django. What I mean is the fact that, Django requires a lot of import statement to do a lot of work, which remembering is not so easy and even after that you may need to write a lot of code. But Ruby on Rails uses gem to add addition feature or dependency in the project. Which requires just copying the gem statement from github and pasting it in the Gemfile, then running bundle install(these days just bundle works super fine). And there you are with the new feature in your app. You can see this with the example of Authentication, where in Django you require several steps like adding class based views and many more, but in rails it's just as easy as installing the 'devise' gem . And if you want to make it beautiful use bootstrap_template gem to make it look prettier. Now with Rails 6 , Rails is a total developer's fervent friend because it has come up with features like Action Mail and Action Text.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Rails?
What is Ruby?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
I started with a CodeAcademy course before working on my first Rails project. The language is easy to read and Rails is an amazing framework. The online community is fantastic, the documentation is amazing, and there is no shortage of Ruby Gems which allows you to quickly "cobble" together a new project.
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.
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.
Only thing worth noting here is that we saw some major issues with memory swapping on Heroku with Ruby 2.1.2. We weren’t the only ones. So we actually reverted back to 2.0.0. Here’s what happened: . We’re planning to upgrade to 2.1.4 once we’ve had time to test thoroughly.
When we are comparing Turing complete languages it's not about what compiles faster or to the cleanest machine code, it's about what the developer can think in and write faster, including the availability of libraries. A couple of times I wrote some ruby scripts for this project. I just like the language best for some things. Love the syntax.
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.
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.
We are primarily a Ruby shop; our main apps are running on Ruby + Rails, our Slack bot is written in Ruby and our smaller projects are on Sinatra. It makes it really easy for us to re-use code and switch between different projects since they are all on the same language.
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.
Because happiness. Testing via RSpec (mostly model and request specs), Factory Girl for fixtures, VCR for testing API responses, timecop, Redcarpet for Markdown rendering, Intercom gem for posting events.