Python and JavaScript: building fullstack apps with a split

The most common fullstack architecture I see in SaaS companies is not really a framework choice. It is a language split: Python on the server, JavaScript in the browser, and a network boundary between them.

This is worth understanding properly, because the split is a decision with real consequences rather than a default to accept.

Why the split exists

Python and JavaScript are both good at different things, and historically they have been used for different reasons.

Python won the backend on developer productivity and the data ecosystem. The libraries for machine learning, data processing, document handling and integrations with other people’s services are simply better there. If your backend touches any of that, Python is usually the shorter path.

JavaScript won the frontend because it was the only option that ran in the browser. That constraint is now historical — transpilers, WebAssembly and serious alternatives exist — but the installed base, the framework ecosystem and the hiring pool are still overwhelmingly JavaScript.

So teams pick the best language for each half and meet at an HTTP boundary. Given those constraints, this is a reasonable default.

What the boundary costs

The API is not a free abstraction. It has real costs, and they compound.

Type information dies at the boundary. Your backend knows exactly what a Customer is. The frontend knows it is whatever shape the last developer typed. Generating types from the backend schema — from an OpenAPI specification — is the single highest-leverage thing you can do in a split codebase, because it converts a class of runtime bug into a compile error.

Validation gets written twice. Once on the server where it is trusted, once in the browser where it can give immediate feedback. This duplication is usually justified for user experience. It is not justified when the two implementations disagree and the browser one wins.

The same knowledge is needed in two languages. Someone who knows your business logic now needs to know it in both. This is the largest ongoing cost and the least visible, because it shows up as hiring difficulty rather than as a line item.

When the split is wrong

If your application is mostly forms, mostly CRUD and mostly about moving data into tables, the split buys you two codebases where one would do.

Server-rendered applications with a small amount of interactivity do not need this. Neither do internal tools. Neither do many early-stage products, where the constraint is speed and the frontend is a thin layer over the backend.

The split is justified when the frontend is complex enough to justify a real application architecture. If it is a form with a table underneath, you are paying twice for one thing.

What I actually do

For backend work I use Python — FastAPI for focused JSON APIs, Django most of the time. PostgreSQL by default, I may introduce SQLITE if concurrent writes are not an issue, Docker for reproducibility.

For frontends: Svelte/SvelteKit is my to go stack.

My bias is to remove rather than add. Every service in the architecture is a thing that can be down and a thing that needs deploying. A two-tier application with a clear API is usually better than four services that must agree.

If the app is CRUD I may use Pocketbase with Svelte in some cases.

The stack is the easy part

The pattern I see with teams that struggle is not that they chose the wrong language. It is that they didn’t have enough business knowledge of what they were building, which resulted in a codebase that didn’t match the business requirements.

That’s normal. Software is always changing.

We need to be careful not to build rigid systems, but systems that are modular and easy to change as the business evolves.

I would start always with Django unless there are some specific requirements to pick FastAPI or Pocketbase. AI knows it, it doesn’t change often, it’s secure and has everything you need built-in for creating web applications.

If you are holding a system together that has outgrown its architecture, describe what is going wrong. The first conversation is free and often ends in removing something.