Ask HN: Is Ruby on Rails still worth it? | Hacker News Reader

Ask HN: Is Ruby on Rails still worth it?

68 pointsahacker1576 comments

Yes. Rails has by now certainly crossed into boring software territory – arguably a [positive thing](http://mcfunley.com/choose-boring-technology) anyway – but it remains an excellent choice coming into 2018:

- Out of the box, Rails has close to unbeatable developer ergonomics, tooling, stability, and ease of use

- Lots of high quality, large companies use it (GitHub, Shopify, Airbnb, Square, Twitch) and have by now figured out how to scale it, often sharing and open sourcing their efforts, e.g. https://github.com/Shopify/identity_cache

- If your product front end is simple, Turbolinks can be an excellent choice (find me a faster, more bug free product than Basecamp)

- If you prefer to use a more modern JavaScript solution on the front end like Ember or React, Rails API is a perfect fit

- The Ruby ecosystem and community are both very high quality

Boring yet still very volatile.

I wonder if or when Rails will settle down and stop changing everything between major releases causing all documentation to be out of date, gems to break, developer habits to break, etc. Not to mention all of the related tooling like Bundler which seems to spit out new and uninteresting warnings and errors every time I update it.

It would be great to be able to write an application using a framework and not have to constantly change the application just to get long-term updates to the framework like bug fixes, security patches, compatibility with new versions of Ruby, etc.

Basically Rails-LTS but not from a 3rd-party (and embraced by the ecosystem).

Volatile in comparison to what exactly?

In comparison to Python, where things just work for years without being touched. Upgrading can get you a better api or performance for a specific workload but rarely will it be necessary.

Django. I'm not doing software these days but still following the news etc., and it seems to me that the general knowledge of the tool is still operable since very early releases. I'm not very familiar with Rails itself but when an environment changes very quickly it's both a big distraction and a great inconvenience. I've last worked with django around January 2014, today when I look at a Django app it's the same beast but a bit better. I was also interested in node in its first days, then about 0.12 I lost my interest. Each time I look at it it's a new thing. If Rails is more like node than Django, that's a problem for a beginner, as they'd rather spend time learning fundamentals of web dev rather than learning a breaking change every month.

The upgrades have progressively become much less painful. Rails 1 to 2 was a big deal, as the change introduced the RESTful API. Rails 3 was slightly less violent, but the asset pipeline was still a pretty big deal. Rails 4 had a lot of API cleanup/simplification. A lot of meta programming magic was removed in favor of simpler code, which resulted in some rewriting of existing code.

Rails 5 was the easiest upgrade yet. ActionCable was the big change, but it’s an addition to Rails, not a replacement for some existing tech. As a result, it doesn’t disturb much existing code.

This has been my experience. I've been working on a large Rails project that started on Rails 4 beta in ~2014. Since then it's been incredibly stable and the upgrade paths have been quite simple from 4.0 to 4.1, then 4.2 and now we're on 5.0 with a few minor updates left before moving to 5.1.

Everything would have worked fine if we didn't keep things up to date, but just about everything in the software world needs to be continuously updated due to security updates/patches, etc.

We just recently upgraded our large Rails app from Rails 5.0 to Rails 5.1. I wanted to come back to this discussion because I'm actually astonished how easy it was to upgrade. Our project has 1,156 Ruby files consisting of 55,396 lines of actual code (per cloc, rspec and app code). Want to guess how many lines had to be updated to upgrade to Rails 5.1? 24 or 0.04%.

Rails is quite stable.

I don't think people understand that boring tech is where most of the jobs are

Absolutely. If you're building a POC or MVP it's a quick and easy way to get something off the ground. The framework will take you pretty far before you have scaling issues (long enough to know if what you're making is worth it). The community is very knowledgeable and friendly, and gems for almost everything already exist.

If I needed to spin up a new project and get to work right away on something I'd go with rails no question. I've yet to find another language/framework combo that works as well as a Ruby & Rails stack (Laravel and Django are good alternatives too, I'm just more experienced with Ruby). Don't think too far ahead. Premature optimization or thinking about future scaling issues if starting a new project is time that could be spent better. Rails isn't going anywhere anytime soon.

Speaking for myself, and I tend to make practical choices for what I understand now. At the moment, I am not using Rails in my day to day work, and this is largely based on my past experiences.

Pros:

- easy enough to find libraries for most things I wanna do

- community likes testing, as do I

- community seems to focus on business & web implementations, so good for those use cases

- lots of questions for which I want answers already answered

- package management

- deployment to PaaS/Herorku-ish platforms pretty easy for smaller teams

- here in San Francisco, there are lots of job opportunities for Rails developers

- I like Ruby, even though I am less excited about OOP these days

Cons:

- Rails is magical & opinionated, and that always annoys me

- Figuring out where some method is coming from in a Rails object is often a pain

- In Elixir I almost never need a debugger, but in Ruby I almost always do

- loading Rails apps can get really slow, and learning to wait for software to boot isn't a skill I like to develop

- I feel more pressure "to do it" right when the time "to do it right" simply doesn't exist for reasons, because trying to come back and refactor gnarly Ruby code is just harder than it is in a compiled language

- Ruby has to be installed on the system to which an app is deployed, and needing to think about how to pre-install Ruby or how long a Ruby install takes is a mild pain (stand alone Go binaries or Elixir releases are pretty sweet)

I feel like figuring out where a method is coming from to be a routine source of tedium and a massive gumption trap when working on Ruby projects. This, along with bugs rooted in hidden state mutations, far overshadows the time saving conveniences in Ruby and Rails for me.

When I have creative freedom, I use Rails for routing, serving requests, and talking to the DB. I try to not to lean too heavily on Rails for business logic stuff.

Ruby on Rails is a great bet for those who need to kickstart fast. When Ruby/Rails becomes a performance bottleneck you're probably already making tens of millions and have dozens of people to diversify your tech stack.

Core team takes care of many things like webpack, ActiveStorage, etc for you, many thanks to folks. I've been doing Ruby on Rails since 0.19 as far as I remember and it's been great ever since.

Not that hyped anymore but who cares about hype when you get your shit done. Also as you grow, you appreciate talent availability when it comes to Ruby/Rails.

In my opinion, yes. I recently built a recent project in Rails 5 and it was rock solid. As your JS needs evolve or you want to start from scratch with a JS framework you can even use Webpacker to introduce Vue or React into your app easily and manage dependencies with Yarn.

This. Webpacker enormously improved the JS experience with Rails.

No.

Long time rails developer, but if you can green-light a project I'd highly recommend node all the way. I've found it much easier to comprehend a pure javascript stack (or even better an all-Typescript stack) due to substantially less cognitive overhead, find other people to work with (very important as your project scales), and the fact I can deploy node with a serverless implementation on Azure, GCP, and AWS makes it a home run when it comes to security and devops costs (and the need for devops in general).

While rails has a bunch of great features, those features (rightfully) have been copied elsewhere, e.g. Active Record, which has a fantastic javascript implementation - TypeORM.

Finally, when it comes to interface development, nothing in rails will get you as far as React these days, especially as the web moves mobile, and into AR/VR, which IMO present the next challenges of interface development. And like rails, nearly every question related to React/Node is answered on Stack Overflow or has a well-documented library to solve that use case.

> Finally, when it comes to interface development, nothing in rails will get you as far as React these days

Rails's out-of-the-box React integration [1] should get you _exactly_ as far as React these days.

[1] https://github.com/rails/webpacker#react

While this is interesting, you're proposing a monolithic repo with two predominant languages. I think it's much harder to get the benefits of riding the NPM wave while the front-end is stuck in a rails project such as using Typescript, React Native, etc. These are all possible of course, but there's a Rails Webpacker library that's an extra intermediary between the author and their JS code.

It seems like you're comparing a framework with a language?

What framework do you use on node.js?

My experience with nodejs has been pretty poor. I'll give some examples;

* The language and runtime is constantly updating - there is no such thing as stability

* Even npm couldn't produce deterministic installs until this year

* npm dependency hell

* there are lots of ways to do any task, so there is much fragmentation with advice / community

* the repls in node suck compared to pry

* I can't find a good opinionated framework - so everyone lays out each application differently, with different standards etc. That means you end up spending a ridiculous amount of time configuring everything.

* most apps i've needed to make don't actually benefit from being a SPA. It's a cargo cult thing.

* javascript as a language sucks!

This is exactly all the pain points I had with node. Left it about a year ago, Forever.

GraphQL and Express (wrapped with AWS Lambda's express handler for deploys)

To answer your points:

* You're right it hasn't been - but it is now with LTS releases of Node.

* I agree, this is why I use yarn.

* Yarn has solved any dependency issues I've witnessed.

* While this is true, every solution boils down to simple objects or simple functions. New solutions tend to be simpler than the status quo (e.g. redux)

* While debugging isn't as easy - all my back-end code boils down to simple functions which just need a simple test (I use mocha which is a lot like RSpec). Also Typescript and TSLint enforce types and code styling so I don't really need the pry-style debugging.

* The only configuration I feel you need is Typescript and TSLint which will enforce a very specific way of styling code, file naming conventions and so much more. From there my individual functions representing GraphQL mutations and queries on the back-end or React components on the front-end are small, modular, and encapsulated in a folder to make for an easy `cp -vr`.

* You're only talking about web. React Native/VR are extremely compelling reasons to expand beyond just the browser. Plus I feel separation of front/back-end makes for faster product development on bigger teams.

* Haha yes, though ES2015 made it a lot better and Typescript has made it complete IMO. Microsoft and Google have both made substantial investments into the language, with the former making it as big of a center-point as C#. That's saying something. You can code Typescript code on a cheaper and faster Windows machine, ruby? much more difficult.

I've yet to find anything that comes close to Rails in programmer productivity for the web. So, as long as programmer productivity is a concern, it's relevant.

EDIT: On the other hand, I wouldn't choose Rails for a project where the main concern is performance/scalability

Try ASP.NET. It’s managed to take learn most of the lessons (what to avoid and what to replicate) from RoR and is built around a better language (C# or others of your choice) and environment (Visual Studio and MSDN) to boot.

Now that .NET with .NET Core is officially a first-class citizen on Linux, there really no good reason not to embrace it.

Except that Visual Studio 2017 is a dog, especially on Windows 10.

I'm not Rubyist, but when I see an article about RoR it's one of these:

"I just started using Ruby and omg it's out-of-box everything, rapid development, monkeypatching makes everything super easy, it's like second Jesus coming."

and the second category is this:

"I am working with RoR for years, maintaining/migrating anything is super painful, because everyone is monkeypatching everything, so you cant safely touch anything."

Choose wisely.

Maybe this says something about the article writers?

Most Rails applications I see have minimal monkeypatching and I can’t remember the last time I had to debug an issue related to one. On the contrary, monkeypatching is most often used to fix issues in libraries that would otherwise require forking or pushing changes upstream to the project to fix. For example, Rails 3.2 is missing a few time duration methods from Rails 4 which Ruby 2.4 relies on so you need to add those via monkeypatch to run Ruby 2.4 with the legacy Rails version if you can’t upgrade everything at once.

The second category there is typically people who adopted Rails and then ignored it's culture of testing. One thing about Ruby is that you better have good test coverage if you ever want to be able to safely upgrade your dependencies.

From someone who doesn't use Rails day-to-day: It's still about as relevant as it used to be before, for the same reasons it was relevant then.

In summary: If you need to get shit done fast, it's a good bet.

It isn't as hyped as it used to be 5 or so years ago, and if hype cycles are relevant to you, you likely already know your answer.

As to whether you are asking whether learning it would make you unemployable, by no means. RoR is still going strong, at least in my country.

Yes, Rails helps developers make good upfront choices to the structuring of their application and database. The DB layer and structure is going to be a bottleneck well before the programming framework is (I think this is true in any framework). I enjoy that Rails makes it easy to do things like take care of N+1 queries, do associations correctly, etc. That isn't exclusive to Rails, but it is really good in Rails.

I think Rails helps developers make ok choices to the structuring of their application, particular if it's serving a domain that models easily into a fairly conventional RESTish-API relational data structure. The strongly-held conventions (in both framework and community) that position it so well for upfront productivity don't leave a ton of space for taking a proactive approach to managing complexity in a trickier domain.

Smart, experienced people can of course identify where the framework leaves off and build within the confines of Rails to get things done. But I wouldn't say that Rails makes it particularly easy to, for example, use a object-oriented approach the the model layer. ActiveRecord, with its lovely but dangerous APIs, really wants to be your everything class. Domain namespacing, while doable (you can do anything in Ruby), isn't particularly intuitive compared to other parts of the framework.

None of this is to say that Rails is a bad tool and I'm grateful for what it's provided (thank you OSS maintainers). It does, however, trade medium-term maintainability for the up-front productivity it offers, which could be totally fine, but for me doesn't feel like a great trade.

A tool in the hands of an expert will be used differently than a non expert. The model layer that AR suggests might not be good for an expert, but it will certainly help a non expert build their app for some time without too severe of issues.

You are right that it's far from perfect and it really is a "be everything" ORM.

Yes! The Rails core is quite stable and the community continues to innovate. I've recently gotten very involved with Devise Token Auth, an open source project that helps you use Devise on apps that do auth on the client side, like those written in Vue and React. We're on the hunt for new contributors: https://github.com/lynndylanhurley/devise_token_auth

Yes. I have used rails since about 0.6 and evaluated other frameworks since. Nothing comes close for me, especially for CRUD apps. For anything complicated (50+ models), things can begin to feel unwieldy but it helps to be disciplined about how you structure your code. I find trailblazer very useful in that regard.

I've recently started to learn vue.js and it's making JavaScript a pleasure to use alongside rails. I think my future projects will be vue + rails by default

It depends on whether or not you are on the React bandwagon. Yes Rails does work with React - but this means two different asset pipelines (Rails and React/Node).

If I was building a product focused stack, then I would simply do React+ Typescript. Why bother bringing in two different languages for front end and backend ?

Typescript is pretty awesome in itself.

Pretty sure that this Quora answer from DHH is still valid in 2018: https://www.quora.com/What-makes-Rails-a-framework-worth-lea...

It’s so fast to spin up, deploy, and iterate on a rails app it’s insane.

As stated, it depends on your context and your goals, but if speed matters to you, it’s hard to say rails is not a top solution.

Wouldn't Python/Django make more sense in 2018 considering that Python could be used for data science and machine learning? I realize this is a Python vs Ruby question, but if you didn't know either Python or Ruby and were trying to pick between Django and Rails for a project, wouldn't you pick Django in 2018 due to future data science and machine learning opportunities?

Merely knowing python does not a data scientist make.

Of course, but wouldn't one be better preparing themselves for data science by working with python/django on a web app vs working with Ruby/Rails?

I think knowing python is just a small part. So yes, it would help, just not enough for it to matter (unless you know up front that you want to do these things).

No. Learning Python is quick and simple compared to learning data science or machine learning.

Knowing Python and Django (which I do) does not afford you any ability do to those things.

Interesting. I assumed that spending more time working with Python would be beneficial, but I guess it's not a big deal. This is great to know, as I've been resistant to starting with Ruby/Rails for the reason I described. Thanks!

I don’t do machine learning or data science, so I’m assuming here, but I would imagine whatever you end up doing would be en entirely different service than your web stack and could be whatever language you wanted.

Learning Ruby would give you a big leg up over starting from scratch learning Python.

I don't know if you are familiar with any programming languages at all, but many skills translate cross-language...the paradigms are the same. Particularly with Ruby & Python which are very similar languages. They're good at the same things, by and large.

Taking your Ruby skills over to Python will be a matter of "google: [python thing] in ruby".

For a specific example, Python has a unique thing called "list comprehensions". Using that google string you can get some great ideas about replicating that functionality in Ruby.

Anyway, on a grander scale, picking up new languages is the easy part of programming--even when they're not so similar.

Best of luck!

Picking the basics or just enough python shouldn't take long(a couple of days?) for a intermediate programmer.

Still one of the best, if not best, choices for building a CRUD web app. I don't see this changing any time soon.

The simple answer is it probably depends on what you’re doing and what you’re optimizing for.

I don’t know of a better way to get an MVP project up quickly. Rails at scale is probably a touch harder to manage, but that’s by no means impossible.

I'm of the opinion of using the best tool for the job. If you need an MVP fat then use Rails but if not evaluate other options. Please your need may come from what you know best.

Yes. It's still a very good framework for simple Web Apps. It's takes care of a lot of boilerplate.

With Rails 5, it's good for a simple API backend as well. And there are a ton of gems that can alleviate a lot of pain.

It's when something non trivial where Rails may not be a good choice.

No.

If you already know Rails, yes.

If you are thinking about learning Rails now, probably not.

Yes Rails is great for MVPs, but then so are a lot of other things, like Meteor.

What would you suggest if you don't know rails?

I would suggest Elixir/Phoenix if your priority is maintaining and scaling a business application. I would offer that suggestion with caution, though, if you're considering building a core skill set for employability today. A small contingent of the experienced Ruby community have become fervent Elixir evangelists, but the number of successful projects, jobs and skilled candidates is a miniscule fraction of Ruby and other mainstream choices.

Yes, here in London Elixir jobs are still very thin on the ground. I don't see Elixir moving beyond its current position in the job market. It has everything - great concurrency, Phoenix - except mindshare and adoption. In another era, with less competition I would have bet on Elixir but not today.

Would you still recommend Rails if the person has absolutely zero Ruby/Javascript knowledge (but functioning HTML/CSS)?

There’s nothing wrong with Rails in 2018. It’s maybe not the most forward-looking choice you could make but it’ll get you running quickly.

But if you have a smart team and a little bit of time for ramping up then I’d suggest Elixir+Phoenix or Node tbh.

Rails is good at what it’s designed to be - a one stop shop for fast to develop, kinda dirty, framework magic, webdev.

And there is nothing wrong with that.

Node with which framework? By itself it's not comparable to Rails.

True! Though I actually think that’s a good thing (imo too much magic & abstraction in a framework leads to bad app design because too much is hidden).

But that sort of reinforces the point I was making tbh. Want something that makes all those choice for you? Right or wrong? Rails.

Nothing wrong with that as such, but it will cause issues eventually.

Could you please not post unsubstantive comments to HN? We're trying for a higher standard here.

If you'd take a look at https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html and follow the spirit of the site, we'd appreciate it.

No. What does rails have that a different python framework doesn't have?

And you'll save yourself the tears of migrating later.

Why would you need to migrate to Python later? I can understand needing to migrate to something more performant/easy to scale, but Python doesn't have any advantage on Ruby in that department.

Not migrate to python, migration away from Rails. I'm suggesting Python as an alternative to Rails to start with.

You still didn't answer why would I want to migrate away from Rails. Python has no advantage I can think of (unless one has to work with data analysis).

My experience is admittedly tainted because we migrated away from a Rails codebase and it was not fun. The Rails code was extremely convoluted and encourages metaprogramming in a way that is very un-typed.

Basically, I think Rails is inferior because it encourages bad practices, has no distinct advantages over Python, Python seems to have a larger talent pool, and Python has uses outside of Rails that make it a better choice for a one-language shop (i.e., your tools can be in the same language as your code and can utilize that + Python is everywhere, Ruby has extra devops costs incurred).

I won't say you can't be successful with Ruby. That'd be silly. But do I think there is a reason to choose Rails over Python if you can start fresh? Nope.

Much of what you learn in Ruby and Rails is not portable to other languages. Ruby and Rails are deeply flawed and much of what you learn is dealing with those flaws. Similar to learning PHP for example (but differently flawed than PHP). Ruby is also showing its age and is lagging behind modern languages.

Rails is probably fine and fast and good for small projects. It is probably not good for professional large projects.

You should let AirBnb and GitHub know.

Oh, believe me, they know

Hahaha

There should be a Hacker News MadLibs form:

UserOne: Don't use [insert language] and [insert framework] because [bad design flaw] and doesn't scale.

UserTwo: But [BigCo with millions of users].

What web dev languages/frameworks aren’t deeply flawed and teach you more portable skills?

Unfortunately I would say Javascript. Unlike Ruby, you will learn about compilers, static analysis, linting (eslint is more useful than rubocop), type systems, function composition, and have a good alternative to OO based programing built into the language (as opposed to your `UnboundMethod` lambda block proc whateverthehell design flaw Ruby has now). Javascript also gives you decent jumping off points into languages you will learn more from (Elm, Purescript).

Many of the popular web frameworks like Django and Elixir have a lot in common with Rails with regards to typing and compilation or lack thereof.

Function composition and partial function application is totally supported in Ruby so not sure what your complaint is there. Here is one rather forced example: http://genua.github.io/ruby/2015/03/17/ruby-function-composi...

I don’t know anything about Elm and Purescript but I’ll look into them. They aren’t hugely popular (as far as I know, feel free to correct me) so I’m not sure that’s a major win for portable skills versus Ruby engineers learning Scala or Python. If you don’t get too wild with the symbols, Scala can actually look quite familiar to Ruby programmers. Twitter had people use a subset of Scala when they transitioned many services from Ruby to Scala so that it would be an extra easy transition.

JavaScript has come a long way though and is certainly the lingua franca of the Internet.

    pp_proc = self.method("pretty_print_me").to_proc

Exactly :(

I did say it was a forced example ;)

Even assuming you implemented it their way, their code isn't very concise. In the snippet you pasted, "self.method" could be replaced with "method" for example without changing anything

Reply on news.ycombinator.com