Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Is Ruby on Rails still worth learning?
123 points by bizkitgto on Oct 15, 2018 | hide | past | favorite | 85 comments
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?

The answer is probably that parts of Rails are worth knowing, and other parts aren't.

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.

Worth noting that webpack (via the webpacker gem) is supported in Rails 5.2, and will be default in Rails 6; using that gets you access to current versions of React, Redux, and pretty much anything else packaged as npm modules. You still need some kind of view layer to serve up the pages that invoke the JS, but if what you're doing is a single-page app that's almost all React, then that view layer doesn't actually have to do very much.

I wonder why Rails 6 doesn't go all in on Webpack and drop Sprockets.

the inscrutable asset pipeline

This has basically all been replaced by Webpack so I’m not so sure

> 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.

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.

People have been saying this about ORMs since the original Rails Blog Demo introduced ActiveRecord, but I don't think we even have to engage with the argument, because no industry trend has made ORMs less relevant; instead, the sort-of collapse of the NoSQL trend has, if anything, made them more relevant. If AR was useful 5 years ago, it's useful now.

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 can't speak to the broader state of the industry as you can. I don't know what the trends are.

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.

> 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.

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.

Unless something has changed to make this discussion interesting, we're really just recapitulating a decade's worth of ORM debates people can just look up in the search bar below.

> you're willing to live with a certain degree of inconsistency in your data, that's what NoSQL is for

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.

> 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!


> 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 timeouts, etc. into generic, application-intelligible exception classes.

> ...

> In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?".

> What I would do, given Rails' existing framework of "programmatically discover the table schema and magically generate logic from it", is set it up so that it observes uniqueness constraints and programmatically adds the validation when found. Also, the adapters should interpret server error messages, throw a custom exception class for "uniqueness constraint failed", and ActiveRecord should catch this exception class and turn it into a failed validation when you attempt to save a record.

> If that's too much work, just be fucking honest, remove the uniqueness validation (because it's completely useless), and be upfront with us that we have to roll our own solution for it.


What's your view on ORM's like Ecto (for Elixir) and possibly Sequel that, from my impression so far, stick closer to the underlying SQL? I find myself generally agreeing with your view on things, but my impression of ActiveRecord has somehow become relatively negative. I don't know enough to know what to think, so I'm curious how you see ActiveRecord in relation to the alternatives.

Minor nit: ORMs and associated pain go back at least as far as Smalltalk (Objectivity/DB from 1990), pretty much before the rest of the world discovered OO. There was a lot of energy put into OO databases, to little avail.

I always wondered what really happened to OO databases. They were supposed to be the future... 20 years ago. And then MySQL exploded and everyone went back to tables. What was the problem: speed, difficulty, price, all of the above...?

I’d love to hear an insider perspective from anyone who might have worked on those things.

We ran some benchmarks and didn’t see a lot of speed.

Also there is always an ecosystem influence issue with choosing databases

Why React over rails front-end? It seems like it adds undue complication. What’s the real benefit? Basecamp works great and it’s a rails front end. Rails make full stack development pretty easy.

You can have the best of both worlds and use webpacker to mix React or VueJS into the Rails frontend where it makes sense, eg complex forms or widgets. Many webapps are not Facebookish and don't need to be SPA blobs, with all the additional complexity, SEO and accessibility costs.

It really depends on the application. If you're making something that has a highly interactive UI, then React is a great tool for that. It doesn't have to be all or nothing though, you can use Rails server side rendering with React components for the complicated stuff. Basecamp is not a fair comparison, they use Stimulus which is their own frontend framework.

React buys you two things: (1) reusable components (2) React Native


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.

It's been a long time since I wrote or even had to look at PHP, but I have done work in PHP. I use React constantly. I do not see any similarities between the two, like, at all.

Yeah, I was shocked when I first heard of it. But when I thought it about it, it makes sense: https://www.reddit.com/r/reactjs/comments/58wmnz/so_reactjs_...

Here's another comment from that reddit thread:

"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... )"

That blog post section describes JSX, not React. JSX is just a notation.

I started learning Ruby/Rails early last year. After building a couple projects in Rails for some clients, I switched to learning Elixir/Phoenix instead. Rails has a lot of magic and implicit behavior you need to learn to use effectively. I still love Ruby; the ecosystem is very mature and stable and the language is just so damn expressive.

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.

If you want to

- 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

How does working with Django translate to being able to work in ML? Merely due to Tensorflow having a python interface?

It's a running joke at my company (we consult for startups) that no matter what stack they build on, they'll always have a small team of people writing in Python for data science. Which is presumably where that's coming from. It is indeed a sort of de facto standard.

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.

