Rails 7.1 Released | Hacker News Reader

Rails 7.1 Released

github.com

265 pointssathishmanohar240 comments

Rails is great, and better than ever. I've spent most of my early years in the field working with Django and Laravel, then moved to frontend doing [all the usual stuff we do nowadays] and this year I was assigned back to a Rails + Hotwire project.

I'm truly amazed how much simpler things are. I feel sad most of us have forgotten how easier things could be, and I'm terrified about new people joining this industry that will never know about how easier things could be because they'll never experience that (as things are right now, who knows the future...).

If you're reading this and never tried Rails, or discarded it because you listened somebody say the usual "PHP is ugly/Rails is dead/JavaScript is messy" give it a try with an open mind and ignore what others say for a moment. I can't recommend it enough.

It might not be the best tool if you have 1k engineers working on the same repository, but as a small team it has no competitors, it's just miles ahead everything else (well, honestly, maybe Laravel is as good).

I'd like to throw in Phoenix LiveView here.

Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO.

LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-to-no-DIY-JS, and one of the finest VMs there is (BEAM).

If nothing else, I'm happy that these projects all fight the "let's take a step back"-fight. At $DAYJOB I write React with Relay and the amount of hoops one needs to jump through is exhausting, even though I've been writing frontend JS for many years now and consider myself half decent in it.

Other than learning for fun. Is there enough of a benefit to learning Elixir if you would already consider yourself an expert at PHP/Laravel and JS/Vue ?

At a glance it's hard to see the value or believe that it has the same longevity or $$$ value.

Elixir is like an alien shiny flying soucer. It can do all types of technical marvels with a simplicity that is not possible without disfiguring more traditional frameworks. So I'd say having a cursory glance at it is a must.

In terms of $$$ value, it is extremely efficient --including all the "alien" stuff, and that's why it's so cool. An Elixir team will generally create things cheaper to build and operate.

Now, the question is how many Elixir shops you are going to find a job with, but the answer to that depends on the type of career trajectory you are choosing. For example, Rails is not an industry standard by any means if you think in terms of classic IT consulting jobs but has a stronger dev mindshare in startups, so there you go.

It's a tough market for Elixir devs at the moment - there seem to be a lot more people who want to work with Elixir than there are companies hiring for it. But on the flipside, that means if you're a company who wants to take a chance on Elixir, there are lots of available devs to hire!

Personally, I'm comfortable betting my career on Elixir at the moment. It's too goddamn good to remain a niche language - I expect it to get a lot bigger in the years ahead as more companies and devs fall in love with it. It'll happen slowly, and it's never going to reach the level of saturation that that, say, Javascript has, but I think it has a bright future.

Phoenix and LiveView are a joy to work with, much more so than any previous technology I've used. I haven't yet looked at any of the exciting new ML stuff that's happening in the Elixir world (Nx etc.) but hopefully they'll drive adoption too. I'm never going back to my old ways.

The craziest thing with Elixir is that you can do things all by yourself in the same time that would normally take a big team and consequent infrastructure to do.

As someone who's spent the bulk of his career in Rails and then Phoenix, to me it's the other way around: everything else is just so goddamn slow and unproductive. Don't people realise that it doesn't have to be like this?

Wait, are you saying that you are more productive in Rails than in Phoenix? That seems to be the opposite of what the consensus view in this thread is.

I'm reading it as "Rails and Phoenix is more productive than other technologies".

Yes.

You are more productive on the thing you know the most. Shocking

No, I'm saying that I'm more productive in either Rails or Phoenix than I am in anything else.

(And of the two, I'm more productive in Phoenix, but I didn't mention that in the comment you're replying to.)

Allow me to disagree. Finding good engineers that are knowledgeable with Elixir has been difficult to the point that we’ve hired people that never professionally used the language to senior positions. That’s not a problem on its own, since the language is mostly easy to learn, but there definitely is no abundance.

Try posting your job ad on the Elixir Slack (elixir-lang.slack.com) - there's a lot of jobseekers in there.

(I think the only way to join the Slack atm is to be manually invited because the signup app got broken by Heroku's pricing changes - but if you email the address in my profile then I'll ask someone to invite you.)

Its biggest strength is that it is good at almost everything (normal CRUD, websockets, distributed systems, easy to deploy as a single binary). Elixir/Erlang could be your entire stack

Just gave it a look. Dynamically typed. IMO if scalability is on the table, having types is a huge benefit.

It saddens me that ruby, python, elixir, JS... many of the best and most productive backend frameworks have types as an afterthought only.

Rust is cool, but it's also hard to write(did last year's AoC using it, and it was fast to run, slow to write).

Anyone have any recommendations for me? Should I look at go/gin perhaps? No Java please - I need type inference because I'm a spoiled baby.

Edit: anyone tried crystal? Looks promising, but doesn't seem popular...

Typing is coming!

Java already has type inference...

If you search Crystal on HN, there are a few user who are happy with it. Unfortunately most of them are only using it for personal projects.

> Laravel is creeping in, but it's not there yet IMO.

Could you elaborate on this?

I love rails. Hardly anyone is using it in my country, and the companies that do are looking for absolute wizards. Because I can’t find jobs using it, I do t get enough experience and lose out to said wizards (after the jobs stay open for 12+ months). Instead, I’m spewing yet more JS into the world because that’s where the demand is :/

What’s limiting you to taking jobs in just your country? I’ve got a gal working for me in Nepal out of all places. Previously had a guy in Jamaica.

I live in a very HCOL country, companies abroad can’t match local market pay.

What is HCOL?

High cost of living

This is great to hear. <3

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

I'm using both on two different customers. I have a preference for Rails.

The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that.

That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports. I hated that in Java even if the inevitable Java IDE added them for me.

The ORMs are more or less equivalent. I have a dislike for having to actually type the default scope (not the Django term) in Django as in

  Model.objects.filter(...)

when Rails lets me type

  Model.where(...)

The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python. It's something else much less powerful so you have to either prepare all the data in the controller (which is called a view in Django) exactly as they'll be displayed in the page, or write a templatetag and use it to transform the data inside the page. That loses an unbelievable amount of time. If I count the cumulative hours, days, weeks spent at writing templatetags instead of a couple of Python statements I don't know whether to thank Django developers for the easy money or to roll my eyes because that time is useless.

To recap, Django wastes developer time. It's death by a thousand cuts. I'll never use it for one of my personal free time projects.

Edit: don't be too smart in Rails, that is don't build too much magic and waste the time of the next developer into a quest for finding where something really happens. Write straightforward code and if some method name is created automatically, put a comment hinting at the source.

