Hacker News new | comments | show | ask | jobs | submit login

IMHO, the main reason Rails is declining in relevance isn't microservices or the productivity (!) of Java, but the fact that more and more development effort for web applications is moving into JS front-end coding.

I still love Rails, but when your front end is mostly done using React (or something similar) you lose many of the advantages you previously had when almost your full stack was inside Ruby and Rails.

The latest version moved in the right direction by making Webpack a first-class citizen, but what would really make a big difference would be some kind of native integration of a mature front-end framework. My personal choice would be React, but anything would do as long as the connection between the Ruby API part and the Javascript front-end part followed the DRY and "convention over configuration" principles that made Rails great in the first place.

If I could scaffold CRUD interfaces with basic React components already integrated with the Rails API, and then start developing from there, I would become a much happier programmer :)

Wholeheartedly agree. And my personal opinion is that this unification is going to come from Java/Truffle.

Trufflejs and Truffleruby are high performance engines implemented in top of JVM JIT. already trufflejs claims reasonable compatibility with nodejs.

It would be amazing to have a single runtime running a Ruby backend and a react front-end.

Laravel pretty much does with Vue what you are suggesting Rails could do with React. It's a pretty nice integration.

This is true for more than RoR.

ASP.Net MVC has the same issue, but Microsoft headed that off by creating WebAPI, which is a better fit for the single page applications. Not that you couldn't do everything in WebAPI in MVC, but MVC was more of a website framework, while WebAPI has no rendering capabilities.

> IMHO, the main reason Rails is declining in relevance isn't microservices or the productivity (!) of Java, but the fact that more and more development effort for web applications is moving into JS front-end coding.

This. I also suspect that for developers whose first language - or primary language these days - is JavaScript it's a lot more comfortable to reach for a Node backend framework when they need it. Also, Go has become pretty popular for somewhat more custom or complex backend tasks. Plus, there are more and more high-level third-party services offering different pieces of backend functionality.

NodeJS as a backend platform is still horribly inefficient and years behind mature Python and Ruby solutions.

I would consider JavaScript my primary language, and you're right - Node is usually my go-to choice for a web backend. Express is pretty easy to grasp and be productive with.

But when I need more (auth, orm, logging, etc.), I feel like I'm spending more time searching for and curating packages and then trying to get them integrated than I am actually building an application.

Rails (especially its API flag) has caught my attention recently because this becomes a non-issue - you pretty much just use what Rails has included.

Huh I have had a very easy time integrating passport, mongoose, and morgan respectively for the above 3 asks.

I'd normally also have to select packages for sending emails, running background jobs, internationalization, templates, validation, file uploads and caching at a bare minimum. Then I'd have to make sure they all work well together, setup testing and probably have to write additional functionality that Rails or Django already covers.

Frameworks like Rails and Django cover a ton of functionality and gluing together and maintaining a set of packages to cover even a fraction of that functionality is a ton of work that's often for very little gain.

Check out hapi. https://hapijs.com

Agree and would love Rails to take this further. Rails is still very useful - and is certainly used by countless startups along with React. CRUD plus a smart redux/mobx scaffold of some sort. Or auto graphql-ify.

The goal is still the same - get up and running with an idea as fast as possible while not being cornered - scaling with the product. The FE has simply become where most of the effort and innovation is now. Rails will benefit from helping on that side of the coin.

> but what would really make a big difference would be some kind of native integration of a mature front-end framework

I haven't kept up-to-date on Rails news, but I thought the Ember.js + Rails pairing was supposed to be their long term answer to that problem. (In that, "we support using Rails with everything, but Ember.js is the philosophically-similar, lowest-friction option"). Is that not happening anymore?

Rails never had that kind of relationship w/ Ember. Katz was both a Rails and Ember core dev, as well other Ember core devs had links to the Rails world so they are philosophically similar in a way...

But it really is a one-way relationship. Rails itself now has webpack included as of 5.1+ and its implementation has integrations for React, Vue, Angular, and even Elm - but no Ember. I don't think the Rails core team is opposed to Ember insofar as they're just embracing what appear to be the most common or upcoming SPA frameworks/libs. Ember just never really broke out.

I've been developing rails for over 10 years, and I somewhat have seen this focus shift - but partly it's due to the complexity of frontend interfaces these days.

I myself would often spin up a rails api + react frontend.

With rails 5.1 and especially webpacker_react I've seen a possible new direction which combines the best of both worlds.

I think we could see something pretty exciting in this space soon if the integration of rails+react can tighten up a bit.

I hate to be that guy, but this may not be the best idea thanks to the patent stuff. I didn't hear if anything changed for React after the Apache Foundation pushed to change the license for RocksDB.


I agree completely. Rails actually is useful as rails-api, but the real benefit to Rails is the simplicity you get from the integrated development system.

You lose a lot of that when you go away from Rails and start using a JS based front end. It's not that rails-api doesn't work - it works quite well. It just neutralizes, to some extent, the productivity gains you got from rails.

Here's a quote from the rails doctrine that sums it up nicely: "Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value."

I actually think Rails is still an excellent choice for small to medium business apps implemented as a series of web forms backed by a database. The productivity Rails brings in that case is pretty amazing. And you certainly can bring in a bit of javascript in a progressive development fashion and maintain simplicity and order.

What drives me nuts is when people write an SPA to stand in for a set of web forms, with almost no gain, and a huge increase in complexity (and drop in productivity). Sometimes I get the feeling people on HN are working on more cutting edge stuff. Truth is, an awful lot of business software really is a series of web forms persisted to a database. I do think you can get these apps done with half the staff, twice as fast, with better code clarity, stability, and test coverage, by sticking with Rails. In fact, the slowdown in Rails activity is probably a good indication that you should use it for these apps, not that you shouldn't!

I also really like your comments about an integrated front-end SPA (or other client-side heavy) framework. I don't see javascript having quite the clarity of ruby on the page, but it could be tidy enough to be no problem. I do think something like this will emerge, eventually.

Until then, I'd be tempted to stay with older technology. Remember the churn around spring di, pico, struts, struts 2, spring mvc, hibernate, JPA, ibates, stripes, tiles, etc...? Or, ahem, EJB? All(some?) were good frameworks written by intelligent people trying to provide value (and, in many cases, providing that value). But I wish I'd just stuck with slightly more vanilla jsp/jdbc/servlets + cookbook for a while longer. Why? Because after investing a ton of time and mental exhaustion into those frameworks, I ended up using... Ruby. My guess is that something similar will happen in the current JS chaos. Something will happen that addresses what these frameworks seek to provide, but how it happens will also be somewhat unexpected (though if I had to make a guess, I'd bet on some sort of isomorphic javascript, with a transpiler that allows people to use Python, Ruby, and other languages, breaking there JS monopoly).

Just because you see an expiration date on the milk carton doesn't mean you can't drink it for another week. My guess is that my time with Rails will be up before too terribly long, but that doesn't mean you need to start writing javascript-heavy SPAs now.

Unless, well, you do have to. Unfortunately, my guess is that a lot of people writing this code aren't doing it because they're on one of those projects that actually really needs it (or benefits substantially from it). We have to do this because our orgs require it, a software architect said it should be used, or because we know we won't get hired for our next gig without this experience, so we bring it into our current project even if it isn't helpful.

Applications are open for YC Summer 2018

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