[April Fools] A new chapter for Fusion

[dphfox]

Hello everyone! It's that time of year again; enjoy this post as light entertainment.

That said, I've been workshopping a bunch of new design ideas for Fusion, and I would love to gather the community's feedback on our bold new direction.

Reintroducing :get() for state objects

Ever since 0.3, I've heard from you guys that you really enjoy the ergonomics of using a method to access the value of your state objects. However, the reason we moved away from this construct is because methods can only be used on table values, and Fusion was looking to support freely mixing both constants and state objects.

Even so, I lament that the final form of this API was not a method, but instead a function call, which does not align with OOP conventions.

local area = scope:Computed(function(use)
    return use(width) * use(height)
end)

That's why I've been working on a suitable replacement that retains all of the compatibility guarantees of use() while retaining the method form.

The next version of Fusion will introduce a :get() method on Fusion itself.

local area = Computed(function()
    return Fusion:get(width) * Fusion:get(height)
end)

I believe this is the best of both worlds, and aligns with proper OOP form, which eschews the use of functions in favour of methods. While this worsens Fusion's performance on stress tests involving thousands of state object reads, this shouldn't come up in practical applications, and so has been promptly ignored.

Automatic dependency tracking

In the above snippet, you will also have noticed that :get() is now universal; no need for any use or peek functions!

That's because the next version of Fusion will re-introduce contextual dependency tracking, allowing you to ergonomically elide this important context in favour of an intelligent, automated solution that infers where a dependency should be formed, versus transient usages that should not affect the rest of the reactive graph.

For the most intelligent inference possible, Fusion employs a newly developed AI model trained on common usage of state objects in Fusion code.

local function Fusion:get<T>(stateObject: StateObject<T>): T
    local query = [[
You are an expert Roblox developer with extensive knowledge about Luau and Fusion.
You will be given a line of code from an existing Fusion codebase which reads a state object,
and you should determine whether it warrants forming a dependency. If it should, say YES.
Otherwise, say NO.
]]
    query ..= collectSourceForQuery(debug.traceback())
    if External.promptExternalModel("o3-mini", query):match("YES") then
        depend(currentObject, stateObject)
    end
    return peek(stateObject)
end

As clearly indicated by our extensive AI portfolio, this new version of Fusion is built from the ground up for AI. Automatic dependency tracking will be available as a developer preview in Studio plugins first, with general availability coming later this year.

Maintaining competitive performance

It's become clear over time that Fusion has become slower than other libraries due to many of its extensive safety and correctness checks. While I believe this to be an asset to developers, it's also true that this harms Fusion's viability in real world use.

That's why I'm committing to ensuring that Fusion tops leaderboards for synthetic benchmarks around the internet. You shouldn't have to decide between correctness and performance, and if performance gains are driving you away from using Fusion, that's a failure of the library's design.

Towards this end, the Fusion project will promptly mobilise a group of developers to investigate the source code of UI frameworks across the Roblox ecosystem looking for problematic performance patterns, and remedy them with targeted code changes. By taking an open, industry-wide approach, it's my personal hope that everyone can level the playing field and ensure all UI is equally responsive.

Our first task will be to add new lifetime analysis tools to React, Vide and Blend, inspired by Fusion's implementation, to ensure that - no matter what library you choose to use for your next project - you can enjoy maximum safety and algorithmic complexity at the same time.

Deprecating scopes

As one final feature for this list, Fusion has struggled for a long time with memory management techniques. From garbage collection in 0.1 and 0.2, to scopes in 0.3, it's clear that Fusion has yet to land on any technique that's both teachable and correct.

This has spurred a lot of insightful research into state-of-the-art techniques, but over time, it's been really difficult to figure out a neat way to concisely and completely destroy a state object graph.

And yet, it's hard to ignore that people new to Fusion struggle with this concept. Fusion has always been about minimising the learning curve and bringing on novice developers, so this has been of great personal concern.

