from Hacker News

Show HN: I made React with a faster Virtual DOM

by aidenyb on 6/1/22, 12:34 AM with 88 comments

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://stackblitz.com/github/aidenybai/million-react-compat

  • by bsimpson on 6/1/22, 1:34 AM

    Congrats!

    Considering the pretty docs, I'm guessing you're trying to get people to use this. It would be useful to have the value proposition front-and-center (e.g. in your README).

    If someone is in the React mainstream, they use React. If they like the devex of React but want something simpler/more streamlined, they use Preact. I'd appreciate a "This is why you might choose this library instead of Preact. This is why this is a new library instead of a patch to Preact. This is an honest assessment of when React/Preact is a better choice than Million." section.

    There are often tradeoffs in library development. Being honest about the ones you chose helps other developers trust you.

  • by a13n on 6/1/22, 12:55 PM

    Is React rendering performance really a pain point worth solving? I've never thought to myself "man I wish React would render faster"... It doesn't seem like this is whatsoever a bottleneck for our application (~1k unique components).

    I feel like the main pain point with React is that routing, bundling, SSR, state management, etc. have to be painfully stapled together, and this is what frameworks like Next.js solve for.

  • by nick__m on 6/1/22, 3:31 AM

    there's a little error in the demo, line 6:

      const [value, setValue] = useState(0);
    should be:

      const [value, setValue] = useState(init);
    or the parameter init could be removed from the component.

  • by djbusby on 6/1/22, 1:51 AM

    Hope you're looking at tools like RiotJS and SvelteJS as well. Riot specifically has a compile step (but you can run un-compiled while building)

  • by sgb_QQ on 6/1/22, 3:00 PM

    OP, are you aware that the React team are testing their own compiler for React? Not to say your project is obselete, just want to make you aware. The team talked about it at React Conf 2021 (see youtube videos), currently named React Forget.

  • by Existenceblinks on 6/1/22, 6:08 AM

    Seems like https://millionjs.org/benchmarks is hanging (tested on firefox with 4GB RAM machine) and the page shoot me 4.8 GB of memory.

  • by mario_kart_snes on 6/1/22, 2:00 AM

    Is this similar to SolidJS?

    https://www.solidjs.com/

  • by aidenyb on 6/1/22, 4:11 PM

    Hey, author here of this Show HN post. I appreciate all the comments on the post, but I would appreciate if content you post is on topic. I love the discussion about HN culture but I don't think it's relevant to this post, and it's quite overwhelming to read so many comments. If you'd like, you can start your own discussion on HN about this rule (as long as it is along the HN guidelines).

    Other than that, thank you so much for all the awesome feedback, it's really appreciated :)

  • by maxloh on 6/1/22, 8:32 AM

    What is its difference with Preact?

  • by spankalee on 6/1/22, 2:30 AM

    The fastest virtual DOM is no virtual DOM at all.

    Rather than creating and diffing a fine-grained tree of elements every render, it's very easy to use the syntactic structure of a template to see exactly what parts can and cannot change. To get stable and minimal DOM updates you just compare the template identity to the previously rendered template - if they match you update the dynamic expressions, if they don't you clear and render the new template.

    This is what we did with lit-html and it's quite a bit faster (and smaller) than React and doesn't require a compiler because it uses standard JS tagged template literals. https://lit.dev/docs/libraries/standalone-templates/

    It's a very simple approach and very, very hard to beat in the fast/small/simple/buildless tradeoff space. I hope one day that the DOM can include standard updatable DOM with a technique like this on top of the template instantiation proposal from Apple. It's such a common need that it should be built in.

  • by Existenceblinks on 6/1/22, 5:59 AM

    I hope developers with decent skills move on on Hook style api (I've seen at least 3 better-than-react libs still copy this) I'm 100% sure it's not going to last long, someone will come up with a better api very soon.