I've worked with both for years and one thing that always bother me is implicit over explicit in RoR. It can seems easy to write code and it's faster because of that, but reading code is harder, there is too much magic. Given that we spent more time reading code than writing code I prefer the python way.

I could agree with this but I think we're comparing here Django with Rails (the frameworks) not the languages.

But yeah, if I had an option I'd prefer things to be more explicit.

I've been a Rails dev for almost 10 years and the magic is the worst part. When something just works but I expected another hour of work, I feel like I've fallen into a trap. So, instead of just moving on, I look in the documentation for what just happened.

When you find yourself interacting with the magic parts, it is imperative that you comment what is going on so the next dev, which will probably be you, isn't also surprised.

Thanks for the reply. Agreed on the templating side of things - it certainly makes building sophisticated UXs harder.

Great point around project structure and ability to move between codebases - I think the lack of enforced structure in Django absolutely helps increase codebase entropy over time.

> If I count the cumulative hours, days, weeks spent at writing templatetags

Django has support for Jinja templates so you could just use that and call methods in your templates, which negates the need for most template tags.

> That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports.

Although its been a while, I do remember struggling a lot with autoloading in rails for two reasons: you can't find your dependencies from the code itself and when it breaks down its quite hard to debug. Maybe things are better now with rails and when you get really proficient you know how to find where things are - however that increase the learning curve which is supposed to be a benefit with rails. With django, I can generally look at the imports to see what this module is using. With the help of the right tools I can:

- 'go to definition' of any symbol and 99% of the time land in the source, even of django itself - automatically add imports so you don't have to write them - automatically sort and format imports and see the unused ones

With the optional static typing that is being greatly improved with recent releases, things get even easier.

I prefer this a lot above the rails 'magic', for me it is a huge time saver because my memory is not so good, there is minimal friction moving around between code and is various dependencies to see exactly how its done. With rails I'm more often looking at the docs (not so great) or examples, with django I'm most of the time looking at the source code itself or running the shell (which is very, very good).

> Model.objects.filter(...)

Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

> The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python.

I hate both but prefer the django template language. I'm surprised this is such a time waster for you. I think its good practice to not put too much logic in the templates so the division of labor in django is much better imo. But then again, I'm not a good frontend person and have problems with the deeply nested structures in html. Everything can help me simplify the template is a huge timesaver for me, bugs in the frontend code are terribly annoying. Honestly I hate frontend.

> > Model.objects.filter(...)

> Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

The point it that the objects method adds zero information to the statement. However it's an opportunity to add a soon to be discovered bug when Django crashes because one forgets to type .objects

They should have made filter a method of all model classes and of the models.Manager class. Same thing for all its sibling methods.

> Unfortunately that means that you have to waste time by writing those imports

This is time well spent in my opinion. Everyone, including future you, benefit from it.

One of my biggest gripes in Rails is not being able to do this.

Django is great (and comparable) if you're doing just backend, or have a separate frontend/SPA.

The frontend situation in Django is terribly outdated. Just the templating system is the worst thing I've ever seen, and it doesn't even have an asset pipeline.

Agreed. I’ve had to create dedicated SPAs for several projects recently which is a huge shame. I’d be interested to understand the architectural goals of the Django project moving ahead to see if they’re even interested in solving for this type of problem.

I've worked with them both, although Rails has been a while. Some things that stand out to me:

Rails has pretty good code generation. If I want just want to get started and add a birthday field to the settings page, I can run a short one sentence command and it will go off: it will know how to do schema migration, routing, views, controller, etc. This is possible because everything is so straightfoward and consistent. I'm not saying generators are a good way to write your code, its just one example of how rails has very a high level of abstractions.

Django however has the admin. Once you have a model, it will generate a fully functional cms for it and its very tweakable. For a lot of businesses, the admin is quite servicable as a cms or administation tool, and it is a _huge_ timesaver.

I generally prefer django over rails, it just seems all much more explicit and easier to discover to me, however I do agree you can be a lot faster with rails once you learn how things fit together.

I second you on the admin and I'm sorry I forgot about it.

Rails has the optional ActiveAdmin gem but it has basically no automatic integration with the Rails app and it's not included. That means that any Django app has a basic admin and most Rails app don't have one.

To be fair, it's easy to hit the limits of those admins but by baking a user hierarchy in the main web app with a super user, you can use the standard web app for many administration tasks. If you can impersonate users (handy for debugging and you have all their data anyway) you can do a lot of things without an admin interface.

What do you consider harder than rails? Something like Remix Run makes things very straightforward.

Those frameworks (Remix, Next, etc) give you like 5% of what you get with Rails or Laravel. There’s no point of comparison.

There is a comparison though. So there's 95% of things for you to give an example from but your comment is missing any useful examples

A lot of rails devs I know have switched to ember.js [1], because it's also a framework based on conventions rather than having a million third-party plugins that break all the time.

Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc.

But it's not as cool as the other ones I guess, because it just works too well enough!?

[1] https://emberjs.com/

I thought Ember was a front end framework or am I missing something?

The idea behind ember-data [2] is that the models and their relationships are defined on the frontend side, which implies that the models are the single source of truth for both the frontend and the backend, including the APIs themselves. Ember adheres to json api specification, but there is lots of adapters for other database query languageds and/or storage types [1]

As I said in my previous post, it's a framework based on conventions, so it'd a batteries-included approach to both frontend and backend.

[1] https://emberobserver.com/categories/ember-data-adapters

[2] https://guides.emberjs.com/release/models/

Did you ever try Jump Start Rails or Bullet Train?

I’m thinking of building a side project with Rails and I’m wondering if they are worth it?

I am on JumpStartPro and quite happy about it. It has all the common gems already included and ready to configure. It also has a lot of excellent code that shows me how to do things.

I took a 13,000 line Rails 7.0 app and updated it to 7.1. I had to change 1 line of test configuration code to make everything work beyond the diff between 7.0 and 7.1[0].

I would say that's a success for having an easy upgrade path. Now the fun part is going back to refactor some of the code to use the new features in 7.1.

If anyone is curious, I updated my Rails / Docker example app to use 7.1 too https://github.com/nickjj/docker-rails-example. Even though Rails 7.1 comes with a Dockerfile, there's still a lot of opinions you can add such as using Docker Compose to have a fully working out of the box experience that works in development and production -- complete with Postgres, Redis, Action Cable, Sidekiq and more.

[0]: https://railsdiff.org/7.0.8/7.1.0

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck

Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

I've been doing Rails since 2005 and love it, but - and that's just my personal preference! - I wish they'd have a stable release cadence (calver like vscode maybe?) and a clearer roadmap/governance.

Maybe it's just me but I just don't like DHH's governance lately. Not in a bad way, but following him on Twitter I just no longer respect him.

Coding in rails since 2012 here. I lost faith in rails at 5.2. Active storage was so terrible.

What is terrible about active storage?

My memory is fuzzy, but...

1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading).

2. no support for CDNs (I think newer rails versions added support)

3. blobs and attachments were unnecessary abstractions.

3a. Querying was annoying (extra joins) and easy to add n+1 queries.

3b. In my app, images are moderated and it was unclear where to put the moderation metadata (on blobs? attachments? create a new table? why so many tables?) or `deleted_at` type columns.

4. GraphQL gem didn't support it: https://github.com/rmosolgo/graphql-ruby/issues/1777

1. Rails has had direct upload since it introduced Active Storage. No one has uploaded files through their servers in a decade

2. What do you mean? Point whatever CDN you want at your origin

3. Maybe

3a. Yes

3b. Metadata or a new table

4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fact we're stuck on the old Graqphl RB gem that used a DSL instead of classes, which also blocks our Rails upgrade. We've been able to revert everything back to good ole Rest for another part of the app. Be cautious adopting technologies of large companies.

1. You are correct for upload, but not for download. Looks like rails 7 added support for presigned urls: https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-ur...

2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136

3. yep

4. yep

Looking forward to see if and how it evolved in rails 7. In 6 it was really bad too and my tests are flaky because of some weird active storage async stuff. Can't find the id of blobs I have no idea

> Maybe it's just me but I just don't like DHH's governance lately.

It's not really governance, that's kinda the problem. To be fair, he never claimed that he was providing governance. Rails was extracted from basecamp. The impression I get is that he sees Rails as a gift to the community created from the profit-making Basecamp. Which is great; and I appreciate the fact that I've been able to build a career using Rails.

But there is no governance really. Rails goes in the direction that 37signals wants it to, which is largely pretty good. You and I don't get much of a say in it though; especially if DHH disagrees.

I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons:

- if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

- it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

- Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like normal.

Additionally, the recent Turbo TypeScript debacle did not instill confidence in the long term stewardship of the Hotwire ecosystem.

We're still on the fence about it. Stimulus does feel like a very Railsy way to write frontend code, which is definitely a plus for small teams of people who're already familiar with Rails.

Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!

> when simple functions with inputs and outputs

And the state library, and the hooks for side effects, and the SSR, and the hydration, and the VDOM, and... It's not that simple.

Functional/OOP flamewar is starting...

On the FE, this is already a settled topic. Who wants to go back to `this`? Um... nobody.

I know react is moving towards SSR quite a lot but I don't think hydration or SSR are actually common for react devs to care about. You also have very similar issues with hotwire, so I'm not sure it makes React more complicated.

For all its flaws, React is still extremely "small" as far as front end and server side front end goes.

That might change with the increased push towards next.js and SSR though.

Very true. For every day dev, all the framework bits are stuff the average dev doesn't need to know at all. Ie, none of the devs at my company know anything about that, and that's just fine. We get a ton of work done.

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Can't these candidates quickly learn Hotwire? Seems like its much simpler than React (less moving parts)

You'd be surprised how many candidates would prefer to just take another job. If for no other reason than resume building with the word react.

Then that was not a good candidate from the get go? What about hiring people that really care about the product they're building and not just tool fanatics?

One good reason to avoid a job doing Hotwire is so that you can take a job doing React for a similar amount, where your experience applies better and where you'll gain more transferrable experience.

In short, it's probably better for your career to work on React.

As a developer, I get it.

What I don't get is why as an owner/stakeholder/CTO/lead would pick the worse tool (in some context) just because everyone is using it. Well, I do get it... I just don't agree.

If you read between the lines here, everyone is just picking React because everyone else is picking React, that's the only reason apparently. It drives me mad, but honestly I do understand it.

Yeah, especially for crud apps when you get to implementing forms. So much easier with rails and hotwire.

But I would be tempted to go react and inertia js for MUI or EUI for the predesinged components and nice datagrids.

- https://eui.elastic.co - https://mui.com

Also, I'm not 100% sure it's for the "same amount". To me it looks like Rails jobs have higher salaries, at least around here. But that could be because most Rails devs have many years of experience, I don't know.

No because every job wants you to hit the ground running. They’ll start asking for “10 years experience in Rails Hotwire” at some point

> Can't these candidates quickly learn Hotwire?

Main issue I've seen is Rails shops don't hire devs without Rails experience, or expect you to interview well with backend OOP type code.

I guess that's okay for someone wanting to get away from frontend and be "full stack", but it's not for a lot of people.

Stimulus is considerably simpler than React, imo. Turbo, with frames and streams, might take a little time to get the hang of, but it's not overly complex either.

TL;DR use React because everyone uses React?

> if you're looking to hire frontend engineers, the candidate pool for React

While this is true, I think you will also need less people to achieve the same, the amount of work is incredibly less. So maybe finding one or two developers with an open enough mind and a good salary will provide even more value than a full team of backend devs + a full team of frontend devs + all the coordination efforts.

> - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

Any example of this? I don’t find this to be the case, given that any “vanilla” library will work out of the box and many of the react packages are there to solve react creates problems.

> Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like

This might be controversial, but I don’t find testing UI with unit tests useful at all. Tools such as cypress provide a lot more value for the effort it takes to write and maintain, and those tools work with any underlying implementation. Mocking browser APIs is not fun at all.

Regarding typescript, I honestly just don’t get the drama. It’s just a tool. If it solves a problem for you use it, if you don’t, don’t use it. And you can’t force others to use the tool you like the most.

Also, given how these tools work (mostly with data attributes and in the fly generated methods from those data attributes) I’m not convinced typescript or not will make any noticeable difference as the user of the library.

At the end of the day it’s all trade offs. But something I can guarantee is that going the React way is a ton more work, decisions, maintenance, people and headaches. If your app/project really requires react then you’ll have to bite the bullet and go for it. What’s sad to me is going with react just because everyone uses it.

Mastodon runs as a rails api with a react frontend. Last time I discussed this people mentioned it was the worst of both worlds and I get the argument.

But doing things that way means nearly every fronted dev can work with their favourite patterns and frameworks. I love that they can debate replacing create-react-app and i do not have to care beyond saying "as long you meet the openapi spec". Moreover, everything you've described along with most of what has changed recently in the ecosystem goes away. I don't have to care what is happening to hotwire, or the asset pipeline in general or around scss gems being deprecated.

> fronted dev can work with their favourite patterns and frameworks

And this is a big problem in my opinion. We should decide the stack that better solves the problem, and then hire people that are happy to work with that, not the other way around.

It's like saying you're in the business of putting screws into walls, but you do it always with hammers because most people like to use hammers.

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

The trick is not to look for React developers, or Stimulus developers, but to look for frontend developers. Those who can competently write javascript/typescript, have a good understanding of browser apis, and are competent in css and html.

Agreed, Stimulus is so simple that there's almost no prerequisite other beyond a basic understanding of HTML and javascript, both things that any "React developer" and even most "backend" web developers should already have.

Maybe I'm biased but I feel like rails + stimulus makes it incredibly easy for anybody with any kind of programming background to grok the entire project, and maybe you can reconsider even even having dedicated "frontend developers" at all. I know that specialization is a thing, but it's just so easy to be a "full stack" developer on such an app that I think almost anybody could pick it up.

If you have to hire dedicated frontend engineers maybe you have overgrown Rails or it’s not a good fit for your site? I find Rails is awesome when it fits in the model Fullstack engineers with designers, HTML-heavy with JS enhancements on specific views. It’s so simple and efficient when the views nicely match the URL routes and they are mostly HTML, even the designers can work on the codebase.

BTW, if you end up using React with Rails, consider https://inertiajs.com/. It works great with Rails.

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Two comments on this - I know it will not change your mind, but maybe other people will read this:

1. Of course, the candidate pool for React is bigger, I think Hotwired - in its current form was released in 2021 (November or December). So this expectation is kinda “Planning to fail” right? If you put this as a criteria of course you are going to choose React. Are you sure you are not already decided to use React and then found reasons for the decision. It is totally fine if you did as we are all doing this constantly (first deciding and then finding reasons or explanations for the decision)

2. I think if you have a React developer (so a person who should know JS and HTML) who cannot write Hotwire code, that is a big problem. Anyone with a good foundation of JS and HTML should be able to write Hotwire code (Stimulus + Turbo)

Recommendation: Don't put in your job ad "Required skill: Hotwired". Just hire people who understand how the web works (browser + HTML ...) and they will be able to write Hotwire-compliant code.

> it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages

I am not sure what packages are you trying to find. But I would suggest if you are trying to find an 1-on-1 corresponding React package to Stimulus package the way the UI and UX is designed is not for Hotwire. You should not choose Hotwire to replace React but keep the same page behaviour. You should think your UX web experience different - more back to basics with interactivity sprinkled around

> Stimulus doesn't really offer a way to write unit tests for your controllers

Again if you have an application like say Figma UI then probably you need unit tests. But if you think the UX to be Rails 7 + Hotwire, you will not write so much JS code that you need unit tests for it.

Testing an end-to-end feature should be enough.

Of course, this is just me talking about a product (yours) that I don't know what it is an I am making so many assumptions.

I lost faith in rails JS integrations.

I either do SSR with slim or do API only with a separate frontend.

Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)

What is SSR with slim?

I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim

There's also SSR with react and other js frameworks, but I don't think that's what they meant.

I haven't used Slim before, but looking at the examples shown on the repo's README, it immediately brought to mind the thought experiment: 'what if Haml but Yaml?'

n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.

I’ve used slim for years and it’s incredible. Writing erb now feels painful. Slim is clean, terse, and correct.

The only downside is I am now spoiled.

Slim is really nice for some things but the moment you want to style words within sentences or paragraphs it gets really messy and you have to start using unintuitive syntax like `|<` or `|<>` to get the spacing right.

You can of course just drop to `markdown:`.

Still, I use it where I can on personal stuff, but tend to opt for Erb when collaboration with others is needed.

I'd like to use haml on the front end rather than ugly ternary ridden JSX. I always thought haml was very tasteful.

yep that ^

I’ve taken a rails 4 through to rails 7. Kind of interesting each major version is basically denoted by a change in the way they handle JavaScript.

Rails 5 & 6 were rough, you forgot yarn! That was my biggest pain point. I still have Coffeescript code, we have been slowly converting as needed.

Rails 7 has been a lot better to deal with, we use vanilla JavaScript (outside the coffeescript lol). Makes it pretty easy tbh. We load partials as needed (via js) and the site is fast and light.

My recommendation is to stick close to html with rails or as mentioned, a separate front end. What we have works super well for us, but definitely custom

I'd like to see coffeescript make a comeback.

> Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.

It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment.

As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon.

Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and

- explains what each part does

- is able to spot potential side effects for each new addition

- suggests simpler ways of doing things / nice refactoring

There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.

That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more.

1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems

2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction.

3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.

This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times.

The fix for this is pretty easy though. Keep employees and avoid the churn.

Yes! See my reply to the commenter above you.

This distinction is frequently emphasized in online discourse, but I've never found it to be super useful. Pretty much everyone can agree that Ruby on Rails is a framework, while underscore.js is a library, but things get really fuzzy in the middle.

The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder to use that as a distinction: is React a library since it all starts with createRoot/render (you called it), or is it a framework because from that point on it's calling you? There are tons of people who are highly opinionated in both directions, which suggests that this dichotomy is artificial and doesn't reflect a deeper reality.

It's generally considered a heuristic or rule of thumb. It is not meant to contain any hidden truth and if you've moved past the need of this level of basic heuristic it wouldn't be useful anymore.

I don't know. I've always found that Symfony in PHP is pretty flexible with its setup. I feel the complexity to be proportional to how far off the beaten path I'm going. I've heard that Spring is also like this.

Rails is really flexible, though.

There's something I never see mentioned in this discussion: you can be flexible with what libraries/frameworks you pick, but you can also be flexible with what you build with those.

If doing things exactly the way you envision involves building the world from scratch, it's often better business to go with a "less elegant" solution that can be rapidly pieced together from mainly ready-made components.

I've often earned long-lasting trust and cooperation of clients by asking whether they would like to adjust (or forego entirely) that one feature, if the project ended up being 20 or more % cheaper/faster to deliver. And given that choice, it's surprising how flexible businesses can be.

It could take a lot more than luck. If it turns out to be a rabbit hole stick with react unless you have a really good reason for that kind of refactor

The react code base is written by me, a backend/infra person and it was the first time I used it. It is a mess and the worst is that all the system tests are super flaky because of weird react DOM stuff.

In that case you’re probably alright with the rewrite. My opinion is to stick to React and rewrite the parts you think are nasty.

That’s only because this can turn into a real rabbit hole in my experience. But at that size maybe it won’t be so bad.

Best of luck!

Goodreads is an example of a Rails victim like yours. They customized the app on top of Rails, and it's been so bad that Goodreads is dead in the water and has not received major tech updates despite Amazon throwing engineers at it. Ruby is a dangerous language to refactor, so often you're locked for a long time. See also: Every blog post about Rails upgrades ever (see also: Stockholm syndrome)

> despite amazon throwing engineers at it

Yeah, that is one way of phrasing it. Another way to phrase it is that Amazon took it over, turned it into an ingestion funnel to their book store, and has done as little as possible after that.

Don’t speculate. Listen to engineers who work there https://news.ycombinator.com/item?id=36577444

That's rather ironic, because I read your comment you linked to, and it is pure speculation.

The Goodreads dev said "the site was originally built as a giant pile of Rails spaghetti with views mixed with business logic and such and then a fuck ton of weird features built and left to sit there". I'm not sure why you think that is or ever was "the Rails way", but it seems more like the classic "move fast and break stuff" startup engineering than anything resembling rails to me.

It's just that amazon isn't that good. See the alexa app as another example

See pretty much everything Amazon. AWS, Kindle, you name it. Successful, yes. Technically good, oh no.

Are you sure Goodreads did not received updates because of Rails?

Here is a competitor build with Rails https://thestorygraph.com/

Seems kinda cool. So I think Rails is not the problem here.

Yes. Goodreads received lots of updates, and they were slow and difficult because of Rails (and Ruby) https://news.ycombinator.com/item?id=36577444

Loose typing is a nightmare.

The youngins always learn the hard way.

20+ years of experience here, I happily reach for loosely typed languages in most circumstances.

Can you elaborate on what circumstances you're referring to?

The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context—each career is unique and what projects you've worked on will have a huge impact on your perception of which is preferable.

You perfectly illustrated the point: that there are no maxims like the grandparent comment made. Myself, I work on very small teams, usually building applications that are backend-heavy web apps or filled with tons of async background processing on the server. Applications that are funded by revenue, not VC. Applications where I typically have a high degree of autonomy and responsibility as to maintainability, with usually no insulation between me and stakeholders.

Given different parameters, I'm sure the decisions would be different as well.

Oh, for sure, I wasn't endorsing OP's position! I had another recent thread [0] that was full of highly dogmatic claims on my mind, where I noticed that very few people brought in the context for their opinions.

[0] https://news.ycombinator.com/item?id=37764326

For quick scripts sure.

For writing an application or something that actually require design and libraries? Why bother? You need to be meticulous anyway, why not be meticulous in code?

Literally every application I work on requires design, libraries, and meticulous code.

The focus for me is on the tools and frameworks, not the underlying language. Show me a Typescript-based or Go-based language that can go from zero to production as fast as Rails with the same-sized team with no productivity loss, and I'd happily use it.

Loose typing is a blessing. Reading and writing code with type declarations everywhere is a nightmare. YMMV.

Ruby is dynamically typed and strongly typed.

Good thing that Ruby is actually strongly typed.

Try https://vite-ruby.netlify.app/guide/rails.html

It was almost a drop in replacement for webpack for me

I wouldn't necessarily recommend moving from an existing react frontend to hotwire at the same time as upgrading Rails itself. I'd get to Rails 7.1 first/independently.

FWIW the Rails 7+ way of doing single page app JS is also more reasonable than it used to be. You pretty much just use whatever build tool you want in isolation from your rails app. You have to run something like `yarn build --watch` alongside `rails s` in development but IMO that's not so bad and makes things a lot simpler.

My company builds software to automate Rails upgrades, and offers a full service where we'll upgrade Rails for you. steve (at) infield.ai if that's interesting or you can generate a free rails upgrade plan at https://app.infield.ai/users/sign_up (no cc required). https://docs.infield.ai/docs/creating-an-upgrade-path for some more details.

Don't upgrade your architecture all at once. First bump yourself to rails 7 (including any other gems you can upgrade), then do any other changes you want.

Don't get me wrong, I love Rails, and have been using it off and on since Rails 2.

It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance.

What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I do it rarely enough that it always seems a fight. Eventually I get it done, but I'm never sure why it finally all comes together.

An installer that puts together all the requirements so my rails just works would be great. The rvm installer will set up rails on top of ruby but won't set up the node system underneath it.

Have you used nvm? It’s pretty painless in my experience.

If you opt to use import-maps I think you can get away without needing node these days, though then you're using import maps and have to deal with that can of worms.

thats the whole premise of rails7: dropping the node dependency...

What are you comparing Node to?

Other typical back ends are more complicated (except Go) Java, C#, Python for example

For Java, sdkman is great—essentially as convenient as nvm.

Python is a disaster.

dotnet new webapi - for apis

dotnet new webapp - for crud

dotnet new react - using react

How is that complicated?

I've never done rails, please tell me, why does "ruby on rails" need nodejs for?

Also it's fairly easy to install node. Too easy in fact. I wish it was much harder, and required a degree.

Rails lets you use modern JS frontend tools.

It lets you use modern JS frontend tool but you can also choose importmaps route that comes as default in Rails 7 so there is no need for nodejs and you can also say goodbye to the big folder "node_modules"

It’s still a problem, especially in mid size or large apps. Unless you have someone taking care of the bootstrap process, it inevitably breaks down.

Eventually only one person can get it working so I suppose it’s job security so perhaps it’s not so bad

That’s for every framework though, Rails isn’t that bad, relatively

>I'm a backend guy, I don't understand how to set up node

I understand that Node is mostly known as a frontend tool and Rails uses it for that, but as far as I remember Node was as least initially developed to bring JavaScript runtime to backends.

Even without a package manager node is just a node.exe under Windows, and I think you just have to download and unpack npm and then put node and npm into your PATH environment variable.

I recently set up a new Win11 laptop and all it took was download Node and install it via the installer. You’re up and running in 90 seconds. Yarn was another 30 seconds (npm i yarn). Even Ruby works well with RubyInstaller, and you can normally develop Rails without WSL if you really want to.

The Ruby/Rails community is one of the best and most friendly I've seen. But the worst part of it, by far is the hate for JavaScript.

JavaScript is just a tool, like any other. And it's a very important one like it or not. And like it or not it's going to stay here for a long time.

Just have a bit of an open mind and try to learn the basics at least, it will make things easier.

What led you to think that Ruby devs don't know the basics of Javascript?

I don't think that.

My last sentence on the parent message was directed to the comment I was replying to (which said they couldn't set up node properly).

What I do think is that there's a huge % of Rails devs that hate on JavaScript as if it were some kind of enemy to beat or something, and often that leads to people not wanting to learn it properly.

A couple of Rails versions ago, I had to deal with webpack and that surely felt like an enemy trying to fight me at every step.

Luckily, I no longer need a PhD in webpack or node packages in order to run rails s successfully.

Here is what bothered me with JS and it might sound very stupid:

The idea to have a node_modules that has tens of thousands of folders/files for the simplest package that I needed to install. Ruby has gems, but they have few files, I can easily know where to go to understand how something works or add a debugger.

But just trying to read the name of all those seemed for me always like a task that I dont want to do.

The language itself letting aside some warts is good, can be enjoyed and good code maybe can be written.

One of these should help with setting up a new laptop to run Rails:

https://rails.new

https://rubyonmac.dev

Cool, but why not just use Docker? 2-4GB extra ram overhead and some initial learning curve, add a decent Makefile and.. never worry about local env ever again. Switch back and forth between Mac, Windows, Linux like it's nothing.

Add to this that Rails 7.1 comes with a pre-generated Dockerfile that works quite well out of the box

'asdf' (a version manager) is great for managing nodejs. I haven't dealt with Ruby before, though.

https://asdf-vm.com/

asdf handles Ruby just fine also. I use asdf for Ruby, Python, Elixir/Erlang, Node, and probably a couple more that I've forgotten.

asdf is awesome. It renders useless each language's own version manager.

The latest version of Rails 7 works out of the box with importmaps so no node (nor yarn or any other version manager) is required.

I am hoping for a renaissance of Rails + HTMX with some sprinkles of JS on very interactive pages.

Using Rails with Slim/HAML is an absolute bliss. If you prefer there are also libraries like `ViewComponents` that can facilitate partial rendering even further. Add in some web components and you can build very interactive pages with it. Even use React if you really need it in specific pages.

HATEOAS cuts the complexity of applications drastically. And if you still need APIs, it's extremely easy to respond to different mime types and even have the same endpoints if you desire.

IME the majority of applications that use React don't need it at all. They use React for a couple of menus that have to pop ups. So hopefully once some larger apps start popping up with no React (or only sprinkles of it), it finally clicks for some people how unnecessarily complex our applications are today.

But I already read comments saying they need to switch to React because everyone else uses it. SMH.

One can dream!

The official announcement here: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-relea... has a few more high level details. Looking forward to using some of these new changes (some of the new async query methods will be very useful for some quick performance wins).

Rails on the backend doesn’t get the credit it deserves.

On the front-end it’s been a mess for a really long while now though

I agree. What are options here? Rails in API-only mode?

Yeah, that’s one approach. Works great

But why? So many more performant frameworks for this in strongly typed languages to boot.

Which ones? Never saw another one which comes with the same comfort of batteries included like rails. For example having database migrations built in etc.

Yeah exactly. All that boilerplate stuff is such a pain to write or maintain long term.

Boilerplate is 1% of time, rest is solving real domain problems

ASP.NET (C#) has migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/m...

Migrations are easy to do in literally every framework in any language

> For example having database migrations built in etc.

I actually went the exact opposite route, at least when possible: https://github.com/amacneil/dbmate

Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).

It's really nice when you can generate entity mappings based on a live database, like with https://blog.jetbrains.com/dotnet/2022/01/31/entity-framewor...

So in my case, I can have:

  * a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
  * a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more
  * a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server

Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!

That’s what a lot of people do. The value is still about convention over configuration IMO. If we are building a REST API, typical CRUD, you can go a long way with using Rails there and using something else when you need the performance or a certain feature.

The performance of Rails serializers is still a nightmare. God awful performance.

20 years on…

“Just use another framework when you need performance” they say.

Also 20 years on the http client still doesn't have proper timeouts.

> The performance of Rails serializers is still a nightmare

Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible.

But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent.

This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.

> It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible.

Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?

Python, PHP and JavaScript have significantly better performance for cpu-bound programs.

E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.

I remember looking at BSON de/serializers for some perceived performance issue a while back, ruby was only marginally slower than PHP for the same task, which was just pulling big record sets back from the db. Can you elaborate?

When was that? I ask because PHP made large improvements to performance in the last few years.

Sometimes it's more than 2x faster than before. They now have JIT and are planing to have an intermediate language for even more speed.

Most PHP stdlib code is pure C/C++ so it tends to be very fast, but I'm guessing Ruby is the same.

It was about maybe late last year/Jan this year. When you say intermediate language, do you mean PHP has a bytecode interpreter instead of AST? At the time I looked at it, to convince myself there was no issue with Ruby, I actually hooked up the same table/query to PHP and used PHP's excellent profiling tools, then compared those to the Rails profiler. There wasn't a great difference. PHP was faster sure, but there was definitely no knocking Ruby's speed.

Ruby is strongly typed.

Excuse me. Statically typed.

There is no agreed upon definition of "strongly typed", so it depends on your interpretation of that term.

Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed terms.

Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.

For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.

Can't use any of them on a plane.

I think that’s pretty much it for big apps if we go with batteries included. Only Java frameworks compare on that front and if you’re a Ruby guy you likely don’t like Java.

I’ve been liking Golang but I haven’t had a job that used it in a while. Who knows what’s it’s like right now

I love the new hotwire stuff. What don’t you like about thd front-end?

Asset pipeline is a hot mess: https://fly.io/ruby-dispatch/making-sense-of-rails-assets/

Propshaft should bring sanity back to it, but its going to be a while before that's mainstream.

That has been a hot mess for almost a decade now.

This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets

I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release.

Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.”

Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to constantly change to keep up with the new One True Way™, only for it to be replaced with another assets strategy powered by a gem with a cute name.

RJS and Prototype, then UJS and jQuery, then Sprockets and CoffeeScript and Sass, then Turbolinks, SCSS, then Dart Sass, then Stimulus and Webpacker, then esbuild and TypeScript, then Turbo, then import maps but there’s also jsbundling/cssbundling, then Hotwire, then Strada, then “Turbo 8” and TypeScript is suddenly phased out because DHH doesn’t like it, and now Bun.

I’m probably leaving something out and this is certainly out of order. But my point stands: the prescribed way of handling assets with Rails is ridiculous.

> But my point stands: the prescribed way of handling assets with Rails is ridiculous

What would the alternative be for a 20 year old project?

I think what we're seeing is a natural progression based on how the web changed over the last 2 decades.

I'd be more concerned if Rails didn't change and `rails new` produced a jQuery / SCSS / CoffeeScript loadout and made it difficult to use modern tools. Now it's easier than ever to plug in whatever front-end you want.

I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

There's a point when change is just too much and the returns are diminishing.

> I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

How tho?

Things naturally progressed from a lot of asset related things with few choices being baked into Rails to being more componentized but still tightly baked into Rails (Webpacker) to even more componentized and mostly decoupled from Rails (current state of things) to even more decoupled from Rails (Propshaft).

Current day if you want to use Webpack or esbuild or something else or nothing it's easy because Rails no longer cares. It only cares that assets end up in a specific directory. How they get there is up to you. The framework also provides value by giving you generators to tie things together based on the choices you want so you don't have to figure it out individually from ground zero.

If you look at it from that perspective I think things unfolded reasonably well.

Personally I didn't like Webpacker at all. Webpack was complicated enough on its own and then having to learn the Rails way of configuring it made it even harder. But I think it was a good tipping point to demonstrate that from a maintainer's POV it's hard and time consuming to create good abstractions over front-end tools on the back-end and from an end user's POV it's bad because of the complexity.

Being able to look directly at esbuild's documentation and apply it 1:1 is a much nicer outcome for everyone. Maintainers don't have to keep up with every change and users don't have another layer of abstraction to deal with.

It did take Rails a while to come to this solution but it's really good that they did. This is how I managed front-end tools in Flask and other frameworks for around the last ~decade. You have the framework look for assets in 1 spot and how they get there is up to you. It was easy for me to do that because I only had to make it work for my apps, my client's apps and the starter apps I posted on GitHub, but applying that to a framework that has hundreds of thousands of people using it is for sure a bigger project.

I think a lot of communities assumed letting JS asset pipelines manage JS, CSS, and image assets would lead to a better future. Sadly that didn’t materialize and it inflicted a lot of damage on DevUX.

Today the perception is that the JS community doesn’t seem to care about providing a stable experience for those outside of it, which is why projects like Rails and Phoenix are successful with “No/Low-JS” features.

Where Rails screwed up is not updating their docs to reflect this new reality for a really long time. It wasn’t clear what people should be using. They’re still creating confusion by making it unclear if Turbo is for Rails or all web frameworks, which you’ll notice when you go to the Hotwire landing page and see no mention of Rails.

I've just removed sprockets from my Rails app and replaced it with propshaft, jsbundling-rails and cssbundling-rails. It took a couple minutes max. Now the "frontend" parts are no longer tied to the rails app, except you get a nice integration with rails assets:precompile and including the final bundle is as easy as ever with Rails.

And this version added Bun support :)

> On the front-end it’s been a mess for a really long while now though

I don't disagree, but also front-end was a mess for a long time.

Now Rails (with Rails 7.1 + Hotwired + Importmaps) is a pleasure to work with.

But we had to wait for good support in browsers of at least ES6 + Import Maps.

See the date of this article here: https://web.dev/import-maps-in-all-modern-browsers/ -> 28 March 2023 announcing importmaps is available on all modern browsers.

Thus there was no way around Webpack Yarn or any other helping tool for JS until now.

Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.

A friend of mine joked a couple weeks ago that if a Rails release is announced but I hadn't submitted a PR (to upgrade), has it really happened?

Well, here we go, PR coming up. Even if it has to stack behind the 7.0 one that's been sitting there for months.

In my experience many teams have problems establishing a clean code base with ActiveRecord.

Don't beat me, but still on rails 4.2 and happy... Gives me everything I need for no/low JS backend SaaS stuff I do for my self and B2B companies, running on low end VPSs...

If you have time to answer - why would I upgrade?

I also use older versions. Firstly make sure you can upgrade to the latest patch/minor version.

The main thing with older versions is vulnerabilities in associated gems, e.g. nokogiri which you can't upgrade without a major rails upgrade. However most apps don't do fancy XML parsing for example so most vulns are not applicable. So there is a bit of maintaining to ensure things are safe. Often you might add in a monkey patch to cover a bug.

Upgrading therefore makes it more secure and lowers maintenance time. However there's the cost of the non stop upgrades to factor in. Another factor might be faster Ruby support in newer versions.

