DX = RR7 * Django^2

After more than twenty years building software, I no longer judge a stack by how fashionable it is. I judge it by a much simpler question: does it let me move fast without turning the codebase into a trap six months later?

Today, the answer that fits me best is this one: React Router in SSR mode for the frontend, Django with DRF for the backend, especially for the ORM, the admin, i18n, and the boring but essential business foundations.

It is not the most hyped combination. It is not the one that gets the most attention on social media. But for actually shipping software with a pleasant day to day experience, it is the stack I currently prefer.

What I mean by developer experience

When I talk about DX, I am not talking only about nice CLI messages or a polished getting started guide. I mean the full feeling of building and maintaining a product over time.

A good developer experience means:

• the project is easy to understand
• responsibilities are clear
• common tasks are fast to implement
• the framework does not fight the platform
• the backend remains boring in the good sense of the word
• the frontend stays expressive without becoming chaotic
• new features do not require rethinking the entire architecture every two weeks

At this stage of my career, I value clarity, leverage, and durability far more than novelty.

Why React Router SSR works so well for me

I like React, but I do not want a frontend stack that tries to reinvent the whole web. That is where React Router in SSR mode hits a very good balance.

It gives me the parts I want on the frontend:

• nested routing
• loaders and actions close to the route
• a clean mental model for data driven pages
• server rendering for fast first paint and robust HTML output
• progressive enhancement instead of JavaScript first tunnel vision

The important part is that it still feels close to the web platform. Routes map naturally to pages and behaviors. Forms remain forms. Navigation remains understandable. Data loading is structured without becoming magical.

SSR also gives me something I find extremely valuable in real systems: composition. Because rendering happens on the server, I can call other APIs, aggregate data from multiple sources, enrich the payload when needed, and shape the page before it reaches the browser. That means the frontend can expose a clean page model even when the underlying information comes from several backend capabilities.

I do not feel like I am surrendering the application to a giant abstraction layer. I still understand where things happen, and that matters a lot for long term maintainability.

Why Django remains incredibly strong

On the backend side, Django keeps proving the same thing year after year: boring technology is often a superpower.

Django gives me a foundation that is hard to beat in real projects:

• a mature ORM
• a battle tested admin
• clear domain modeling
• strong conventions
• excellent tooling for data centric applications
• built-in i18n support that is genuinely useful in real products
• a backend that can grow without becoming immediately messy

Three parts are especially valuable to me.

1. The ORM

Django ORM is productive in the right way. It lets me model business entities quickly, express queries clearly, and keep a solid link between application logic and relational data.

Of course, every ORM has limits, and complex systems still require real SQL knowledge. But Django gets the default case right extremely often, and that removes a huge amount of friction.

I do not want to spend my time rebuilding CRUD foundations or debating whether every query should pass through five layers of indirection. I want a model layer that is explicit, proven, and efficient enough for most business software. Django delivers that.

2. i18n

Django also gets something very important right for many real-world products: internationalization.

As soon as an application needs multiple languages, things become annoying surprisingly fast if the framework treats i18n as an afterthought. With Django, the foundations are already there:

• translation hooks are part of the normal development model
• locale handling is built into the framework
• the overall approach stays coherent across templates, backend code, and validation messages

That matters a lot in professional environments. I do not want to bolt multilingual support on top of the product with ad hoc conventions and fragile glue code. I want i18n to feel like a first-class concern from the beginning, even if the project only grows into it later.

3. The admin

Django admin is one of those features that feels almost unfair.

In many projects, internal back office needs appear very early:

• manage users
• correct data
• inspect records
• trigger operations
• support business teams
• verify that the system state matches expectations

With Django, a large part of that arrives almost immediately. Not as a toy, but as a genuinely useful operational interface.

That changes the rhythm of a project. Instead of promising “we will build internal tooling later”, you often have a very capable baseline from the start. That is a massive DX win, because it reduces the amount of custom code you need before the product becomes usable by real people behind the scenes.

Why the combination is stronger than each part alone

What I like most is not React Router alone or Django alone. It is the separation of concerns between them.

• React Router SSR handles the user facing application experience
• Django + DRF handle the domain, persistence, administration, and backend logic

This boundary is healthy. Each side can focus on what it does best.

On the frontend, I can build an interface that feels modern, structured, and pleasant. On the backend, I can rely on a framework that is extremely good at representing business data and operational workflows.

This avoids a pattern I have seen many times: forcing one framework to do everything, then paying for that decision in complexity.

In practice, this usually means a simple architecture that stays readable:

• React Router SSR renders the application and orchestrates the UI flow
• Django and DRF expose the business capabilities and own persistence
• the contract between both sides stays explicit, whether it is server rendered data, classic forms, or a clean HTTP API
• from React Router, I can call OPTIONS on endpoints to retrieve schema information and use that to build forms with the right fields and constraints
• authentication and permissions remain backend concerns first, instead of being scattered everywhere in the frontend

I do not need the frontend to pretend it is also my entire backend platform. And I do not need the backend to own all presentation concerns. A clear contract between the two gives me a better system overall.

Why this matters more after twenty years

With experience, one thing becomes obvious: most technical pain does not come from missing features. It comes from accidental complexity.

A stack becomes expensive when:

• too many concepts overlap
• too much is implicit
• debugging requires framework archaeology
• simple features need disproportionately complex setup
• upgrades feel like migrations between religions

That is exactly why I appreciate this combination. It keeps complexity in places where it is justified. It avoids inventing extra complexity just to look modern.

I can explain the architecture quickly. I can onboard someone without a two hour lecture on framework philosophy. And I can return to the code later without feeling that past me tried to be clever at my expense.

It is not about chasing the perfect stack

To be clear, I do not think this is the universal best stack for every team and every product. There is no such thing.

Some products need a different frontend model. Some teams need tighter full stack conventions. Some organizations optimize for hiring patterns, not personal preference. That is normal.

But for the kind of software I value building, this pairing gives me an excellent trade off:

• modern UI capabilities where they matter
• robust server side rendering
• strong backend foundations
• superb data management
• schema-driven form building via DRF OPTIONS responses
• an admin that saves real time
• a codebase that stays understandable

That balance is rare.

Conclusion

If I had to summarize my preferred stack in one sentence, it would be this:

React Router SSR gives me a frontend that stays close to the web, and Django plus DRF give me a backend that stays close to the business.

That is why, after more than twenty years of development, it feels like the best technical stack for me.

Not because it is trendy. Because it is efficient, durable, and pleasant to work with.