Show HN: I made React with a faster Virtual DOM

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • million

    Optimize React performance and make your React 70% faster in minutes, not months.

  • Hi! I made a React compatibility library for a Virtual DOM library (https://github.com/aidenybai/million).

    The idea is to have much faster rendering (a compiler optimizes virtual DOM beforehand) while ensuring the same developer experience React provides.

    This is very, VERY early stage, so be prepared for weird bugs / plugin incompatibility / etc. If you have any suggestions, I'd be more than happy if you replied in a comment with it!

    You can spin up the demo here >> https://github.com/aidenybai/million-react-compat

  • million-react

    Discontinued ⚛️ Vite starter for Million.js

  • Hi! I made a React compatibility library for a Virtual DOM library (https://github.com/aidenybai/million).

    The idea is to have much faster rendering (a compiler optimizes virtual DOM beforehand) while ensuring the same developer experience React provides.

    This is very, VERY early stage, so be prepared for weird bugs / plugin incompatibility / etc. If you have any suggestions, I'd be more than happy if you replied in a comment with it!

    You can spin up the demo here >> https://github.com/aidenybai/million-react-compat

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

    SurveyJS logo
  • solid-site

    Code that powers the SolidJS.com platform.

  • htm

    Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support.

  • Just to add on here, the Preact author made a generalized utility for tagged template => vnode conversions: https://github.com/developit/htm

  • dom-expressions

    A Fine-Grained Runtime for Performant DOM Rendering

  • Solid is great, you can also use it with hyper dom expressions: https://github.com/ryansolid/dom-expressions

  • solid-router

    A universal router for Solid inspired by Ember and React Router

  • Agree wrt. Solid being easier to reason about.

    Is the router you are using solid-app-router [1] ? Have been working with it for last few months and it has been generally stable (my usecases are not particularly complex though).

    The docs for the solidjs core has also massively improved recently.

    [1] https://github.com/solidjs/solid-app-router

  • nextra

    Simple, powerful and flexible site generation framework with everything you love from Next.js.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • astro

    The web framework for content-driven websites. ⭐️ Star to support our work!

  • This sounds like a websocket version of Astro (https://astro.build)! Very cool stuff.

  • lexical

    Lexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.

  • It is an old idea with reactive graph and direct bindings (knockout.js, etc), but as always, implementation is way more important than some abstract idea, and ~6 years ago Adam showed that it is actually possible to implement this idea quite efficiently (S.js+Surplus). Then Ryan started working on Solid.js and it became one of the most popular implementation of this idea.

    There are a lot of things that I don't like in Solid.js implementation, like it seems that he still don't care about performance in general and only focuses on getting high score in js-framework-benchmark (optimizing library for two cases: DOM template cloning and one-to-one reactive bindings). But I believe that it is not something that is inherently wrong with an idea and there are a lot of room for improvements in implementations.

    I guess the main tradeoff with such idea is that it has a slightly higher learning curve than something like React with its top-down recompute/rerender approach (as long as we don't care about performance). But when we start to add reactive systems to react/svelte/etc to improve performance, at that point it becomes more complex than just using UI library specifically designed for reactive system.

    Right now I am trying some experiments with new algorithms and datastructures for reactive system, that I specifically designed for UI problem space, to actually beat vdom implementations in microbenchmarks that were heavily biased towards vdom-like libraries (reimplementing top-down dataflow+diffing in reactive system with derived computations, it is super useful when building something like https://lexical.dev/ )

  • js-framework-benchmark

    A comparison of the performance of a few popular javascript frameworks

  • > And if there are any other good resources out there, then do share! :)

    Unfortunately there aren't any good resources on this topics. Everyone is just focusing on a diffing and unable to see a bigger picture. In the end, all feature-complete libraries implement diffing algorithms for dynamic children lists and attribute diffing for "spread attributes", so with this features we are kinda already implementing almost everything to work with DOM and create a vdom API, everything else are just slight optimizations to reduce diffing overhead. But working with DOM is only a part of a problem, it is also important how everything else is implemented, all this different features are going to be intertwined and we can end up with combinatorial explosion in complexity if we aren't careful enough. Svelte is a good example of a library that tried to optimize work with DOM nodes at the cost of everything else. As an experiment, I would recommend to take any library from this[1] benchmark that makes a lot of claims about its performance, and start making small modifications to the benchmark implementation by wrapping DOM nodes into separate components, add conditional rendering, add more dynamic bindings, etc and look how different features will affect its performance. Also, I'd recommend to run tests in a browser with ublock and grammarly extensions.

    And again, it is possible to implement a library with a declarative API that avoids vDOM diffing and it will be faster that any "vdom" library in every possible use cases, but it shouldn't be done at the cost of everything else. But unfortunately, some authors of popular libraries are spreading a lot of misinformation about "vdom overhead" and even unable to compete with the fastest ones.

    1. https://github.com/krausest/js-framework-benchmark

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts