[clairity]

i think if rails continues to push hotwire (turbo + stimulus, and perhaps strada?) and get a coherent story on view components, it will continue to take mindshare from the js hype of the last decade. mobile dev is in decline, and browser makers just released web notifications, web app support, webtransport, page transitions, etc., so the backend has largely reached parity for cross-platform development. no longer is json the natural data exchange medium for apps, but rather chucks of html that can be plopped right into the dom without js having to massage the response into shape on the frontend. js can return to being a frontend scripting language, its natural habitat, rather than being shoehorned into being a do-it-all platform language.

[d3nj4l]

I've been building a webapp with Rails on and off over weekends. Several times over this process, I thought through some of the architectural decisions and naturally realized that the "Rails way" was the best option to pursue. It's not just because I'm using Rails - my most recent webdev experience was with a SPA driven by a Java backend. I'm sure there are tradeoffs involved (what doesn't?) but with every passing day I use Rails the more I appreciate the decisions it makes for you.

[graypegg]

I’ve had the exact same experience! I’m getting to use some new JS SSR frameworks at work (Remix) but I keep using rails for my own things. Gets out of my way.

[d3nj4l]

Remix is pretty nice too, and I appreciate it for bringing Rails-style SSR to style in the React world before RSC, but the power of Rails is from having a complete platform to build your apps on. I don't need to string together five different libraries to implement authentication and e-mails, that comes more or less built into Rails.

[noelwelsh]

Can you recall some of these architectural decisions? I think that would be interesting.

[d3nj4l]

Two decisions on the top of my head:

- I wanted to make an index page where a user could make edits to the items being displayed and make regular show/edit pages for the item so if a user was on that page they could edit it. This is actually really useful: a user can bookmark the page for a specific item, or open it in a new tab, or in general do things browsers let you do but apps struggle with. Making two different edit components would be stupid, and I thought this would be one of those things that I could do better in React than in Rails. After looking around a bit I quickly found that if I used standard REST-y routes and wrapped the key parts of the view with turbo frames I could get exactly what I wanted, and it worked out seamlessly. In general, I've found that Rails' heavy emphasis on REST was a good architectural choice, and every time I disagreed with it and went another way I ended up regretting that choice and reverting to REST.

- In the Java world, you typically have thin models + a service layer which has the business logic. This is apart from other layers such as Repo/DAO etc, which I was already replacing with ActiveRecord, but I was initially resistant to putting all of my business logic in the models, especially if it involved logic across them. But it also hurt discoverability. I was working on a project I was expecting other people to work on with me, and I wanted to make it easy for them to figure out what they could do with a model object. The solution to this came from DHH himself. I've lost a link for this, but he said that if you make service objects, you should add a method on the model that acts as a way to reach the service. This keeps the model "fat" while also separating out logic into simple, unit-testable classes.

One of the smaller things I appreciate is keeping all of the routing details in rails routes. I know other frameworks like Django also do this, but I really didn't like this about most Java frameworks and microframeworks in other languages.

In general, if you're interested in seeing how to architect Rails apps, I say study how 37Signals does it. Playing around with Basecamp convinced me of the practicality of the Rails way and taught me a lot of interesting and useful patterns.

[twic]

> mobile dev is in decline

This is news to me. Is this really true?

[clairity]

i don't have rigorous data at hand, but browsers and mobile hardware are now good enough that most apps are just fine being developed using cross-platform web tech rather than java or swift. plus, apps no longer attract and retain users as they once did (we're past the hype cycle). native mobile, as a result, has retreated to domains where the tighter integration has benefits, like games, health, IoT, etc. even apple is loosening its iron grip over its app store as the tradeoff between integration and flexibility no longer makes sense for most apps. apple now focuses more on content and on integrating more functionality into iOS itself because of that.