Probably fair to express that more broadly as Data Science instead of just AI/ML. Libraries like Pandas and Numpy are used all over the place, as well as Python being a relatively straightforward tool for doing data munging tasks.

As far as learning/investing in a specific language learning python while doing Django would avoid needing to learn python later, but Django it self wouldn't make you better at AI/ML.

Pretty much. I almost always advise Python to learn "programming" and then moving to javascript to get a job cause above is pretty accurate.

I'd recommend JS first if it weren't such a complicated world with so many options.

Usual personal opinion caveats

Ok, simply rails is a tool. It is a well worn tool. Can do a lot of things and a lot of people know how to use it. Learning how to use it has been done many many times before so the path to competence is really smooth and straight forward.

I think it is worth learning because: 1) the community, you would be hard pressed to find a more diverse, welcoming, non-neck beard programming community. 2) resources, there are a lot of them. You will not encounter a problem that someone hasn’t solved for 3) fun, ruby is really nice and doesn’t fight you. Some features are debatable (meta programming, everything is an object, it’s GIL implementation etc) and I think all dynamic languages downsides are most noticeable in large code bases. But for your stated use case it’s great.

I strongly recommend the hartle rails tutorial. I convinced a friend to drop out of his math PhD and go through it. Do I think he will stay a rails programmer? No, but picking up python is a cinch after rails and there is no equivalently good python tutorial for teaching technical fluency in web dev that I am aware of.

Best of luck!!

Rails is a good framework and Ruby is a great language. I still use both. However, given limited time, I would advise someone new to learn Javascript / Typescript & a framework based on that instead. Why?

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.

Yes, of course it's still worth learning. Whether you learn Rails, Django, or anything else, the concepts will apply pretty well for any web framework.

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

I mean, learning X is an opportunity cost. Not dismissing your answer, but I guess we could rephrase the question: "Is Rails worth learning instead of X", where X can be some other popular frameworks. Or said differently, both for newcomers or more experienced devs, why do you think Rails is worth learning instead of some other web framework?

Rails influenced some other popular web frameworks, and I feel it’s still faster to build some types of web apps in Rails. I’d think you could cover more concepts sooner and then translate what you’ve learned to other frameworks as you need them.

I'm sure your stuff is great, and I'll happily give a look or two... but you are openly advertising your stuff without really answering the OP.

Thanks so much for your screencasts. I'm cooking up a MVP in Rails on a really tight timeframe and they've been invaluable.

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.

I was just talking about this with my co-workers. Rails has so much built in and has been refactored and cleaned up so many times that, if you are just trying to build a web application with a reasonable authentication system, it's a great platform to know.

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.

I'm always surprised I like Rails. It's my guilty pleasure. I find languages like Elm, Racket, and Elixir to be much more sane and exciting than ruby. And I find the design of frameworks like Phoenix and Yesod to be very elegant when compared with Rails. And at least in theory, I like the idea of composing a bunch of libraries together into an app rather than using a big 800 pound gorilla framework like Rails.

But in practice, I'm more productive will Rails than anything else. I've spent most of my time the past few years with other languages and frameworks, but I'm still more productive with Rails than anything else when making webapps.

Of course, there is a lot of understandable excitement these days around SPA tech like React, which you should probably use on the frontend. Just set Rails to API mode. The productivity of Rails is all of the useful backend features that have been packed in. Out of the box, you have database integration, migrations, data validation tools, email sending, web sockets, background jobs, file uploads, and a dozen other features, all wrapped up in a simple architecture. Simple to integrate gems can add pretty much any feature you need, like authentication, graphql, or search. On top of that, the wealth of documentation and example code is really incredible.

And since Rails projects all have the same core and architecture, most knowledge you gain on one Rails project is transferable to any other rails project. I wish I could say the same for my work in React projects, for example. React projects often use dozens of other libraries, and each project requires me to learn that project's unique set of libraries, their architectural decisions and so on.

If you want to get hired right now? Learn React, redux, and friends. But if you want to MVP a project and need something for the backend, Rails all the way.


* 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.


* 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/

Is "rebuilding rails" still relevant? The website has a 2010-ish design vibe and it seems to talk about rails 3 being cutting age while we're now at rails 5. One image has (c) 2012.

Didnt know about the book, so I'm interested, but I can't tell if it's worth buying because of the above.

It's very much still relevant. It won't give you very low-level details but it'll explain a lot of the metaprogramming (others call it magic) that Rails has.

Your third question should be inverted: if you do care that it's not the new hotness, run away. I think you meant something like "Is it okay that it's not the new hotness?"

