No frameworks. No dependencies. No regrets.
That’s the bold claim coming out of Optistream, a French streaming analytics platform that just shipped seven interactive calculators—earnings estimators, revenue breakdowns, growth trackers—using nothing but HTML, CSS, and vanilla JavaScript. No React. No Vue. No webpack bundle watching your every move.
In an era when every junior dev’s first instinct is to scaffold a Next.js project for a simple calculator, this feels almost heretical. But after 20 years of watching Silicon Valley fetishize frameworks, I’m here to tell you: they nailed it. And more importantly, they’ve exposed the dirty secret that nobody in the startup world wants to admit.
The Heresy: Frameworks Are Overkill for Simple Tools
Optistream’s requirements were refreshingly honest:
- Load instantly (no 200KB+ JavaScript bundle eating your bandwidth)
- Live inside WordPress pages without breaking
- Stay maintainable for a small team
- Play nice with LiteSpeed Cache
They built tools for streamers—Twitch sub calculators, revenue comparators, donation trackers, growth estimators. Each one is a self-contained widget. Input some numbers. Get a result. Math happens on the client. Done.
And here’s where I’d normally expect the punchline: “So they used [insert framework],” right? Wrong.
“We made a deliberate choice: no React, no Vue, no frameworks. Just pure HTML, CSS, and vanilla JavaScript, embedded directly into WordPress pages.”
This isn’t a hot take or a blog post written by someone living in a cabin. This is production code running on a real business. And the numbers speak louder than any Hacker News comment:
- 0 KB of framework JavaScript
- Under 5KB per calculator (HTML + CSS + JS combined)
- LiteSpeed PageSpeed score: 98/100
- Time to Interactive: under 1 second on 3G
Let that sink in. A complete, functional revenue calculator that weighs less than a medium-sized JPEG. No build step. No npm install nightmare. No hours wasted debugging why your SSR isn’t hydrating correctly.
Is Pure JavaScript Actually Faster Than React?
Here’s the thing that keeps framework advocates up at night: yes. For this use case, vanilla JS is objectively faster. But that’s not the real story.
The real story is that we’ve spent the last decade optimizing for the wrong problem. React, Vue, Next.js—they’re designed for massive, stateful single-page applications where the complexity is astronomical. They’re built to prevent entire categories of bugs that don’t exist when you’re building a calculator.
Optistream’s calculators don’t need a virtual DOM. They don’t need reactive state bindings. They don’t need code-splitting, lazy loading, or any of the architectural gymnastics we’ve normalized. A button click triggers a function. The function reads inputs. The function updates the DOM. Done.
But here’s where it gets interesting—and where the real lesson lives.
WordPress Is a Minefield (And Nobody Tells You)
Embedding JavaScript directly into WordPress is like trying to assemble IKEA furniture while someone randomly rotates your screwdriver. WordPress has this feature called wpautop that automatically wraps content in paragraph tags and converts line breaks into <p> elements.
So your pristine inline JavaScript:
if (x > 0) {
calculate();
}
Becomes this nightmare:
<p>if (x > 0) {</p>
<p>calculate();</p>
<p>}</p>
Your code is now completely broken. This is the kind of gotcha that exists in the gaps between documentation, where developers suffer alone at 2 a.m., Googling frantically.
Optistream’s solutions were pragmatic:
- Wrap all JavaScript in
<script>tags (wpautop leaves those alone) - Use custom shortcodes that disable wpautop for calculator blocks
- Minify everything to reduce line break opportunities
- use IIFEs (Immediately Invoked Function Expressions) to avoid variable collisions
These aren’t groundbreaking techniques. They’re just… careful. Deliberate. The opposite of the move-fast-break-things mentality that dominates tech discourse.
The Specificity Wars Nobody Talks About
When your CSS lives inside a WordPress page alongside theme styles, you’re fighting a specificity battle with one hand tied behind your back. Optistream’s answer: just prefix everything with a unique calculator ID.
#calc-twitch-subs .input-group { ... }
#calc-twitch-subs .result-display { ... }
#calc-twitch-subs button.calculate-btn { ... }
No BEM. No CSS modules. No CSS-in-JS library doing runtime parsing. Just ID-scoped selectors with enough specificity to win. It’s almost quaint how simple it is.
LiteSpeed Cache—the aggressive caching plugin that powers millions of WordPress sites—was another wrench in the works. Optistream handled it by making sure all calculations happen client-side, avoiding cookies, and using data-* attributes instead of server-rendered PHP values. They only added calculator pages to LiteSpeed’s “Do Not Cache” list as a last resort.
Again: pragmatism over purism.
Why Mobile UX Matters More Than Your Framework Choice
Streamers check their stats on phones. This simple fact drove design decisions that most frontend developers overlook:
<input type="number" inputmode="numeric" pattern="[0-9]*"
min="0" step="1" placeholder="Enter subscriber count">
That inputmode="numeric" attribute ensures the numeric keypad opens on mobile. It’s a tiny detail. It makes an enormous difference. And it’s the kind of thing that gets buried under framework abstractions and design system layers.
The Uncomfortable Truth About Technology Choices
Here’s what nobody wants to say out loud in a startup context: choosing vanilla JavaScript over React isn’t brave. It’s not even controversial in engineering circles. It’s just… correct for the problem.
But it’s invisible to the investment community, to the product marketing team, to anyone who doesn’t actually have to maintain the code. React looks like progress. It signals that you’re “serious” about engineering. A calculator that loads in 0.8 seconds using vanilla JS? That doesn’t fit any narrative.
This is why boring technology wins in production but never gets venture funding. Optistream didn’t invent anything revolutionary. They just built something that works, loads fast, and doesn’t require three developers to maintain a build pipeline.
The fact that this is noteworthy tells you everything you need to know about the state of web development right now.
🧬 Related Insights
- Read more: How One Developer Built a Framework to Stop AI Agents From Forgetting Everything
- Read more: JavaScript’s Array.flat() Is Elegant. But Your Nested Data Might Need Something Meaner.
Frequently Asked Questions
Can you build complex web apps with vanilla JavaScript?
Yes, but it gets harder as complexity grows. Vanilla JS is ideal for widgets, forms, and single-purpose tools. For applications with dozens of interconnected components, state management, and heavy interactivity, frameworks provide genuine value. Choose the tool based on actual requirements, not resume-building.
Will WordPress always break inline JavaScript?
No, but you need to plan around wpautop. Use <script> tags, custom shortcodes, or plugins that disable wpautop for specific content blocks. It’s a known problem with predictable solutions—just not the ones most developers expect.
How do you handle CSS naming without a framework?
ID-prefixing (like Optistream’s #calc-twitch-subs) is simple and effective for isolated widgets. For larger applications, BEM or other methodologies provide structure. The key is being intentional about scope instead of relying on CSS-in-JS or module systems to handle it for you.
