The world feels batshit insane right now. Between a dubious war and AI doomerism, working on side projects feels futile; if I’m not meta-orchestrating a cackle of agents via subvocalization from the bomb shelter, I’m doing it wrong.

Fortunately I’m not intimidated by futility, and decided to fight back by pursuing a niche problem I occasionally have, writing HTML and JS by hand like it’s 2007. That’ll show`em!

Wedding financials

January 2025: my soon-to-be-wife and I are planning our wedding, and have to make some chicken-and-egg decisions around budget, venue and number of invitees. Though governed by the simple constraint total cost == money spent, the variables interact in nontrivial dynamics and offer several possible tradeoffs. As I well know from constrained optimization, if I could reduce all these variables into a single objective function to score the desirability of a specific tradeoff, I could find an optimal solution automatically.

But that’s not how humans work. If I’m going to save $3000 by not inviting distant relatives, I want to decide it myself, not have it spat out by some arcane formula. What I want isn’t constrained optimization; it’s to directly interact with the constraint, and explore the manifold it induces on the space in a way that allows me to build intuition about the tradeoff dynamics.

I’ve felt that itch before, but it was during this time that I started to (semi-)seriously contemplate what such interaction might look like. That’s when the idea for the tradeoff sliders was born.

The Snacks Guy

You and a couple of friends are organizing a party, and you’ve been appointed the snacks guy (or gal), with a $200 budget. Not one to take your duties lightly, you want to explore your options before making a decision. And by “options” I mean not just which snacks you could buy, but also how to allocate the budget between them.

Conveniently, the local general store’s snacks section is very limited, offering only popcrn, for $5 a bag, and liquorice sticks, $12 a pack. Exploring the tradeoff is as easy as these two sliders!





Alas! As you approach the snacks shelf, you see that the store started importing Wasabi peas, for $7 a bag. Judy will be delighted, but the tradeoff is harder to consider in full. You want to add another slider, but how to make the three of them auto-update to respect the budget without hard-coding a preference for one snack over another? You could, in theory, create a 3D chart to depict the tradeoffs, but this is clearly not generalizable should the store add another snack to the selection.

Reluctantly, you enter all the data to Excel, where you create conditional formatting to show you when you’re overbudget. This does the job - Excel tends to deliver - but the feedback loop. It’s so slow.

This is what the tradeoff sliders are meant to solve. When we were planning the wedding, we used Excel, but I found myself yearning for an almost physical interface where the constraint simply can’t be violated, yet I’m free to explore the space otherwise. Here, give it a try:






How does it work?

At the heart of every group of tradeoff sliders is the constraint: an equality that must be satisfied throughout changes to the variables. Each variable also has bounds. Then when you move a slider, a tiny differential evolution optimization is run to find values for the other sliders such that the equality is still satisfied, and all sliders (other than the one you updated) move as little as possible from their previous positions. The effect is that the error created by you moving the slider is spread among the rest of the variables, to the degree possible.

This way, you can make changes while the constraint is preserved, and by spreading the error around the sliders aren’t keeping you to the edge of the manifold. While not a perfect realization of the concept, I’m really happy with it as a first step.

Business model back-of-the-envelope calculations

You’ve been there: sitting with friends, spitballing ideas for startups or apps. Pretty soon you find yourself doing back-of-the-envelope business model calculations: how much could we charge? What would be the operating costs? Quaint as the back of the envelope might be, this is another sort of exploration that calls for immediate feedback.

Here are tradeoff sliders for a simplistic business model: active_users * (subscription) price == expenses + profit







The idea isn’t to provide some judgement call or evaluation for realism, only to provide an easy way to explore different combinations where the math checks out.

Try it yourself

Making tradeoff sliders is so fun, I made a small webpage where you can make them yourself. Write the constraint as a javascript expression, fill in the bounds and explore away! It serializes through the hash (for example, you can play here with the business model ones), and you can even embed them in your own pages. The expression is parsed with Acorn.

Room for improvement

As happy as I am with this as the first iteration, there’s still much to be desired:

  • Sometimes the sliders’ response is jittery. This happens because the optimization runs for a short time to respond in semi-realtime, and doesn’t converge to the truly optimal solution that would be closest to the sliders’ current value. I imagine WASM / WebGPU can be used to run more iterations without a performance hit.
  • When I try to explore certain tradeoffs, there can be a feeling of fighting the sliders - each move undoes some of the last move, and I have to persist to converge to my desired tradeoff. Having a preference to move recently-changed sliders less than the others could solve this, or perhaps a UI for locking / setting the “resistance” for each slider.
  • It would be nice to support more than one constraint, and allow inequalities.
  • The UI could be improved, made more responsive, customizable etc.

I’m not going to do these now, but one can dream.

Wedding financials revisited

Finally, some closure for the motivating example: an example of how planning our wedding with tradeoff sliders might have looked like. For this to make sense you’ll need to understand a bit about wedding norms in Israel.

Typically, the majority of a wedding’s cost will come from the venue’s price-per-guest, with a few additional costs for various services such as photography, the DJ and so on.

It’s customary for the guests to give money as the wedding gift to offset the costs (it’s a pretty expensive deal for most couples), depending on how close they are to the couple (so if you invite distant relatives and a wider social circle, you can expect a lower average gift). While it’s possible to pull off a cost-neutral wedding, realistically most couples (or their parents) have to spend a few tens of thousands of NIS.

(I have my personal criticism of the wedding institution and norms here, but refusing to play the game comes with its own price.)

Anyway, all this comes down to this constraint:

budget == guests * (guest_price - average_gift) + extra_cost

Which you can explore here, with roughly the ranges we considered:








kthxbye