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:

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:

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:

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:

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.

Image for post
Image for post

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?

Image for post
Image for post

This ball:

Image for post
Image for post

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:

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.

Image for post
Image for post
Yes, I’m a professional

The way Fusion achieves this is:

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:

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store