Rewrite it in Rails

Discussion two days ago, 239 points, 219 comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42024246">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42024246</a>

I spend a lot of time each year evaluating frameworks for our clients and their projects, and I keep on coming back to rails.<p>&gt; Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It&#x27;s typically caused by developers, not programming languages or frameworks.<p>After running a number of rails applications in production for going on a decade, this is really hard, and I find it to be one place where rails (really ruby) doesn&#x27;t help much.<p>Of all the languages we work in (and it&#x27;s quite a few), ruby has the worst support for modern language tools: the LSP implementations are weak, and don&#x27;t play well with containerized development environments. Typing efforts are fractured, and the official way is... well.. it&#x27;s bad. This is exacerbated by ruby&#x27;s tendencies towards &quot;fluent&quot; interfaces, which is actually code for lots of methods that take undocumented hashes of arguments --- and hash access with strings and symbols? nightmare fuel.<p>But I still come back to rails. It&#x27;s productive, it&#x27;s fast enough, it scales just fine, and perhaps most importantly there&#x27;s a &quot;right&quot; way to do just about everything your web application will ever need to do: background jobs, websockets, read-only database replicas.<p>All in all, its still my recommendation for new web projects going into 2025.

&gt; It&#x27;s typically caused by developers, not programming languages or frameworks.<p>Best sentence in the article. I’ve worked in well-organized and reliable PHP apps, and giant buggy abortions in TypeScript. Lots of Rails apps with varying degrees of quality. Languages and frameworks can’t fix disorganization, poor architecture, laziness, or most of all, ignorance of how the Web should work (and <i>why</i>.)<p>The main predictor of how good your app will be technically, is the skill level of your worst developers + how much your best developers care (or are allowed to care, which necessarily varies with business conditions). Regardless of if you’re using trendy languages like Rust, TS, etc.<p>Of course, while as hackers we desperately wish for the app to be of very high quality, the sad truth is that companies who always obsess over the finest details under the hood don’t tend to perform as well financially as the ones who make compromises to get things to market faster and pivot more effectively, so I think that’s why most of us have rarely worked in commercial codebases where nothing is embarrassing.

Over the last few months I evaluated django, laravel, and rails by doing their tutorials.<p>So far rails has been my favorite to rediscover, I used it 10 years ago and boy has a lot changed!<p>I was hoping to like django more since I&#x27;m a professional python dev, but django felt like I was still clobbering together libraries (whitenoise, celery, etc) and it doesn&#x27;t have a great front end story.<p>Laravel was super slick, but I just can&#x27;t do PHP. I know it&#x27;s come a long way but it&#x27;s just not for me.<p>Rails really stuck for me the most and I really like the hotwire paradigm. As a dad with limited time for side projects Rails is going to be the tool for me now to spin up something quickly.<p>I&#x27;m actually porting over a current side project to rails and stumbled on this magical gem called &quot;Brick&quot;[0]. You just point it at your existing DB then it reads the current state of the database and makes active record models in memory for you to play with. You can then eject the models and controllers into your code base, and bam you have your model layer recreated in rails.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;lorint&#x2F;brick">https:&#x2F;&#x2F;github.com&#x2F;lorint&#x2F;brick</a>

Many make the same argument about Laravel, Symfony, ASP.NET, etc.<p>There&#x27;s a huge amount of value in having an ecosystem of components that are designed to work together, and randomly choosing &quot;oauth X&quot; and &quot;smtp Y&quot; components and trying to string them together, vs using a battle-tested and supported stack, just invites a lot of hurt.<p>If you have a team of Java web app devs, having them build a web app in Rust or Go will be incredibly costly and inefficient. It seems very obvious to me, but I still get people that say &quot;oh, it&#x27;s not that hard - library X can do all of that other stuff&quot;... but inevitably it can&#x27;t. And the communities of people doing web app stuff in (Rust, Go, Scala, etc) just aren&#x27;t big enough to provide the community support other frameworks provide.<p>Kudos to the author for their epiphany.

The problem was choosing Rust and SvelteKit over Elixir with LiveView (Phoenix) - especially coming from Rails where it’s an easy transition due to shared philosophy and even syntax to some degree. Rust is neat but complex and probably overkill for a web app. But yeah, in general - innovation tokens cost time vs what you already know.

