[faizshah]

Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails

My plea to the Rails community and Rails senior devs:

1) Fully embrace SPAs as an option, React and Vue are ubiquitous among my peers. I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level.

2) Increase your outreach to hackathons and universities, I'd love to see more Rails companies coming out to the big hackathons and mentoring students. At the biggest hackathon in MLH (Bitcamp 2019) I couldn't find a Rails or Ember mentor. I'd also love to see more courses on coursera and other places that teach Rails, in my search for Rails courses on Coursera I only found 1 course (although Traversy media has been making some great content on youtube)!

[pgm8705]

I would say that Rails has fully embraced SPAs as an option. With Webpacker you can have React or Vue installed by default. That being said, at one point we decided to start using React to handle the front end of our Rails app and it has become a huge regret.

Recently we decided to switch back to using Rails + Turbolinks + Stimulus.js and the development speed and experience have been so much better.

It's disheartening to hear so few young people are using Rails. In my 10+ years experience, I always get drawn in by the new hot thing but always end up finding my way back to Rails for the better.

[conanbatt]

I hadn't done rails in a while when I brushed up on it, and found Turbolinks to be a game changing addition.

SPA's just require way too much work and fine-grained detail for starter applications. I would not recommend to do full-stack node over rails if you care about iteration speed early on.

[fouc]

I did Rails + Mithril.js (5kb react-like SPA) and then switched to Rails + Turbolinks + a mix of vanilla js, stimulus.js, and abusing ajax & js.erb.

The biggest things I miss from the original setup:

1) it's easy to write integration tests when rails is nothing but an api

2) components. it's just way easier & nicer to work with than rails views/partials.

I thought rails + turbolinks + stimulus etc would be simpler in terms of code/maintainability, but I'm not so sure anymore.

[ravenstine]

> I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level.

Is that really what you want? That sounds like a ticket for short-term gains and long-term pains.

[rhinoceraptor]

I would think understanding declarative code like React is much easier for beginners than procedural code like loops and switches. For example, tons of analysts and other business people can pick up SQL for reporting, but would have a lot of trouble writing code.

[chessturk]

That line sent a chill down my spine. I'd hate to refactor those devs' work. Oh wait, that's my day job.

[derefr]

I’m surprised it’s Python/Node taking that mindshare. From my perspective (fintech industry), it looked like 100% of the decreasing usage of Rails by other fintech startups have been due to choosing Elixir’s Phoenix framework instead.

[davidkuhta]

Out of curiosity, as a non-fintech Elixir/Phoenix dev, what particular facets of Elixir/Phoenix are fintech startups finding attractive/useful?

[derefr]

A lot of finance is built on event sourcing (without calling it that), in that you can’t just overwrite your existing DB state with new state; everything has to be a ledger with a history, and you have to be able to trace the “provenance” of your data—what version of your business rules were used to compute any derived results, both so that those results (and results derived further from them) can be recomputed when you update your logic; and so you that you can use the version of the business rules appropriate to a given dataset (e.g. the tax laws appropriate for the year a given invoice was generated) when auditing that dataset, or when migrating that dataset to a new storage format.

Basically, you want:

• a runtime that forces a functional/immutable programming style (because it’s so much harder to avoid errors in algorithms that operate on mutable data), and which has lots of persistent data structures to make this style efficient;

• concurrency for processing unrelated batches;

• workload isolation (where one batch-job workload crashing doesn’t bring down your whole job processor);

• runtime inspectability and tracing (because it’s hard/illegal to replicate production customer data in staging to get matching conditions)

• a solid library to transit data between a DBMS and native record types (a Record-Relational Mapper lib), with fluent syntax for advanced relational querying features;

• and, of course, a solid Rails-like backend MVC framework to stick on top, to give people an API and web app view into your system†.

So, a lot of these companies are choosing an Elixir+Phoenix stack 85% because of ERTS, 10% because of Ecto, and 5% because of Phoenix itself.

For the companies that realize that what they’re doing is Event Sourcing, the https://github.com/commanded/commanded CQRS/ES framework is also an exciting “feature” of the Elixir ecosystem.

† Sometimes this is considered a separate need—you can build the business event-processing system, in Elixir, as a custom e.g. gRPC API service; and then you can use whatever you want for the web-API/web-app service that fronts it. Sometimes these shops use Rails for the web layer! But just as likely they use Node (because they delegate the front-end layer—now free of business logic—to the front-end devs, and front-end devs know JS) or Elixir+Phoenix (if the same backend devs writing the event-processing system are tasked with writing the web layer.)

[j88439h84]

Great writeup, thank you.

[davidkuhta]

Thanks for the insights!

[diveanon]

Hire this guy.

[sansnomme]

Can you cite some examples?

[dschadd]

To play devil's advocate, I am a junior dev in a relatively large US market and Rails is still very popular. I'm currently using it as the backend API for my side project. It's just simple and fun to code in.

[diveanon]

Most of my career has been spent building web apps in Rails, Node, a smattering of python frameworks.

Python is pretty great, but the fragmentation of the ecosystem puts it behind Rails imho.

Node is a constant headache and I have seen it be the death of more than one startup. Unless you are using a typed version of JS it is going to be a problem, I can guarantee it.

Rails kinda just works. It isn't as performant as I would like, but for the overwhelming majority of web apps that isn't an issue.

I know it can be hard to find rails devs, so just make them. Hire competent CS grads and train them. If they actually earned their degree it will be easy.

If you are in an executive role at a startup building a web app and optimizing for team velocity it is always in your interests to choose an opinionated framework that has already solved the hard problems for you and imposed structure on your team.

[ksec]

>My plea to the Rails community and Rails senior devs:

The problem is, I think, DHH doesn't really cares about it. He made it clear that Open Source shouldn't come with responsibility to make it great or fit your needs. It is more like a gift to the rest of the world with No Strings attached.

There is also the resources and company backing problem. Python is THE languages in Data Science, Node is javascript that is everywhere, and PHP, despite many people despise it, still runs the vast majority of the web.

With Github and Shopify now actively contributing to Rails, and Stripe working on Ruby, hopefully things will be better in the future.