The United States pandemic policies are gone, and they probably won’t be coming back with any kind of long-term lockdowns like we had in 2020 and 2021. It’s making the pandemic notice at the top of SacMusic.com look a little dated. And God willing, I’m moving back to Sacramento in a few weeks. It feels like it’s finally time to get the site’s information current.
The only problem: I absolutely hate the Django/Next.js tech stack it’s currently built with, and updating it sounds like so much trouble that I don’t even want to bother.
How we got here
I rebuilt the site with a Django back-end during the pandemic when I left my job in July 2021. I had planned to use it as an opportunity to learn Django and Docker. Mission accomplished: I learned both, and it helped me land my current job where I use both technologies daily. In that way, it was a success beyond my wildest expectations.
Using Django also gave me the ability to edit the underlying data almost as easily as I could edit WordPress, except with MUCH faster response times. I was particularly excited about that.
But the stack came with major downsides. Django’s API story is fantastic for building a REST API that would make Roy Fielding proud. But most of the time it feels ridiculously over-engineered compared to the ease in which you can return data in Laravel, Rails or Express. Django’s Router also feels ridged as it doesn’t support HTTP verbs per route, and Next’s file-based router makes me want to quit programming. Then gluing these layers together feels incredibly tedious, especially when dealing with bits like authentication. I could drop Next.js altogether and use Django templates, but Django templates are so restrictive that I hate using them.
I am a single developer building a distributed monolith with several downsides and no benefits. Enough is enough.
Auditioning Rails
I’ve built versions of SacMusic in countless technologies, and I’ve deployed it with WordPress, Next and Django. I don’t believe I’ve ever actually attempted to build SacMusic in Rails. It feels overdue.
Rails has famously little boilerplate, which is great because I want to spend as little time maintaining this site as possible while still being able to kick out new features. I’ll stick with Tailwind, and I’ll try to swap in Alpine for interactivity. I’ve made Alpine and Turbolinks play nice together, so hopefully some of that knowledge will transfer over to Turbo.
Now that I’m working with Django professionally, I don’t feel the need to maintain a Django side project actively. As a matter of fact, one of my biggest Django learnings has been that I don’t actually like working with Django that much. So it feels like a good time to switch. I also want to try Elixir/Phoenix at some point, and I think learning Ruby and Rails better could be helpful for when that rolls around.
Requirements
To launch, the new Rails version needs feature parity with the existing application. It also needs up-to-date event listings, and a way to handle retired events that won’t fuck the SEO. I anticipate that I can do this development on nights and weekends over the course of a month.
After launch, the app needs the ability for hosts to manage their own events. Host account creation and ability for hosts to create new events can be punted.
Contingencies
So I’m going to give Rails a shot. If this whole thing crashes and burns, I’m going to move SacMusic over to Laravel and keep it there forever. Laravel is my most comfortable framework, but I find writing migrations incredibly tedious, and there’s a lot of boilerplate. So I’m hoping that this works. Django’s real killer feature is the declarative models.
Anyway, here’s the stream-of-conscious Twitter thread that sent me down this rabbit hole.
Noise in F# 