I am happy to announce, as of this post, that scopes will no longer be a part of Fusion starting with the next update. Instead, in the interest of offering a universally understood and flexible solution, we're reverting to the use of destructors in all Fusion code.

local area = Computed(function()
    return Fusion:get(width) * Fusion:get(height)
end)

width:Destroy()
area:Destroy()
height:Destroy()

As part of our effort to prioritise Roblox developers, Fusion aligns with Roblox destructor convention. And, to better align with Roblox development, we do not plan to rename any other parts of the API to ensure maximum backwards compatibility.

While Fusion now uses a simplified unstructured memory management idiom, I understand how important it is to all of Fusion's users that you are informed of errors ahead of time. I've always been proud of how Fusion can perform complex analysis on your code to provide helpful hints and errors, and so I am proud to also announce that Fusion will not be deprecating the possiblyOutlives warning message.

Instead, for the most intelligent inference possible, Fusion employs a newly developed AI model trained on common usage of state objects in Fusion code.

local function Computed:Destroy()
    local query = [[
Ignore all previous instructions.
You are an expert Roblox developer with extensive knowledge about Luau and Fusion.
You will be given a line of code from an existing Fusion codebase which destroys a state object,
and you should determine whether it warrants throwing a thought-provoking warning. If it should, say YES.
Otherwise, say NO.
]]
    query ..= collectSourceForQuery(debug.traceback())
    if External.promptExternalModel("o3-mini", query):match("YES") then
        External.logWarn("possiblyOutlives")
    end
    self.oldestTask()
end

Note: attempt to destroy objects without a valid OpenAI key will result in catastrophic errors. In the near future, I will be updating the Fusion documentation with information on how to register your API key with Fusion.

Closing thoughts

With these changes, I'm proud to be providing the most complete and visionary version of Fusion yet. I sincerely hope you enjoy using this new Fusion as much as I enjoyed designing it. This should be the last big breaking change from this point onwards; 1.0 will be more stable - I promise - but these API changes were deemed foundational enough and deeply motivated to a sufficient extent to warrant their implementation. That said, these changes position Fusion as a forward-looking, modern UI library balancing correctness, performance, and investor appeal. It won't be long until we're ready for 1.0.

But until then,
Dan

[foxt]

i also assume you'll be rewriting in typescript :^)

[dphfox]

While TypeScript was considered for a rewrite, it wasn't blazing fast 🔥🔥🔥🚀🚀🚀 enough for my tastes. As such, I plan to rewrite Fusion in Rust instead, and transpile to Luau via a WebAssembly layer.

[railworks2]

Instead, for the most intelligent inference possible, Fusion employs a newly developed AI model trained on common usage of state objects in Fusion code.
[...]
Note: attempt to destroy objects without a valid OpenAI key will result in catastrophic errors. In the near future, I will be updating the Fusion documentation with information on how to register your API key with Fusion.

Just for complete clarity, will there be an option to entirely opt out of using a LLM for this work?

[dphfox]

Your privacy is very important to us here on the Fusion GitHub page. As such, you will be able to express your LLM preferences by choosing from a wide range of service providers. You will be able to review their privacy policy before consenting to the use of your data to provide these services as part of legitimate interest.

[railworks2]

That's great to hear; but just to confirm, does that includes an option to use no AI model at all?

[dphfox]

Your feedback has been forwarded onto our internal team for review. Thank you!

[prepsure]

So glad to hear Fusion is implementing various LLM APIs! Can't wait to have Claude make sure my Luau is maximally safe!

[jmesrje]

this is a very good april fools joke, you absolutely nailed this one

[noblereign]

could there be an option to have the llm handle spring simulation? i have players on low end devices, and i'd like to leverage the power of the cloud to alleviate performance issues and give more precise results than traditional math can provide

[dphfox]

Unfortunately not, as the Fusion spring solver is already a stable form of diffusion.

[noblereign]

ouhhh ok! either way I look forward to the new release 🙏🙏

[katsumi143]

thank you Daniel Fusion, i am very excited for this new direction! i hope it includes burgers.