Hacker News Reader

Comment by hirundo | Hacker News Reader

Apparently reports of Rails' death are greatly exaggerated.

Say what you will about performance, but Rails continues to be the most productive framework for building a database backed web application or (non-trivial) REST API. It's secure by default, includes optional peripherals (ActiveJob, ActiveStorage, ActiveMailbox, etc.) to handle most common tasks and has excellent documentation.

Congrats to the Rails team on this release and for continuing to plug away after all these years.

Rails just became boring technology. It works. The hype is gone, but it continues chugging along happily and is generally an understood problem.

I think you mean mature.

Well, yes. Mature, boring technology. I meant it in the sense of this essay[1].

[1] https://mcfunley.com/choose-boring-technology

And the presentation at http://boringtechnology.club/

I hated on Rails forever. It has its flaws for sure. And granted, I now have 5 years of experience with it, but there is nothing that compares to it for whipping something together quickly.

Don't get me wrong, Python is a great language. And Django is a great framework. There's lots of good languages and Frameworks.

But Rails has the right magic of incredibly stable tooling, a huge community, and tons of documentation & guides written for beginners. It definitely has a unique (and valuable) place in the world / businesses.

Has it ever been accused of being dead as a project? Falling out of favor for new projects, sure, but a new major release doesn't counter that.

Search for "rails dead" and you'll find a whole genre of Rails eulogies ... and denials that it needs one.

All of the ones I’ve seen have been “dead” in the sense of “there is some new hotness that has replaced it for new projects” not “no one is still maintaining Rails”.

A new release contradicts the latter, not the former.

If dead means not the new hotness, then yes, Rails is dead. If it means the project has stopped releasing major features and improving the code base top to bottom, it isn't.

What?! Rails has been announced as dead at the release of almost every new MVC framework. The last major proclamation was when Phoenix was the new hotness.

Rails: still dead after 15 years.

Will it ever hit critical mass?

Eh, no. The whole MVC pattern is obsolete and every web project I've worked on less than 5 years old is a SPA. It's gone the way of PHP. It will always be around in legacy stuff but hardly anyone is building new project with it.

You can very easily eschew the V and run your spa against a Rails API.

Strictly speaking, the V is still there. The View doesn't have to render HTML; it's still there, rendering JSON, in a Rails API.

You can even build an SPA using the MVC pattern. I think nullwasamistake's comment was misusing buzzwords, and they were rather comparing server-rendered apps vs client-side SPAs.

Assuming your API follows REST, I find the MVC pattern to be immensely helpful. Even if the "V" part is just an object serializer, it's still a great pattern.

What are you using for the backend? A SPA has no value without one. Unless you're using something like Firebase, pretty good chance your backend is an MVC app. (I think you're confusing server-rendered apps with the MVC pattern)

If you're using graphql for the backend, is it still MVC?

Even if you can stretch the definition to fit, is it still useful to organize your code along those terms instead of what's natural in the new ecosystem? (data source resolvers, type schemas, queries/mutations)

Depends on what you're building the API in. GraphQL is a specification, not a language. For example, you can build a GraphQL API using Rails.

Eh I guess I meant "traditional" web MVC where HTML template for the whole page is pre-rendered on the server.

We use gRPC web, so backend is a bunch of RPC endpoints. Front end is regular SPA.

This has worked great for us because it reduces backend to "shipping objects" instead of all the bs you normally have to deal with in HTTP.

With gRPC there's no use for rails, or any HTTP server framework. As far as I can tell, this is the future of web endpoints, so rails will die out.

> rails will die out

That'll suck. Hope your company doesn't use Github.

Amazon still runs a bunch of Perl in the back. Just because you're stuck with some design choice doesn't mean that framework has a solid future. People still write plenty of COBOL but you don't see any new applications using it

Plenty of new mainframe code is written in corporate settings. Legacy modernization is strong as ever and for some companies that doesn’t mean moving off mainframe - it means upgrading, cleaning up and cloning legacy COBOL code bases and some times writing new.

Pretty sure Rails is just adapting so that the V in the MVC is the SPA.

I'm convinced RPC frameworks are the future of REST. It's too crufty without them. Most of the rails stack just isn't involved in those calls, so there's not much purpose using it.

MVC has been around since the 70s and is one of the most formative design patterns. Hardly obsolete.

And this is why every website now has a loading screen in front of it.

That's stupid implementation. You can _easily_ build static websites that load near instantly and are tiny. Also if you choose to shut off javascript that's your choice, but don't complain the web does not work.

If nearly every implementation of a technology is broken, I wouldn't blame the implementors. I would blame the technology.

Hell, Facebook basically invented reactive Javascript and they still have loading bars everywhere, broken content sections, and requires a full reload every now and again to get content to show. Reddit is even worse. Those are two major implementations of SPAs and they're both horribly broken.

It's nothing to do with if Javascript is enabled in your browser. If Facebook and Reddit, two of the most popular sites on the Internet, can't get SPA right, I'm blaming the technology.

MVC is way bigger than "server-rendered websites". It applies to anything with an interface - native apps, SPAs. Arguably even services that don't have GUIs. It's a method of separating concerns that has remained remarkably popular through many different technology cycles. You're saying a lot of words but I don't think you know what they mean.

Right on. My concept of MVC just helps guide me on how I’m going to go about building some particular web functionality, irregardless of whether or not the end result is more or less SPA in nature or not. Some parts of my app are nearly completely Ajax driven and server side rendered, other parts are just static web pages. The model means, what classes or methods do I need to build to store the data/state. The view means how am I going to present the to the client side, with a mix of html/template engine working with a backend view class/methods. The controller is how am I going to network the model with the view, and that is generally with forms and other supporting logic. The level of people on this thread that are talking very confidently about things with which they are clearly novices, is pretty shocking. I haven’t seen such a thread on HN in a long time. I’m a python guy using Flask, but congrats to the Rails users and thanks to the developers for continuing to drive it! You’ve made the web a better place.

Irregardless isn’t a word. :)

Reply on news.ycombinator.com