[brightball]

I don't know why, there are tons of smaller companies using it. I have a lot of languages and experience on my resume and the one that consistently gets me the most inquiries at the highest pay grades is still Ruby.

Anecdotal I know, but from the moment that it appeared on my resume in 2012 it's been non-stop. Probably 80% of everything I hear about.

Ruby and it's ecosystem brings the closest thing to natural Aspect Oriented Programming that I've seen in the wild, which is why it's so much more productive than everything else I've tried.

[LapsangGuzzler]

> I don't know why, there are tons of smaller companies using it.

Longtime rails dev here. The reason smaller companies are using it is because you can move much faster working on a full stack rails app that gives you SPA-like functionality without needing to incur the performance or operational cost of a dedicated front end.

I've worked for both rails shops and JS shops, and the productivity achieved with Rails is staggering compared to React in a small team environment. Guillermo Rauch tweeted a few months back that SPAs were a zero interest-rate phenomenon and I completely agree. Just because a bunch of companies jumped on the JS hype train doesn't mean that they were all making the right decision.

[pcthrowaway]

> Guillermo Rauch tweeted a few months back that SPAs were a zero interest-rate phenomenon

Guillermo Rauch is selling Vercel, whose strategy includes first-class tooling for SSR, convincing people to move their SPA to SSR, and then locking them in on their platform.

[Rauchg]

Except my preference for SSR as the default dates as far back as 2014 and is rooted in the laws of physics[1] Downloading an empty shell, downloading code to render a bunch of spinners, to then incur in a bunch of waterfalls of data and more code to the server is not gonna make it.

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

[pcthrowaway]

I mean those are fair points, though respectfully I think there are cases for SPAs where SSR won't do. But that's not what we're talking about.

Referring to SPAs as a "zero-interest-rate phenomenon" implies that SSG/SSR models are more efficient in terms of financial cost of deployment. I don't agree this is necessarily the case, and I think SPAs can be developed and deployed sanely and cheaply also.

Vercel is doing some amazing things, but it's also innovating in ways that occasionally lead to "lock-in", in the sense that moving away from Vercel would involve a lot of friction. So I think it's fair to point out that you have a financial interest in convincing people to adopt delivery models that your business streamlines.

[LapsangGuzzler]

Sure, he's trying to create a business that I'm not particularly interested in being tied down as well. That doesn't make him wrong about SPA.

[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.