Rails really packs a punch

After seven years with Django, I’ve become a bit of a Python zealot. It’s sleek, it’s flexible, and with Django, you have all the essentials neatly packed into a one-stop web framework. Yet, for the past couple of years, I’ve been dabbling with Ruby on Rails. And honestly? Rails 8 has made quite an impression on me, leaving me in a tug-of-war between these two worlds.

Now, don’t get me wrong—I still love Django. It’s like that dependable partner who’s always there for you. But Rails, especially the upcoming latest 8.0 release, has an undeniable allure. It’s like discovering a new love that sweeps you off your feet while you’re still in a long-term relationship. Let’s dive into what makes Rails 8 so intriguing and where it might still stumble.

Rails 8 has introduced some game-changing features, particularly in how it tackles the age-old problem of application deployment. Remember the headaches of managing deployments without the help of a platform-as-a-service (PaaS)? For many of us, this meant spending hours fine-tuning our infrastructure, only to be hit with eye-watering AWS bills at the end of the month. Hosting on PaaS platforms like Heroku, while convenient, can quickly become prohibitively expensive as your app scales. Rails 8 essentially shifts the focus back to building, rather than constantly fretting over where and how your app will run. It’s a change that’s hard to overstate for developers who have spent years wrestling with infrastructure and battling escalating cloud costs.

Kamal2 is huge! It can be used with django as well but kudos to the rails team for bringing to us devs! It’s essentially Rails’ way of saying, “We've got your back, even when it comes to deployment.” You provide the IP addresses of your servers and your SSH key, and Kamal handles the rest. It automates the setup, turning a plain Linux box into a fully functional app server within minutes.

Another feature that caught my attention is Thruster, which acts as a built-in proxy for the Puma web server. Thruster eliminates the need for an external web server like Nginx, allowing the Rails app to handle internet traffic directly. In contrast, Django developers often find themselves wrangling with configurations for web servers to act as reverse proxies. A streamlined, built-in proxy layer for Django could save developers a lot of time and reduce the complexity of their deployment setups.

“Thruster aims to be as zero-config as possible. It has no configuration file, and most features are automatically enabled with sensible defaults. The goal is that simply running your Puma server with Thruster should be enough to get a production-ready setup.”

The Solid Series & Less Reliance on Third-Party Services:

Rails 8’s introduction of Solid Cable, Solid Cache, and Solid Queue is another area where it flexes its muscles. Traditionally, Rails apps have relied on services like Redis for caching, background jobs, and WebSockets. In Rails 8, this is now simplified, with SQLite being used for these tasks by default. This change brings Rails back to its "batteries-included" philosophy, removing the need for additional services to get started. For Django, adding features like real-time communication (Channels) or caching (Redis or Memcached) often requires setting up separate services, along with their own configurations and maintenance overhead. While Django does provide robust support for integrating with these services, a built-in, Rails-like approach to handling tasks with the default database would be a game-changer. Imagine a world where Django handles WebSockets, background jobs, and caching seamlessly with just the default SQLite or PostgreSQL setup.

While Rails embraces its convention over configuration philosophy, which often results in faster development and fewer decisions to make upfront, Django leans more towards explicit configuration. For example, Rails’ automatic setup for things like asset management or database connections means you can focus more on building your app rather than tweaking settings files.

There’s a wishful part of me that longs for a Rails-like magic in some of Django’s more tedious setups, like deployment and asset management, without sacrificing the explicitness that makes Django so versatile. A bit of Rails’ opinionated convenience in Django—while preserving Django’s flexibility—would make the development process even more enjoyable.

— Rishi Banerjee
July 2023