mohebifar

Thanks. I totally hear you and that makes sense. Content is not my forte and I get lazy when it comes to that. Will improve it.

It is real but still experimental. Gotta test it in small apps first. I will move grep.codemod.com (currently vanilla js) this week to Vidact to try it out in production.

I started Vidact as an experiment 6 years ago, an experimental compiler that takes React-style function components and hooks and compiles them into direct DOM operations. The basic idea is: keep React's programming model, but replace its runtime model.

It was a very ambitious project back then, but recently, another project I was working on (grep.codemod.com) inspired me to rebuild this and I thought of using React compiler's analysis this time as it has already done most of the heavy lifting.

With Vidact, a component runs once when it mounts. The compiler analyzes which expressions depend on which values and generates static update functions for them. When state changes, it directly updates the affected text node, attribute, conditional range, or list item.

So instead of:

state change -> rerender component -> create element tree -> reconcile -> mutate DOM

it's closer to:

state change -> run compiler-selected updater -> mutate DOM

There is no Virtual DOM, no reconciler, no runtime dependency tracking, and React itself isn't shipped to the browser.

The compiler is written in Rust and uses React Compiler's analysis infrastructure for AST/scope/HIR/CFG/SSA and dependency information, but Vidact has its own IR, DOM code generator, and runtime.

I've also been experimenting with the same model for SSR/hydration and built Vidact Start around it, with file-based routes, loaders, SSR, hydration, and client navigation.

One design decision I'm particularly interested in feedback on: Vidact fails compilation when it encounters React behavior it can't preserve rather than silently falling back to React or a slower runtime path. It's therefore intentionally a subset of React today.

It's beta and there are definitely compatibility edges left to explore. I'm especially interested in cases where React semantics make static compilation fundamentally difficult, rather than just features I haven't implemented yet.

Site: https://www.vidact.dev/

Source: https://github.com/mohebifar/vidact

Much of Tooscut's heavy data lives outside the V8 heap. We use WASM linear memory which is not counted against V8 heap. GPU buffers is in VRAM. Bitmaps are also native allocations.

Also, video files are never fully decoded. We use the browser's native WebCodecs on demand. Only a small buffered window gets decoded and sent to the compositor. So it can even handle long 4K videos.

Could you please tell me more about your use case. I've changed the license once today. I'm open to changing it again.

I added CONTRIBUTING.md. I also took a look at OpenFX. My current view is that supporting OFX in the browser would be hard, since the standard and its existing tooling are not designed around wgpu or browser execution. Tooscut would likely need its own plugin model rather than adopting OFX as is.

That said, I would be very interested in hearing your thoughts if you are open to contributing or discussing what a practical plugin system should look like in this environment. Please file a GitHub issue if you can

The goal here is not to replace Premiere Pro across every professional workflow. But it is also not intended to be a toy editor.

Modern browser and GPU capabilities are already sufficient for a large category of practical video editing tasks. We are not targeting blockbuster scale 8K movies at least for now, but we are targeting real jobs people do every day across social, commercial, and non-commercial video production.

Amazing! That's really great to hear! Let me know if you ever have any issues or feature requests in the GitHub issues.

Good point. I agree that could be a very interesting direction.

I have used Remotion for years because the DX is great, but the performance and overhead is significant. Even something like attaching subtitles to a video can take around 10x more time and resources than bare FFmpeg because of the chromium layer.

A headless version of this wgpu renderer with a clean API and eventually a nicer DX layer such as a react renderer could be a strong replacement for that kind of workflow.

We actually already support text, transitions, and animation of basic properties as well as some filters. I would be interested to hear more about your use case and which capabilities you felt were missing from what you saw.

Thanks so much for the feedback. I just changed the license to ELv2.

Thanks for the feedback! I honestly had not read the license thoroughly. I just changed it to ELv2.

You are right. Thanks for the insights! I just changed the license to ELv2.

You are absolutely right. I just changed the license to ELv2.

Yep. Unfortunately, Firefox has a poor WebGPU support atm.

Seems interesting. I had not seen Omniclip specifically. But like most web-based NLEs I've seen, its UX feels unfamiliar. My goal was to build a desktop-grade professional editor that feels familiar to editors like Premiere Pro, DaVinci Resolve, and Final Cut Pro, rather than reinventing the editing experience.

Yes, that was part of the thinking behind the licensing choice. The goal was to keep the engine itself open source, while creating opportunities to monetize adjacent offerings like cloud file management, sharing, AI editing, and other higher-level capabilities.

Great question! I actually have built a poc that is not released yet. It's on the roadmap. It requires some tooling for the devs building these plugins like a CLI for building the WASM binaries, bundling, manifests, etc.

The current poc still has significant performance overhead, and that overhead grows as the plugin system becomes more powerful. If plugins are only allowed to apply a WGSL shader, the performance impact is almost negligible. But features that require broader access to timeline data, such as time shifts, speed ramps, or full timeline transformations, become much more expensive and make zero-copy architectures harder to reason about.

I see. I haven't decided on the commercial license yet. This might be temporary. I started this as part of another for-profit side project (for dubbing videos with AI). I may change the license later as the quote unquote "copyright owner". If I see the open-source community is active and finds it useful, I'd switch to a free-er license. Things are not super clear yet to me re what can be done with a web based video editor.

Yes, but the goal is to become the photopea of video editing. Something quick that you can launch via web that can support 80% of the day to day use cases.

Ah I believe I should have clarified browser support. Safari is not very well supported. Have you tried chrome?

Free and open source NLE video editor powered by WGPU, WASM, WebGPU, Rust, and Tanstack Start

The mission is to make a photopea-like alternative for Video Editing tools like Premiere Pro and Davinci Resolve

With React Forget's release timeline unclear, I've launched a community-driven version to keep innovation alive. I believe React Unforget can be to React Compiler what Preact is to React.

With React Forget's release timeline unclear, I've launched a community-driven version to keep innovation alive. I believe React Unforget can be to React Compiler what Preact is to React.