Thanks for the recommendations!

Yes, absolutely. It's a very mature and productive framework with a vibrant community built up around it. It integrates with webpack so you can have whatever frontend you like. There's plenty of work. Performance and scalability are big focuses for the future Ruby and Rails, respectively, which covers most people's gripes.

It never hurts to know a few tools, but at the end of the day if you need to crank out a webserver Rails is top notch.

I'd definitely say no. Going from little knowledge straight into Rails teaches terrible habits imo, and indeed it doesn't tend to be used for new projects much any more.

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.

So, what actual book/tutorial would you recommend for somebody who wanted to learn web development? Regardless of the problems with Rails itself, what's a better learning path that the Rails Tutorial?

I wouldn't. Just need to get stuck in and keep Googling anything you don't understand. Best thing you can do is find a friend who knows a bit about programming to show you what they know.

Unless you dig into the magic to learn how it works.

Arguably digging into Rails source code will

> teach... terrible habits imo

Yes. But any modern web framework would also work. The patterns and practices you will learn from any of them will be mostly comparative.

What will really help you the most is learning a second tool chain after the first. This will introduce you to new and differing patterns that allow you to see the pros and cons so many here are stating.

You'll find most people have changed frameworks and languages throughout their careers. You have to with ever evolving technology. So X vs Y doesn't matter too much. At some point both could be obsolete.

The goal you seem to be after is learning web development in general. While there could be any number of paths, I would recommend whatever one you have the most resources for.

If you know developers that you can have help mentor you and they use X... then use X. Because nothing beats having a 10 minute explanation when you are learning compared to a blog post.

If you don't have in person mentors, then find X framework that has the most resources. You'll find the more stable frameworks tend to have the most documentation, go figure.

I'd also start out with a full stack framework. This is because you will already be learning so much that it can be overwhelming. Don't lose motivation to continue learning programming by trying to learn every little piece of web development. Just get something simple working. Then use libraries to add functionality. You'll get more excited having built something. Then go start to see how the library works internally and start your deep dives into core functionally apps have to have. Like authentication, authorization, validation, databases, etc.

The biggest problem I see with new or prospective developers is analysis paralysis. Pick anything and build something. If you aren't having fun you won't keep at it.

As far as employability... it's the principles you learn from building something that matter more than the framework. At lots of companies you won't even find language or framework in the job posting. This is because they understand someone who had learned the strengths and weaknesses of patterns will be more valuable. Those are harder and take longer to teach than a second language to someone. While already knowing the toolset never hurts, it often isn't a requirement.

P.S. I'm biased... use Ruby and Rails

Update: corrected protective to prospective.

I would upvote this post twice if I could.

Rails is probably still the best implementation of a full-stack framework, and I agree that full-stack frameworks are are the best way to learn.

Despite working for a Rails shop for a long time, I would probably not recommend Rails itself for completely new programmers anymore, just because they would probably be better served learning Python than Ruby these days.

For early stage development, Rails is still the best. No ORM tool out there is as powerful as ActiveRecord. Front ends are nowadays built more with React/Redux, which is well supported via Webpacker. And for basic admin pages, regular controller calls with validations and ERB/Haml/Slim templates works great. And GraphQL is fully supported via gems.

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

Yes. It’s pretty useful for building most kinds of common web services. Lessons learned will translate well to othe tools, and in particular it will help you to avoid making some common mistakes while getting to grips with the nuts and bolts of web applications.

Don’t panic about it “losing popularity.” Tools and techniques learned using one framework are pretty generally applicable to others.

I used to be a Rails developer, but in today's JS ecosystem I've found most of it can be replaced by full-stack JS.

In particular with an EmberJS front-end if you like the EmberJS convention over configuration methodology.

Yep, absolutely. It's a very productive environment to build in. If you want to get something infront of a user quickly and not get stuck in configurations, webpack scripts and so on, go with rails.

“Is Rails still relevant in 2018?”

306 points by bdcravens 49 days ago



RoR, for all of its flaws, influenced many other frameworks. It is still very popular, though I'd also say, it is on a slow decline. The takeaways are:

  1. How to create a good experience for developers

  2. Taking care to refine syntax, patterns, and architecture

  3. If you understand how the Rails is put together, you'd generally know how many frameworks are put together.
However, there are some other options.

  1. Many Rubyists and Rails developers had jumped over to using Elixir and Phoenix; that platform

  2. Others have started experimenting with Rust, Go, Crystal, etc. after knowing the flaws of the Rails platform

  3. However, the Rubyists who jump to a different platform often bring in the things they learned from Ruby to apply to the new platform. For example, Elixir is primarily built around a powerful macro system that allows for refining the syntax, while taking advantage of what the Erlang/OTP environment.