(Generally when I make a rails app I use the latest release but I don't upgrade the rails version afterwards unless it's popular or the app is very old and stuff doesn't work on newer systems)

For security.

I really like Rails and for a long time I used it and lived fairly well off of it.

I used to make good money doing upgrades from one version to another as well...

I hear your gripes here... I think with Rails if you run into problems, this is because you created (or someone in your org) them for you.

Are they gonna change the governance at the last minute like with Turbo?

What happened? I missed the drama.

DHH removed TS from Turbo, posted a pretty inflammatory blog post about it and then got surprised when people reacted badly to it. Classic DHH stuff really.

A significant part of that ""reacted badly"" was a bunch of kids and YouTuber idiots spamming GitHub with meaningless comments, issues and PRs. Those people don't come out of it looking respectable, regardless of DHH's approach.

I mean yeah sure but DHH does seem to enjoy the controversy a bit. Either that or he’s really good at unintentionally courting it.

There's nothing unintentional about it, it's a strategy they employ since 2006/7. They have an entire chapter about it in their first book "Getting Real"[0]:

> […] One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you’re feeding people a story they want to hear. Not only will they understand your product better and faster, they’ll take sides. And that’s a sure-fire way to get attention and ignite passion.

[0] https://basecamp.com/gettingreal/02.5-have-an-enemy

I hope to see the Hotwire dependency dropped one day. I love Rails and Hotwire, but I wish the latter were also a community tool. When TypeScript support was discontinued, DHH commented:

> This project has been founded, funded, and maintained predominantly by the resources and investment of 37signals. We will set the direction as we see fit...

With TensorFlow recently discontinuing support for Windows, it's very concerning to me that one day one person or organization decides that "we will set the direction".

They don't even try to use nicer language. Don't get me wrong, I respect the work and effort. But 37signals are no saints. There was a scandal, and employee exodus not so long ago.

Hotwire is so deeply integrated into Rails, so Rails is even more 37signals' tool than ever before. Before we had webpack, and JavaScript libraries that sometimes were not easy to use. Now things are easier, but instead of JS libraries we've gotten 37signals dependency, which is VERY concerning.

The Turbo incident was none. It just wasn’t. I would not have dropped TS but the change barely matters. I have only ever seen it used in a script tag and the code reads well enough in vanilla.

The actual incident was a horde of morons piling on top of that repo in the days that followed.

None? They ignored multiple instances of community feedback. Broke countless current PRs and upstream libraries. And moreover, going forward I expect another surprise from them. Another surprise that I ain't gonna like.

Rails backend is in a good shape, but I don't like being dependent on a dictator's decisions on the frontend. I don't understand why Rails team don't understand that.

But from the other side I'm thankful to DHH, because now I use more Elixir, and Crystal. Those are awesome tools, and 37signals-free world feels so much better. It's not toxic.

For me it made a lot of sense. Ruby developers don't like types as much as in other languages. By far the majority of Javascript made by Ruby/Rails developers is vanilla. Turbo is a library used mostly by Ruby/Rails developers.

As a Rails developer myself, it was much harder to contribute to Turbo. I had to learn Typescript before doing so, which makes the bridge too high.

90+% of the people who were complaining didn't even know Turbo existed.

Could it be communicated a bit better? Yeah sure, I give you that. Is it bad moving forward? Maybe initially as there were broken PRs but I think eventually it is in a much better place. In my opinion.

Would anyone start a new project with Rails today?

If someone suggested using Rails for a new project to me today, I would show them the door.

There are so many more mature frameworks in more robust and performant languages.

IMO the only reason to use Rails today is if you’re too uncurious to learn something better.

Please name a few with the same comfort of having most things built-in. One example: database migrations. In the JS world it is knex all over and it is much less comfortable than ActiveRecord.

Phoenix

With Ash, even more attractive.

I really need to check Ash out, it seems be a rising star!

Personally I would rather use Fastify+MikroORM.

Or Asp.Net.

Or Flask with SqlAlchemy + the migration and validation libs(marshmallow?)

Or whatever is good in Golang.

> Or whatever is good in Golang.

There is no such thing in Go and most likely will never be given the perspectives held by the greater Go community (less is more).

Comparatively, the Ruby community is the complete inverse: any perceived friction can and should be abstracted to be (subjectively) nicer. It's why some people love the language, and it's also why some people dislike the language.

And none of those combinations reach 5% of the features Rails provides. These answers are incomplete and hide the underlying problem: You have to tie together 10s of third party libraries or services, or alternatively reinvent the wheel and implement everything from scratch. That's the point.

Asp.Net has 5% of the features of Rails? Which 5%? What of the 95% missing do you need?

Sorry, I don’t know anything about Asp.net.

My comment definitely applies to the other two options you listed.

I wonder if anyone here has used ebean and the generated db migrations? I was looking for a java ORM that's like Django's ORM with the built in generated migrations tool which is great for a lot of projects - it seems like ebean is pretty much the best choice? and now with virtual threads I don't have to worry that it's not reactive.

ASP.NET Core. And database migrations are not uncommon in web frameworks at all.

Easily ASP.NET Core + EF Core combo thanks to strong typing which is a developer productivity boost in back-end, and performance on the opposite end of spectrum suitable for high scalability.

(but then again, if you are doing complex migrations through framework in-language, you might be setting yourself up for failure)

Why not? I have seen or worked on too many projects that would have been better off using Rails/Laravel/Django instead of whatever cobbled together mess was chosen instead.

Not saying that those are the best choice under all circumstances but they certainly aren’t wrong.

The alternative to Rails is not "cobbled together mess".

It is not, no. But for whatever reason too many people gravitate to an unreasonably bloated and badly constructed mess of tools and things and services. All for the sake of planet scale.

It's either a cobbled together mess or reinventing the wheel (framework). There are not many more options.

Looking at the new Hotwire stuff. It’s neat from a technical perspective but looks dreadful to me. Why double down on a sloppy backend language when hardly any of the needed logic for a web application is backend? Especially when the alternatives include a full stack of TypeScript, a robust, performant, strongly typed, fantastically tooled language?

I was an RoR developer for a decade. These code bases do not age well. The test requirements of loosely typed languages are so much greater. The lack of ability to automate refactors alone is enough to avoid ruby.

What would be fully stack TS alternative to rails?

Ha, that's the problem! Everyone will give you a different list of 143 packages (minimum).

Also, the list they gave you will be different next month.

Last time I checked it is perfectly possible to use anything including TS via jsbundling-rails and esbuild, so honestly I don’t understand what is the problem here.

I’m also on a fence re Hotwire, but apparently it works for them in Basecamp and Hey, so that’s what they are investing into.

Anecdotally, recently in Ruby shops I see an increase in new projects using Hotwire as a push back against bloated and hard to maintain React front ends and people are delighted how everything is easier now. RoR codebases are not the only ones which did not age well, I’ve seen quite a few React/NextJs legacy projects I would prefer not to touch at all. So I don’t think technology is the main culprit here.

In my experience codebases that do not age well tell more about the developers and the managers than the tech stack.

I've seen marvels and disasters in every stack.

Python is slower than ruby.

> There are so many more mature frameworks

Please name "many more mature" frameworks. I am curious about how many web frameworks are still actively maintained today.

Please note for me, mature also includes age. So you have to state frameworks that are at least older than 2005 (I would also accept created in 2005).

Rails is great for new projects, the opinionated structure and the Convention over Configuration is what makes it scale well!

I am Rails dev, and I don't like the fact that Rails in every new version has to REINVENT ALL THE WHEELS, ALL THE TIME. That creates huge problems for Rails devs and stakeholders.

Rails is based on Ruby, which is backend language, and Rails should stay more on backend.

That means

  - session management
  - routing and controllers
  - many API options (REST, json-rpc, ...) + JSON object exporters
  - ORM, Mailing, etc
  - server template renders (ViewCells are still not part of Rails)
  - tasks, logging and other helpers

In the same way Rails adopted rake gem as default task runner, without re-inventing it as "ActiveCliTasks", they could have created standardised connector layer that will exchange objects between backend and frontend.

So no Stimulus, TurboLinks, HotWire and other stuff one HAS TO learn and re-learn between versions. Svelte, Vue and React should have been officially supported with thin connectors. Rails server render layer can easily be integrated in any existing frontend tech, as alternative to React server components insanity.

Also, there is no reason to have to have socket connection to pass HTML between server and client, good old RPC is just fine as 99% of big app scaling problems are Database problems, no need for another layers of complexity one has to ensure it works.

I think, in that way Rails could "shine" far into the future, using its strong points but adopting new frontend stuff on the way, not re-inventing it all the time.

And chances are, new Rails projects will just be API backends with React frontends.

Also, if trying to do lightweight Javascripty frontends within the framework is important, we might as well just move to Phoenix. Phoenix is arguably better already... it just requires a moderate jump to learn Elixir (which unfortunately looks very much like Ruby but requires a very different approach to writing).

Phoenix is super fun, but it is in completely different realm than rails :)

What about all the gems Ruby has, does one really have all he needs inside Elixir/Erlang? More complex stuff like NokoGiri, Haml, etc., that works well and is maintained.

Are you seriously comparing the speed of changes in Rails with React/Vue/Svelte?

People just look for ways to justify their already taken decisions.

Reply on news.ycombinator.com