What about Rails and Svelte? While many people are doing things with full stack Rails, there are just as many using Rails (whether as a monolith or separate backend from frontend deployments) with modern JS.<p>Actually, in recent Rails versions the mistakes of Webpacker have been replaced with much more flexible gems for building frontend assets with esbuild, vite, or any other build tool.<p>This gives the ability to seamlessly blend the nice pre packaged rails ecosystem with the nice ecosystem of react components or other modern frontend tooling most people are using.<p>I close this comment with mentioning: you still may not need all of that new stuff! What does your app actually do?

I&#x27;m not surprised that this conclusion was reached after trying to use Rust for a web development project.<p>Rails&#x27; is what people are going for when they choose it, not Ruby (generally speaking... there are obviously people who like Ruby). Rails provides all of the tooling, conventions, and ecosystem needed to tackle a great deal of web development projects.<p>Rails is a great example of a <i>killer application</i>. People learned Ruby just so they could use Rails. Wanna make a bread-and-butter website, just build it in Rails. Three-quarters of what you need is available in the framework itself and most of everything else is a library that integrates seamlessly with the framework.<p>If you need to use a systems-level language to solve a technical problem, you&#x27;ll know exactly why you need to go through the trouble. If you&#x27;re using maxims to justify your choice, you have no idea. &quot;Because it&#x27;s blazingly fast,&quot; doesn&#x27;t matter if -- as the TFA points out -- your most heavily-trafficked endpoint is serving a p90 of &lt; 400ms, your team is delivering the features you need on time, and your users are happy.<p>I think there are lots of good reasons to use a Rust-based framework. I work in Haskell full time. I get it. But there are huge trade-offs. The most obvious one is that almost no SaaS or open-source components you use will ship Rust or Haskell SDKs. They will ship libraries that integrate with Rails.

Too bad you didn&#x27;t choose Phoenix&#x2F;Elixir. Give it a try, and never come back to Rails.

This isn&#x27;t really an argument in favor of Rails so much as it is an argument against being indecisive and scattering your efforts too widely.

Dupe <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42024246">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42024246</a>

Changelog had a podcast come out with David Hansson (the creator of Rails) a few days ago: &quot;Rails is having a moment (again)&quot; <a href="https:&#x2F;&#x2F;changelog.com&#x2F;podcast&#x2F;615" rel="nofollow">https:&#x2F;&#x2F;changelog.com&#x2F;podcast&#x2F;615</a><p>I&#x27;m not a particular fan of Ruby itself but I can appreciate the value that Rails brings. The interview with DHH was quite interesting... DHH is not someone I find I&#x27;ve always agreed with but his opinions nonetheless always seem reasonable and thoughtful. It seems useful to have someone that Zigs when the rest of the industry Zags.

Rewriting really improves the quality of the code-base, because it increases our understanding of it, and allows us to replace stupid designs with better ones. Using adifferent language or platform forces you to rewrite much of it, with the same or better design.<p>In my opinion the ionvestment is not so much in the code, than in the design.

I couldn’t help but notice that he was working with two extremes, ruby and rust. A nice middle ground could have been nodejs with TS, with the advantage of using a single language throughout the project. While nodejs doesn’t have something like rails, its ecosystem is largely centered around building web applications.

Rails is having a comeback

I do think LLMs change the game a bit. Rails is nice because of the ecosystem and how magic and expressive it is but LLMs can generate and maintain a lot of the boilerplate while they&#x27;re less good at debugging the magic when it is misbehaving.<p>I am working on an app that has a frontend in Django and the backend in Go and when I make changes to the Go side I just feel a lot more confident it&#x27;ll all work as intended. Compared with Django I keep finding myself in the weeds debugging why some random dependency is misbehaving which is difficult because python allows you to do some really heinous stuff like instantiate classes that are chosen using runtime configuration.

Rails still gets the job done. That&#x27;s what you get paid to do -- the job!

Excellent article. This is why I have tied my livelihood to Ruby on Rails.

Forget Rails and embrace Sveltekit. All the magic of Rails can be achieved in any framework with LLMs.