I work daily in rails and have for years. It's a great platform to learn from.

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.

Wow. Really going for a trigger with the title.(you should get a lot of activity)

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

Curious as to whether you have found a better Rails-type framework or have moved on to a different type of dev work that you prefer. Any recommendations?

In a "philosophical" move I've gone into the micro-framework realm for web stuff, and of late that means mainly a Serverless Node.js (w/ ES7) set up which is similar to the OpenAPI/swagger (w/ koa) stuff I was doing a bit ago. Also some flask.

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).

I think you should give it a try. Rails made me a better software architect and showed my the importance of writing expressive elegant code. It might have lost some market share to other techs (Node / Elixir) but it's still the original.

I think you should as your first web framework. Ruby is fun to write, and it's easy to find and understand examples for Rails (even across versions). Rails is more opinionated so allows you to think less about project structure and more about actual business logic (might be seen as a benefit for a beginner)

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)

I was a Rails dev for the past 7 years, switched to a React position a couple months ago.

There was a lot of hand wringing a few years back that Rails was quickly losing popularity, but gauging by my recent time on the job market it is still very hot. It seems like I had just as many recruiters contacting me for Rails positions as they did React. I somewhat suspect this is because many people transitioned to other things and it's harder to find experienced devs.

As many others have stated it's a mature ecosystem and there's plenty of great learning material out there.

But job market varies in every market. Rails aren't seen much anymore in EU, SEA Tech Hub and China, No idea on Canada or AUS. Japan seems to use Ruby much more in non Rails application.

I would say yes, because I don't know of a better learning resource for "learning web develeopment", especially for somebody starting at zero, teaching oneself, than the Rails Tutorial: https://www.railstutorial.org/book.

Rails aside, what would be the best tool for "learning web development" starting from zero?

I ask because people ask me and so far I've been sending beginners to the Rails Tutorial.

I don't have as detailed an answer as several of the other commenters here, but as someone in the job market at the moment I see a decent amount of Rails work floating around.

Another framework that seems to have been burgeoning in enthusiasm lately is Phoenix, built in Elixir which is a Ruby like syntax. The neat thing there is that it introduces a ton of interesting OTP concepts borrowed from Erlang (both Erlang and Elixir compile down to bytecode for the same virtual machine, the beam).

I'm still most productive in Ruby on Rails, I learned it after previously using Go, PHP, and Python (Django and Flask) for web development. Far and away Rails allows me to be more productive, and it's still being actively developed. I've used Node.js and some other frameworks since, but personal projects always come back to Rails.

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.

The question is why do you want to learn something - because it is marketable or because you will learn good practices in software development?

The question isn't "is it worth learning" it's "is it worth learning next". What do you already know?

Focus on learning theory and standards (e.x. HTTP, websockets, MVC, security principals) and learning tools becomes easy enough you won't bother asking us if it's worth the time investment.

Pretty much every programming language community has server side framework(s) which is better or close to the features provided by RoR.


No. It already has a large number of experienced enthusiasts chasing a diminishing amount of work.

It's not directly related, if I have the same question but change ruby and rails with php and laravel. What's your answer? I saw many early stage startups build their MVP using laravel.

I use laravel daily... normally as a backend to SPA style apps, with Vue on the frontend. It's a great workflow. I've tried and tried to move to nodejs as a backend, but there's just too many options, and I feel like there's no best practices there.

Basically it feels like php did back in 2012. There wasn't really a 'framework'... there were a few popular ones: codeigniter, symfony, zend -- but until the entire dev base flocked to laravel you really didn't have that community.

Then laravel kept just becoming stronger and stronger, and then vue came about and fit perfectly along side laravel. JS has no real backend that the entire community has adopted. I mean a large part of the js community doesn't even use backends they use serverless or BaaS like firebase, and there's definitely no really good full-stack frameworks esp since you now need to choose one that fits your 'flavor' (vue/react/angular).

Whatever you do, you WILL probably want to learn react or vue, I prefer vue, but that's just my preference. Vue/react are very employable skills right now. React more so, but vue is rising in popularity and I think will surpass react (I hope)...

I feel that rails is still a good framework to prototype, and grow a business from scratch.


I feel like I see a post like this every 6 months.


No. That ship has sailed. The new runtime is in the browser. Learn about wasm and matrix-multiply-add.

question asked about web software, is this not more of 'cutting edge language experiment'?




Go take a look at OutSystems. Www.outsystems.com

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact