Rewrite It in Rails

Rails (and possibly Django and Laravel) are just light-years ahead of any other stack for building web apps. They have dealt with all the tedium, know all the requirements, and actually get out of your face when building an application. I have been developing web apps for 15 years now.

I have tried Meteor (back in the day), Remix, Nextjs, Node w/ Express, etc. Always talking about how much better they are. But in my mind web dev is a solved problem. The js stuff is mainly just developers wanking off, driven by a bunch of dollars from big companies.

Systems stuff, deployment infra, etc. is great for stuff like Rust & Go, but shoehorning into web dev makes no sense. I would love to just move on from this debate but it seems thats going to never be possible.

I'm working with Rails for 17 years now, still love it and still prefer it even for the frontend. It give you all the options to separate your code without the head of your files becoming a unnecessary long list of `includes` like I see in the angular app I have to work on for a client. I don't see a disadvantage in splitting logic and markup for the frontend, it allows you to test the logic independently and normally when you hunt a bug you should know whether it's in the markup or the logic. Tracking down a bug thus becomes more easy.

I've written my fair share of far too long ruby methods, 200 lines and more, but those are truly my fault. With a more granular unit test regime those can be prevented.

Great real world article. Everybody should keep the bottom line "under their pillow":

>> Interestingly, all of the things that used to annoy me about Ruby and Rails now annoy me much, much, much less. I have accepted that there is no perfect language or framework. You just have to know its strengths and weaknesses and deal with them.

Rust is a language built by extremely smart people, unfortunately their focus is more on type theory and sparing few allocations than building something useful and coherent for blue collar devs like me. When I read a blog post on rust, I literally don't understand half of it, although I'm working with rust since 2020.

Writing large web applications in Rust isn't going to happen fast. Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.

Choosing something like Java, C# or Go might not sound sexy or cool, but with get the job done as fast as Rails while running almost as fast as Rust. That choice will also generally mean less bugs and a having a project that is easy to maintain and extend.

We recently started testing AdonisJS as a TS alternative to rails.

I'd recommend anyone who'd be interested in "Rails, but in TS" to give it a go.

It feels much more similar to rails (or Laravel) than the most popular TS stacks, and also has "batteries included" instead of leaving you to decide on every part of your stack (or trust a template from a third party).

The reason NextJS and similar tech like SvelteKit are so popular amongst JS developers is that they alleviate the problem of Node.JS not having a great backend development experience. Building a backend in Typescript is like building it in C#, but without the advantages of a properly designed language. The experience of building a backend in Rails is miles away.

Node.JS developers are starting to realize it's not just about having the ecosystem and the tooling, it's also about the framework being a holistic solution to building out your application. That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.

I'm a little confused about the comments here saying Rust is not great for web backends. I've had the opposite experience, building mostly small services like beampaint.com and probablyup.net. Maybe the complexity goes way up once you try to build a bigger app? I mean surely it does,but Rust is great at giving you confidence where you need it when you have large code bases

This article is kind of the story of my life… I launched a SaaS app written in Go in 2013 coming from Rails and I had to figure out everything on my own. Migrations, database layer, asset pipeline, deployment, validations, logging, payments and so many more things that rails just give you.

I’m the same with Django.

I’ve found that perf issues were much more often caused by the DB queries than by Django itself.

Using Rust for a CRUD application is a terrible choice. Of course it won't work.

It's like using Rails to write a database or a DNS server. You're just trying to use the wrong tool for the job.

I want to try Rails but I can't downgrade away from static typing for my personal projects. I typically want to spin them out quickly and not worry about writing tests: static typing adds way too much value in that scenario.

I looked into Ruby's static typing attempts but the picture painted was grim.

It’s fascinating to me to see that nowhere in this thread, at the time of writing, is mentioned what used to be the darling of web development, a language that seduced many ruby developers to crossover: Clojure. The times have changed.

I much prefer Rails to say Django, but I wish decent typechecking were possible in Ruby. All the options I’m aware of (Sorbet, header files, etc) are all so inferior to Python’s typing syntax that I feel like this alone makes me not want to use Ruby/Rails for web projects these days.

I think decent type checking can fix many of the usual bugs people encounter, but the syntax for types at least needs to be decent.

I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more performance or correctness on complex tasks, there were some Java services and some Postgres sprocs.

Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce".

I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system.

There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.

This was a great read. Thanks to the author for the vulnerability.

In this thread and others, HN does a lot of talking about the fixed properties of these languages and frameworks.

Something I don’t see much is: choose the tool that you and your team are most familiar with.

It’s relatively easy to learn a new language, but it takes a long time to learn an ecosystem. Learning that ecosystem takes time away from focusing on your customer.

I recently started a new web app and tried to use Django because of the batteries-included framework “should” have been the right tool for the job.

But I haven’t used Django in 15 years and it was slow going. After a few weeks of slow going, I rewrote the whole thing in Typescript in a week. Not because of any general argument that TS is better, but because it’s the ecosystem I know well. Not by choice, but as a function of the jobs I’ve had.

I’d like to suggest that it’s okay to choose the tool you’re most familiar with, because you’ll move faster, write better code, and frankly web apps can be written in any of these languages.

The keys here for me...

> After probably a good year of writing Rust and Svelte, it dawned on me that our users didn't benefit from any of this.

> With days and often weeks on end being spent on adding absolutely no direct value

> these last weeks I've felt very productive again, building new features, improving existing ones, updating the UI, fixing stupid bugs. I also really enjoy working more closely with my colleagues who use the application all day, every day and figuring out how I can make the product better for them.

Rails is GREAT at solving PRODUCT problems very quickly and very effectively. In the right place there is nothing better at building _products_ or making engineers incredibly productive.

It's not the only tool in the toolbox, but it's always been one of the best to solve early applications and proofs of concept

This is a nice enough article considered as an experience report. It’s tempting for me to focus too much on the title (was it a rewrite in an interesting sense? no, it was like going on a five-year trip across Asia and returning to your hometown to marry your high school sweetheart[1]).

It doesn’t seem like the author learnt that much. They know Rails and Rails is good for making webapps? Makes sense.

[1] For the author. The rest of the team didn’t know Rails. And there was no one on the team that knew that rewriting parts in “blazing fast”-lang would work.

Laravel with Filament is super productive also. Django used to be my goto for 15 years but the frontend infra, Livewire, and flexibility of Filament compared to django-admin are hard to beat.

"I couldn't horseshoe a hard systems language to replace a web framework for a CRUD app written with soft language, so I had to go back"

Rails is very good until you need to go off rails. Even in that case rewrites must be partial and not to aim to fully replace the original. Most of the time rewrites are a waste of time. This article could be true if you s/Rust/Ruby and tell the story in the opposite direction.

Rust is fine.

The worst is TypeScript and Node.js.

A lot of startups are making their code bases in TypeScript. And it is an unbearable mess.

I recently consulted with a company where I rewrote their app in Rails. And now it's much simpler, much better, much more extensible, and far more enjoyable for the developers to work on it.

Not getting this one. Programmer writes app in framework he knows experiences productivity?

This:

"Have many issues at runtime? Test more. Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It's typically caused by developers, not programming languages or frameworks."

React plus Rails is my favorite modern combo. Development bliss.

https://github.com/shakacode/react_on_rails

Rewrite it in any framework that _doesn't_ make you dependent on platforms waiting to milk you dry when usage takes off.

Imagine if the author had tried Phoenix and Elixir with its amazing OTP foundation…

Somewhere, DHH is reading this and smiling…

Boring tech is great!

we are not in 2010, why use rail? There are a lot of alternatives - java (spring) - go - node. But using rust for it is not far from c++ by craziness. So you are jumping from one strange solution to another…

There's this weird conceit that Ruby On Rails somehow has a monopoly on developer experience, that Ruby On Rails gives developers pleasure that is unique and uncopyable - a unique and utterly amazing and incomprehensibly awesome developer experience that no other language or framework can replicate.

Rails developers smugly assert that Ruby on Rails is more productive than anything else out there.

I call BS on the "Ruby On Rails is the very best by far" conceit.

Ruby On Rails has a monopoly only on the perception that its developer experience and productivity is off the charts.

Ruby On Rails is just another language and framework. There's literally nothing that makes it different or particularly special compared to anything else.

Developers everywhere with Python or nodejs or TypeScript or C# or Golang have a developer experience that is just as great, without the high handed conceit that what they are doing is amazingly better than anything else.

Didn't we make this mistake and learn from it in 2005? I guess not.

Ruby, and Rails, was an awful idea then and it's an awful idea now. Even in-browser stuff is moving to typescript to get away from having to write unit tests for basic type errors.

But sure, let's dig up this failure and try it again

Please don’t.

You pay 100x for each line of code and get nothing in return over ASP.NET Core or Vert.X. Pick any fast compiled language you like, don’t contribute to global warming.