Hacker Newsnew | past | comments | ask | show | jobs | submit | mohebifar's commentslogin

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.

> Content is not my forte

The way to get good at something is by doing it a lot.

"Four things, running here"

This made me want to close the tab.

Take some time to think about what you've built and explain it in your own words. Get an LLM to help you with content ideas and editing, but write it yourself. It looks like a cool project.


You don't need to improve your writing. You can write extremely simply and people will vastly prefer it over slop. For example, translating your landing page into normal human language:

I built a compiler that compiles React code into vanilla JS.

Here are some examples

Vidact Start adds a bunch of server-side features - file routes, server loaders, SSR, hydration, and client navigation.

You can't use class components, createRef, most of the Children helpers, or React DevTools. Or any third-party package that ships precompiled against React's runtime.


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


It seems close to https://octanejs.dev/

  React’s programming model, compiled.
  The successor to Inferno, built around the same focus on performance. It brings React’s hooks, Suspense, and actions to a compiler-first architecture. 
  No virtual DOM, rules of hooks, or dependency arrays you have to maintain yourself. The compiler tracks what your code uses automatically.
Also do you have any benchmark like https://krausest.github.io/js-framework-benchmark/current.ht...

This comment is 10x more useful than your website. I'd suggest moving most of this copy onto the site just in a better format.

I would suggest adding a readable and formatted example of compiled code.

i suggest changing the name to something that is related to react. or atleast unrelated to Vue (the logo seems Vue inspired)

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


So for example, we offer a Digital Assets Management system, we off free plan right up to enterprise plans. If I wanted to enhance the users experience by having a tool *your tool( loaded for them to make quick basic modifications to their video media in browser that would not be possible.

The enhancement is not core to the product and available to free and paid users, but because its a commecial product your ELv2 license does not support it. As I understand, and its limited, the ELv2 is best suited for tools that are source available but only usedage in backend tools / single developer experience.

In your case that may be the case, so it depends on your desired direction, if you want media creators to be able to use their tool individually then sure, your license is fine.


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.


A chrome tab still has 4gb max memory limit right ?


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.


good info, thanks.


Sure, and most social/video workflows fit comfortably under that. Not everything is 8K RAW timelines.


Except WebGPU 1.0 isn't modern, it exposes hardware capabilities from a decade ago, better than WebGL 2.0 sure, which is what mobile GPUs were in 2010.

And the sandboxing get up to 4 GB, which in most cases will kill the browser depending on how many tabs are open.


Most real-world edits aren't hitting those limits. Constraint ≠ useless, it just defines the target use case.


Depends on the target audience.


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.


I am always on the lookout for a tool that can replace Premiere first of all, but that that is easy to do. Replacing After Effects, no one has ever accomplished, even remotely close. I have actually been able to somewhat (big asterisk here) use Remotion in some instances as an AE replacement.

I can use Remotion for example, to design any kind of animation in code, and overlay it on video, which, especially with AI, lets me do quite a lot.

One thing I did for a while, was render some assets, and then with remotion I created a template, and a script, that would pump out videos automatically. Think similar in concept to like, a Daily Mail news video, where its just some music, some footage, and some text overlayed. Every video is the same, they just need to drag and drop some assets in and click Go. Remotion was great for that.

Still, I made the actual assets for the graphics in after effects. In mine, a date would "glitch" onto the screen and then glitch out. Probably possible to do with code, obviously, but was much more complicated than using AE to design that.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: