Having now built and deployed both kinds of projects — several static HTML/CSS/JS sites (this portfolio, CBC Best, Ronny Best Math) and a full Flask backend application (RonnyBank) — the question "should this be static or should it use a backend framework like Flask?" has a clearer answer in my head than it did before actually building both. Here's the practical version of that answer.
The actual difference, in plain terms
A static site is just files — HTML, CSS, JavaScript — sent to a visitor's browser exactly as written. Nothing runs on a server when someone visits; the server's only job is handing over the same files to everyone who asks.
A Flask application runs actual Python code on a server every time someone visits a page. That code can check who's logged in, read and write to a database, calculate something fresh for each visitor, and return a different result depending on who's asking and what they're doing.
The decision table
| Question | Static Site | Flask App |
|---|---|---|
| Does each visitor see the same content? | Yes → static fits | No, personalized → Flask needed |
| Do users need to log in / have accounts? | Not possible with static alone | Yes, this is exactly Flask's job |
| Does data need to be saved between visits? | No persistent storage | Yes, via a database or file |
| Hosting cost & complexity | Lower — Netlify free tier, no server logic | Higher — needs a real running server |
| Speed | Extremely fast, served from CDN | Slightly slower, server has to compute a response |
Where this actually applied in my own projects
Every visitor to these sites sees the same worked examples, the same curriculum content, the same FAQ. Nobody logs in. Nothing needs to be remembered between visits. Adding Flask here would have added real hosting complexity — and the cost of keeping a server running — for zero actual benefit, since nothing about the experience needs to differ per visitor.
RonnyBank fundamentally requires knowing who is visiting — which account, which balance, which transaction history — and that information has to be checked and updated on every single action. There's no version of "login, deposit, transfer money" that a static site can do; it's not a limitation of skill, it's a limitation of what static files are structurally capable of.
The trap to avoid in both directions
It's tempting, once Flask feels comfortable, to reach for it on every new project — but that's its own kind of mistake. A portfolio site, a curriculum resource hub, a landing page: none of these need a running backend, and adding one means more to deploy, more to secure, more that can go wrong, for content that was never going to change per visitor anyway.
Equally, trying to force genuinely interactive, account-based functionality onto a static site — usually via increasingly elaborate JavaScript and browser storage workarounds — tends to produce something fragile that breaks the moment a user switches devices, since browser-only storage never leaves that one browser.
A useful filter question
Before starting any new project, one question cuts through most of the confusion: "Does this need to remember anything about a specific user, across visits, in a way only a server can guarantee?" If yes, that's Flask (or a similar backend) territory. If no — if every visitor genuinely sees the same thing — a static site will be faster to build, faster to load, and easier to host, with nothing lost in the process.
See both approaches in action
Compare a static educational site with a full-stack Flask application, both built and deployed by the same process.
View CBC Best (Static) → View RonnyBank (Flask)