A couple of months ago I built a tiny reactive engine called State.js.
Originally it was just an experiment. I wanted to see how far I could push native web technologies before reaching for React, Vue or another heavyweight framework.
That experiment eventually became my first commercial WooCommerce plugin, Woo State Configurator, and while building it I noticed another opportunity.
There are plenty of WooCommerce Product Calculator plugins available, but almost all of them solve the same problem in similar ways. Large JavaScript bundles, dated interfaces and increasingly complex frontend stacks for what is ultimately a fairly straightforward task—calculating a price from a customer's measurements.
I wondered whether I could build a modern WooCommerce Measurement Pricing plugin without any of that.
So I did.
The result is Woo State Calculator.
If you sell products like flooring, wallpaper, carpet, artificial grass, timber, glass or fabric, pricing usually isn't fixed.
Customers need to enter measurements.
Length.
Width.
Height.
Sometimes wastage.
Sometimes minimum order values.
Sometimes maximum charges.
The final price needs to update instantly while remaining accurate when the product is added to the cart.
From a customer's perspective, that's exactly how it should work.
From a developer's perspective, many existing WooCommerce product calculator plugins rely on increasingly heavy frontend solutions to achieve what is essentially a handful of reactive calculations.
I wanted something simpler.
Don't get me wrong—I like React and Vue.
They're fantastic for the right applications.
But WooCommerce product pages are already server-rendered.
The HTML already exists.
SEO is already handled.
Performance already matters.
Adding a large frontend framework just to update a few prices and show or hide a couple of fields felt unnecessary.
That's exactly why I built State.js.
Instead of rebuilding the page in JavaScript, State.js simply reacts to changes in the existing HTML, keeping everything lightweight while still providing live updates.
The result is instant pricing without turning the product page into a client-side application.
Woo State Calculator focuses on one thing:
Making WooCommerce Measurement Pricing easy to configure while remaining fast for the customer.
Some of the features include:
Live measurement pricing
Area, length and volume calculations
Formula presets for common industries
Automatic wastage calculations
Minimum and maximum pricing limits
Server-side validation of every calculation
Lightweight State.js reactive frontend
Native WooCommerce integration
The goal wasn't to build the biggest WooCommerce Product Calculator available.
It was to build one that solved the problem cleanly without unnecessary complexity.
Ironically, the hardest part wasn't the calculations.
It was understanding the businesses using them.
A flooring company calculates prices differently to someone selling wallpaper.
A timber merchant has different requirements from someone selling glass.
Every industry has slightly different expectations, so a lot of the work went into making the plugin flexible enough to support different pricing models while keeping the setup simple.
That led to features like formula presets, configurable wastage, and minimum and maximum order pricing.
One thing I've learned while building commercial plugins is that merchants don't usually want a giant plugin with hundreds of unrelated features.
Most just want one problem solved well.
That's the philosophy behind Woo State Calculator.
Build a fast, focused WooCommerce Product Calculator that does one job exceptionally well, while keeping the customer experience fast and responsive.
I'm interested to know how other developers approach this.
If you're building for WooCommerce today, would you still reach for React or Vue for something like a measurement pricing calculator, or would you keep things server-rendered and lightweight?
The philosophy here is right, most WooCommerce calculator plugins do overbuild the frontend for what is a handful of reactive calculations. To your question: I would keep it server-rendered too for this specific case, product pages are already server-rendered and SEO-dependent, so a heavy framework is solving a problem that does not exist yet.
The claim I would want tested before recommending this to a merchant: does the live price the customer sees always match what gets validated server-side, across different formula presets and at the min or max pricing boundaries. That is where a reactive frontend and server-side validation can quietly drift apart, and it is the kind of bug that only shows up under real industry-specific formulas, not a simple demo.
I do product testing and walkthrough videos for early tools. I would be glad to run a few real pricing scenarios (flooring, timber, glass) through checkout and confirm the live price and the charged price always match, then put together a short video showing that end to end. Useful if you want proof before pushing this harder.