Why I chose Vanilla JavaScript over React for a production SaaS tool — and would do it again

When I started building Aservus — a free PDF toolkit at aservus.com — the first decision I made was to use zero JavaScript frameworks.
No React. No Vue. No Svelte. Pure HTML, CSS, and Vanilla JavaScript.
Every developer I mentioned this to had the same reaction: "Why would you do that for a production tool?"
Here is my honest answer.
The use case made frameworks unnecessary
Aservus is a collection of single-purpose tool pages. Each page does one thing — merge PDFs, compress a PDF, convert PDF to Word. There is no complex shared state across components. There is no real-time data syncing. There is no authentication flow with dozens of conditional UI states.
The use case that frameworks solve brilliantly — complex, stateful, interactive applications — was not my use case. My use case was: user arrives, user selects file, tool processes file, user downloads result.
A framework would have added complexity without solving any problem I actually had.
Performance was non-negotiable
PDF tools are used by people in a hurry. Someone needs to compress a file before a job application deadline. Someone needs to merge documents before a meeting starts. They are not browsing — they are trying to get something done in under 60 seconds.
Every millisecond of load time is a conversion killer.
Vanilla JS with no build step, no hydration, no bundle parsing means tool pages load near-instantly. The first contentful paint is fast because there is nothing heavy to parse. The user sees the upload interface immediately.
A React bundle — even optimised — adds overhead that I could not justify for pages where speed is the core product feature.
WebAssembly integration is simpler without a framework
Most of the PDF processing on Aservus runs locally in the browser using WebAssembly compiled libraries. Loading and initialising a WASM module, managing its memory, and handling the async processing pipeline is already complex enough.
Adding a framework layer on top would have meant managing WASM lifecycle inside component lifecycle hooks — which creates more surface area for bugs without any benefit.
With vanilla JS I have direct control over exactly when modules load, how memory is managed, and when the UI updates. That control matters when you are processing binary file data in the browser.
What I would use a framework for
I am not anti-framework. If I were building the analytics dashboard for Aservus — something with real-time charts, filterable tables, multiple interconnected views — I would reach for React or Vue without hesitation.
Frameworks are the right tool for stateful, complex, component-heavy interfaces. They are the wrong tool for fast, focused, single-purpose tool pages.
The actual outcome
The site is a PWA with a service worker. Tools work offline. Pages load fast. The codebase is simple enough that I can read and understand every part of it without a build system or mental model overhead.
If you are building a tool-focused product where performance directly affects user satisfaction — I would seriously reconsider the default assumption that you need a framework.
What are your thoughts? Has anyone else made a similar call on a production project?