Ask HN: Is Ruby on Rails still worth learning?
I'm looking to learn more about web software. I like the all in one approach of the Rails framework, but fear it may be losing popularity. Any thoughts? If you were to advise someone today what the best approach to learning web development would be, what direction/resource/book would you recommend?
86 comments
[ 5.7 ms ] story [ 249 ms ] thread- be very employable => JS/Express/[a-myriad-of-other-things]
- be able to do anything (including trending AI/ML) => Python/Django (you won't be as productive as with Ruby/Rails and won't the same happiness experience [in regards to web])
- be very productive in Web env & enojoy your time => Ruby on Rails
But that's not at all to say that learning Django or Python will get you a data science job; the underlying domain-specific data-science stuff is much harder to learn and qualify for than the Python is.
I'd recommend JS first if it weren't such a complicated world with so many options.
* Do you like to be able to build things fast?
* Do you prefer not having to reinvent the wheel?
* Do you care if it's not the new hotness?
If you answered no to any of those, run away! Rails is mature-ish. It's boring now. Its ecosystem is stable. Your sanity won't be tested.
Reads...
* Michael Hartl's Rails Tutorial is probably the book you'll want to read to get a simple grasp on Rails (it can be overwhelming).
* 99 Bootles, POODR (Sandi Metz)
* some RSpec book
* Finish it off with https://rebuilding-rails.com/
Didnt know about the book, so I'm interested, but I can't tell if it's worth buying because of the above.
I've been making screencasts for Rails developers at GoRails (https://gorails.com) showing how to build various features of websites in Rails.
If you're a beginner though, I would first recommend the Rails Tutorial - https://www.railstutorial.org/book
To address OP, Rails is now a boring tech and that's a good thing. I can move quickly and for every roadblock there's a community answer. It feels like React tutorials become obsolete after 4 months.
The answer that you will unconditionally see to this question will be "it depends"... I would get more specific with your question so that you can extract a bit of wisdom from the answers.
Rails is and has been a dominant web framework for the last ~10 years, dhh and the people working on it have crafted a wonderfully useful tool, with all sorts of lessons hidden inside the code. Ruby is a great language... and all of these things provide wonderful reasons to learn it.
With that being said, I don't use it anymore. and I'm not going to ever go back to it unless there something out of my control. ¯\_(ツ)_/¯
Do I recommend it? ... It depends
I'm mainly trying to do things with as little code as possible that are lightweight with almost no devops. Things like static site generators, Vue w/ Serverless Framework, Flask... which do have limitations... but they are tradeoffs that I'm comfortable with, and I know the work arounds.
At work for my last two W2/Employee gigs our main codebases were Laravel and Rails. Lots of advantages, but they come with tradeoffs.
My main recommendation is that you need to find what fits for your situation. Frameworks, IMO, are more than a set of technical choices they are cultures and shared sets of values. Which is why Rails didn't really fit for me. I'd argue that I'm a fair to mediocre developer... and I care more about the thing I am building rather that what I am building with. So I try my best to keep the code out of my way. JS kind of helps me do that because I don't need to flip my brain around so much between syntax, and it has arguably the most resources for getting over challenges. What I lose is speed (compared to Go, Java, C) and that I have to be really good at evaluating resources/ repos (Rails/ Laravel pretty much do this for you).
In particular with an EmberJS front-end if you like the EmberJS convention over configuration methodology.
It's very fast to first real web app request (not just a hello world response) and many of the concepts will translate to another platform.
When you're learning to find your feet with software engineering, I'd strongly recommend avoiding languages where the emphasis on everything being "magic". It doesn't help you learn how things actually work.
> teach... terrible habits imo
ActiveRecord and the Rails Controller/Model/Routing system are as good as anything in the serverside framework world. A few years back people might have started saying that AR was in danger of being obsoleted by "modern" databases, but SQL (and particularly Postgres) has come roaring back, and AR remains one of the best (arguably the best) SQL ORM.
At the same time, there's a lot of mechanism in Rails that is aimed at front-end work; templates, different template engines, helpers, the inscrutable asset pipeline. This stuff, not so much anymore. The energy you'd put into learning how to do idiomatic front-end in Rails, you should instead put into something like React (probably: into React).
People with a visceral "No" reaction to your question are probably thinking of what would happen if you started with a couple Rails books and tutorials and just went to town building a 2012-era idiomatic Rails application. Don't do that! But as an API server backend, Rails is fine, and does some things better than other platforms.
For whatever it's worth: we see a lot more Django today than Rails. 5 years ago, it was the opposite. People probably wouldn't recoil at the prospect of you doing an idiomatic Django application, even though it's not that much different than an idiomatic Rails application.
https://thinkster.io/tutorials/what-exactly-is-react
It's major criticism: there is a kernel of truth in the joke that React is a dressed-up PHP (in the sense of how you put the components together)
Some other options are Vue and Elm.
"If you're at all familiar with the history of React, there's actually some amount of truth to this. React grew out of an internal PHP extension at Facebook called XHP. See the recent post describing React's history at https://facebook.github.io/react/blog/2016/09/28/our-first-5... for more details."
"That said, the parallels only go so far. PHP is frequently rather unstructured, while React lends itself to some very specific structures. I don't think I'd necessarily say that PHP typically involves "recursively breaking down parts of the page". But sure, some similarities. (Then again, just about anything that involves template-ish work has some similarities... )"
This has basically all been replaced by Webpack so I’m not so sure
To me, that gives me pause about the viability of ORM as an approach more than it vouches for Rails. ActiveRecord has so many limitations and footguns that using it as a serious production framework is...well, doable, if you're willing to do a lot of the work that ActiveRecord claims to save you from.
If you're going to try to tell me that there's a countervailing trend of people meticulously writing their own SQL statements and record serialization logic, I'm going to say no, I haven't seen anything like that in our client base, or in blog posts, or anywhere else.
Incidentally, lest I come off as a Rails partisan: I don't use it anymore; the last thing I built with Rails (Microcorruption) was in 2013. But I sort of do miss ActiveRecord sometimes.
I'm just not actually sure what problem ActiveRecord actually solves. If you don't want to write SQL and you're willing to live with a certain degree of inconsistency in your data, that's what NoSQL is for. If you actually want the benefits of a SQL database, ActiveRecord makes the easy things easy and the difficult things impossible unless you just give up and write SQL, which you could have just done in the first place and wouldn't have actually been that much harder.
It's entirely possible that everyone does the same thing that I did when I worked on Rails apps: manually add all the DB constraints the ActiveRecord documentation tries to talk you out of, write my own error handling code for when these constraints threw exceptions that ActiveRecord had no idea how to handle, liberally call 'connection.execute' or 'find_by_sql' when nothing I wanted to do cleanly fit into the ActiveRecord query interface, and so on. It's also entirely possible that some ORMs other than ActiveRecord does a much better job at these things, but I'm taking you at your word that AR is the best.
Most queries in a typical web application are much easier with ActiveRecord, others with plain sql. A decent rails developer would know to use the right tool for the right situation. Throwing out all of ActiveRecord is throwing out the baby with the bathwater, in my opninion.
What is this even supposed to mean? Are you suggesting that ActiveRecord, a way to model the data in your database and layer behavior ontop, gives you as inconsistent data as "NoSQL"?
That may be the weirdest thing I've heard on HN.
> the difficult things impossible unless you just give up
Like what?
After reading the rest of your post I just think it's that you haven't used Rails since 2006.
I used Rails on a full-time basis between approximately 2011 and 2015.
> Like what?
Did you actually read the rest of my post? I explicitly covered that:
> ...manually add all the DB constraints the ActiveRecord documentation tries to talk you out of, write my own error handling code for when these constraints threw exceptions that ActiveRecord had no idea how to handle, liberally call 'connection.execute' or 'find_by_sql' when nothing I wanted to do cleanly fit into the ActiveRecord query interface...
And while I haven't used Rails since 2015, a quick check of the documentation reveals that the same basic limitations still exist, which I've written about before:
> OK, what if you want to generate the SQL dynamically with attributes? connection.execute doesn't do sanitization for you by itself (though you can call a private method to do that). If the generation is more complicated than that, you also have to have code to concatenate together strings of SQL code. Not because Rails doesn't have a SQL generation library, just because it's tightly coupled to ActiveRecord and fuck you and the horse you rode in on if that isn't good enough for you.
> I generally advocate for find_by_sql and select_all, but think about what that actually does. It instantiates a bunch of ActiveRecord objects that have to be of a particular model (what if the query joins tables together and returns a result set that doesn't actually neatly contain the intended columns of a given model? I can't even use ActiveRecord::Base.find_by_sql, I have to choose an actual ActiveRecord model arbitrarily), has the columns of the result set dynamically bound to it as methods during runtime (slow), also has the methods of the model itself bound to it, which may have unexpected behavior based on the query (especially if we just choose an arbitrary model), and in exchange we get to treat the result set as an array of structs rather than an array of hashes (which admittedly has its performance advantages, but not if the fields have to be dynamically bound to each object as methods!). Oh, and if you're writing an INSERT statement you have to use connection.execute after all. Have fun!
https://news.ycombinator.com/item?id=11750676
> The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say:
>> ...it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on both columns in your database.
> But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that.
> That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait time...
I’d love to hear an insider perspective from anyone who might have worked on those things.
Also there is always an ecosystem influence issue with choosing databases
The big ideas from any of the popular web frameworks (rails, django, express, etc) will be shared between the rest of them. It's really more of a question about which language do you want to use.
If you already had experience with web MVC, I would recommend something more exotic like elixir phoenix instead (1.4RC released today)
Honestly, I don't enjoy using the front end parts of Rails, and even on the back end side of things there's a lot of non-standard things that are good to do in order to make an actually scalable and long-lived app. But that doesn't mean it isn't worth using.
1. You will need to learn it anyways
2. It's powerful being able to use one language for both the front and back end. Context changes harm productivity.
3. Javascript & Typescript are the future and both are evolving really fast.
4. The Node.js ecosystem is already pretty mature with a lot of 3rd party libraries.
5. Performance is really good compared to languages like Ruby, Python, or PHP. For near the same simplicity and terseness, you get something with way better performance.
The only downside for beginners is that while the Nodejs world has a ton of libraries and frameworks, there isn't really a dominant framework similar to Rails that provides everything and the kitchen sink as well as a single 'right way' to do everything. The closest thing is Express, but it's really lacking; it's similar to Sinatra. Having to deal with a ton of possible choices and directions for development is just terrible for beginners, which is why Rails is still worth it to learn as your first framework.
Don’t panic about it “losing popularity.” Tools and techniques learned using one framework are pretty generally applicable to others.
I switched largely because of the applications I wanted to build were very 'Reactive' and message/event driven. Elixir being an Erlang/Actor-Model derivative with the expressiveness of Ruby was a perfect fit.
Elixir's ecosystem and community hasn't had as much time to develop as Ruby, but it's still very capable and you're not going to run into scalability problems.
If your goal is to skill up and get a job asap, maybe Elixir isn't ready yet, but I'd pick it over anything else to build a greenfield application in.
When you look for performance for microservices, Go or Scala are better. But that's when you are beyond the first 2 years and 25 developers and have the cash to invest
It's up to you, what I will say, is Rails is (in my opinion) the easiest to get started with and easiest to maintain.