Fusion — a small library created as an attempt to challenge the existing architecture of high-load and real-time apps — is going to be 4 months old soon. Here is what happened over these months:
If you believe Virtual DOM is a “lightweight copy” of a real DOM helping to speed up the updates by batching them together— continue reading. Albeit being correct, it’s a highly misleading answer. Surprisingly, it’s also the most popular one: googling for “react virtual DOM” leads you to very similar descriptions: 1, 2, and you get ~ the same results even if you stick to the top answers on StackOverflow: 1, 2, 3;
The content below equally applicable to React and Blazor.
#1. It doesn’t highlight the key problem Virtual DOM solves — namely, the elimination of unnecessary re-renders. And…
The same day .NET 5 was released I shared a single screenshot showing how much faster .NET 5 is relatively to .NET Core 3.1. I promised to share more data later — and here it is.
Code: https://github.com/servicetitan/Stl.Fusion.Samples , see “Caching Sample” section there.
Overall, these tests stress an API endpoint fetching a small object from SQL database, the only difference is how it is exposed (locally or via HTTP) and if Fusion is used there to provide transparent caching.
My initial test was performed on Window & AMD CPU, but almost every production service runs on Linux nowadays, so…
I migrated Fusion to .NET 5 today — and honestly, I was absolutely astonished by the performance boost it brings:
The output is produced by Fusion’s “Caching” sample, which uses EF Core 5 and ASP.NET Core. The speed on tests producing 20M+ operations/s (#1, #3) is mainly constrained by Fusion’s logic and Castle.DynamicProxy. And tests producing around 100K operations/s are constrained by either EF & SQL Server (#2, #5) or ASP.NET Core (#4 — it’s ~ the same as #5, but relying on Fusion’s caching features). All of this means that:
Even though Amazon’s example isn’t unique in the context of this post, I’ll use it as a first example of efficiency of a modern web service:
Disclaimer: I am the author of Stl.Fusion — an open-source library helping to address the long-standing problem described in this post. But the problem is real, and the post is relevant even if this library won’t exist.
To answer this question, let’s ask the opposite one first: what’s the most rudimentary UX feature used by almost any web app today?
I nominate this button:
A very short description first:
Now, let’s talk about specific differences. I assume you already know Fusion abstractions support thread-safety, immutability, async support, etc. — in other words, the “must-have” features…
Even though both libraries are targeting similar problems (they help to write real-time apps faster), they do this quite differently:
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.
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…