Yesterday I announced Fusion — a library helping to implement real-time UIs much faster, but more importantly, differently from how it’s done today. And Fusion’s documentation — with pages like Overview and Tutorial — is definitely useful for someone who has already decided to learn it, but a really simple explanation of what Fusion does is missing there. So here it is.

As a bonus, you’ll learn a lot about CAD systems and modern-day manufacturing.

What’s common between Fusion and Incremental Builds?

If you’re a developer knowing about incremental builds, this is the only section you need to read.

Fusion is like an incremental build system, but for any value your code computes:

  • Our code is a composition of functions. And instead of “rebuilding” each function’s output from scratch, Fusion tries to either use its cached value, or rebuild it from cached outputs of other functions that are known to be consistent.

What’s common between Fusion and CAD systems?

Look at the video below — it shows how hardware is designed nowadays. The model designed in CAD system (e.g. Autodesk Inventor) is later transformed into a program controlling CNC machines, and these machines carve model parts from metal, 3D print them, etc.

Such models are almost always parametric, and the video is all about this. Parametric models have constraints, which are defined when the model is designed; some examples of such constraints are:

  • Lines A and B must be perpendicular

Any non-toy CAD system has a geometric constraint solver — an algorithm that adjusts the “free” parts of the model to satisfy every constraint. The number of possible solutions for a given model is quite important:

  • 0 solutions: there is no way to satisfy all of the constraints. Usually, it means you should change or remove some of them — e.g. change the dimension to “unblock” the desirable solutions.

So as you see, constraints are super important in CAD. Asserting there is only one geometry that satisfies all of them is crucial for manufacturing, but importantly, they also allow engineers to adjust the model later. That’s how it works:

  • You specify that all the holes in part_P have dimD diameter (dimD is a constraint), which matches the screw size you plan to use. Let’s say it is screw size #10.

Now, assume you already manufactured all the parts of your final assembly and discovered you have no #10 screws — the AI running your warehouse concluded it’s better to sell them as a scrap metal to buy all available WD-40.

The only screws left are M6 screws (guess why…), and you’re curious which parts of your model have to be re-manufactured.

When your model is, basically, a ball, the answer is easy, right?

This ball:

The gist: dependencies and constraints are quite useful in real life, and having something capable to tell what’s impacted by seemingly a tiny change is super useful too. If you’re still not convinced, the famous “The Space Shuttle and the Horse’s Rear End” should tell a non-fictional story about dependencies.

How all of this is related to Fusion?

It’s actually super simple:

  • “A part of the model” in the story above = “anything you can compute, including the “look” of UI you want to update in real-time”

And Fusion is an efficient constraint solver. “Efficient” here means it re-computes only what’s outdated, and reuses as much of remaining components as possible — and that’s why Fusion improves performance. For the sake of clarity, a typical web app recomputes almost everything needed (directly or indirectly) to produce the result for each and every API call. I’ll explain this in one of the upcoming posts, but for now, just believe me.

Yes, I’m a professional

The way Fusion achieves this is:

  • When a “fusion function” runs, it records every “fusion value” used in it and attaches the information about what’s used to the output (which is also a “fusion value”).

Long story short, Fusion tracks all the dependencies down to the roots to precisely know when any part of UI becomes outdated. Once this happens, it lets you decide when an outdated part has to be re-rendered. Typically you decide what’s the delay between the moment you know something is invalidated and the actual update (re-render), and in vast majority of cases this decision is super simple:

  • If the current user just performed an action, there should be no delay, because most likely these are the changes caused by his/her action

P.S. Next time I’ll try to explain the difference between Fusion and such libraries as SignalR.