10 ms·
Show HN: I made React with a faster Virtual DOM
Hi! I made a React compatibility library for a Virtual DOM library (https://github.com/aidenybai/million 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 https://stackblitz.com/github/aidenybai/million-react-compat
- bsimpson 4y agoCongrats! 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.
- sk0g 4y agoEven better, for something similar to React, but much simpler and more streamlined, I turned to Svelte. As a backend dev, it was the first frontend framework that I actually stuck with. In retrospect, I think what really confused me was that React components return HTML, which is a weird semantic I can't intuit, after a few attempts. Svelte lets you declare everything separately, while being more succinct and readable (IMO at least).
- Vinnl 4y agoProbably not too relevant/helpful anymore, but the problem might be that React components don't return HTML: they're functions that return a collection of JS objects that describe what the DOM ("HTML") should look like, and React compares that to what the DOM actually looks like and applies the relevant changes. These functions get called every time something changes. Having that mental model is vital for React "clicking".
- wussboy 4y agoAgreed. Svelte was the first front end framework that ever made sense to me. I was able to do things in it that I never dreamed of doing in React/Vue.
- FractalHQ 4y agoThe combination of Svelte’s DX and performance is truly unmatched and unlocked a lot of doors for me as a developer too.
- aidenyb 4y agoI appreciate the feedback. Will be adding to the readme!
- presentation 4y agoBiggest thing for me is that this library won't get abandoned like the ones that the intro section for this library refers to. Unless the value prop is really, really good I would stick to the bigger options for that reason alone.
- aidenyb 4y agoI made some adjustments to the README [1], thanks again for the helpful feedback. [1] https://github.com/aidenybai/million#readme https://github.com/aidenybai/million#readme
- codedoctor 4y agoIt looks very good. I hope there will be support in nextjs and a nice material library for this
- djbusby 4y agoHope 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)
- aidenyb 4y agoDefinitely going to check Riot out. I've tried it while it was in the initial release, seems really cool they're trending towards compiled!
- bryans 4y agoRiot has its quirks, but it should really get more love than it does. I found it to be a breeze to work with, and they were doing things correctly even back when the pre-rewrite versions of Angular and React were still getting it very wrong.
- mario_kart_snes 4y agoIs this similar to SolidJS? https://www.solidjs.com/ https://www.solidjs.com/
- latchkey 4y agoI've been doing a small project in SolidJS recently and really enjoying it. It is a lot easier to reason about than React. My only complaint is that the router is kind of alpha and a moving target, so the examples are now out of date with the latest version. Also, like most open source projects, the documentation is lacking in a lot of ways. That said, if you know React and you're not doing anything too complicated, I highly recommend it.
- lf-non 4y agoAgree 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 https://github.com/solidjs/solid-app-router
- aidenyb 4y agoNot similar to SolidJS in internals (fine grained rendering), but same idea of compiling JSX and optimizing it beforehand
- spankalee 4y agoThe 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/ 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.
- bsimpson 4y agoLink to the Apple proposal?
- mfe7 4y agoI remember seeing this a few years ago: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
- esprehn 4y agoI believe this is the current iteration: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... You can learn more of the history here: https://www.w3.org/2020/10/TPAC/parts_and_template_instantiation.html https://www.w3.org/2020/10/TPAC/parts_and_template_instantia... https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
- bsimpson 4y ago
- nick__m 4y agothere'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.
- aidenyb 4y agoThanks!
- Existenceblinks 4y agoI 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.
- arinlen 4y ago> I hope developers with decent skills move on on Hook style api (...) What's your opinion on Hook-style APIs?
- maxloh 4y agoI have mixed feelings. Hook style API allows us to write the same functionality with less keystrokes. But I found that I interpret how it works object-orientedly. It feels wierd to write them as functions instead of classes. If there are multiple appearances of the same component, they belong to different "instances". Components get updated by modifying their state, or in other words, their "instance variables".
- mekkkkkk 4y agoThe only major downside with hooks is that they are sort of non-intuitive imo. Writing UIs with hooks once you grok it properly is really nice and terse. What's your beef with them?
- Existenceblinks 4y agoIt destroys pure view layer as pure function and that makes it less compostable/reusable. Not be able to just a view function by just passing arguments.
- Existenceblinks 4y agoSeems like https://millionjs.org/benchmarks https://millionjs.org/benchmarks is hanging (tested on firefox with 4GB RAM machine) and the page shoot me 4.8 GB of memory.
- natly 4y agoOn that note, the main page https://millionjs.org/ https://millionjs.org/ is weirdly janky/slow when scrolling. Doesn't make sense to me since there's barely much on it.
- aidenyb 4y agoMillion's docs uses https://github.com/shuding/nextra https://github.com/shuding/nextra, which uses React + Next.js for underlying code
- aidenyb 4y agoNot sure why that's happening, looking into it
- maxloh 4y agoWhat is its difference with Preact?
- aidenyb 4y agoCheck the value prop: https://github.com/aidenybai/million#what-is-million https://github.com/aidenybai/million#what-is-million
- a13n 4y agoIs 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.
- deleted 4y ago[deleted]
- lsalvatore 4y ago
- azeirah 4y agoDon't think it's a pain point, but better performance without feeling a difference (ie not using bubble sort for sorting but using quicksort) is just.. always nice?
- smolder 4y agoHow often are you testing on low end devices like say 5 year old budget tablets or netbooks? Speed also correlates with energy use. Does using your site drain batteries faster than it needs to? I find these things often aren't given appropriate consideration, although speed improvements could easily be negligible for your app and its users.
- jimmySixDOF 4y agoMaybe with something like React-Three-Fiber where the frame rates can be 11ms
- aporetics 4y agoWell, let’s look at it from a different angle; not the angle of the user or the developer, but as a matter of computational work and the energy consumed by that work. In a single application or even the life of an application all it might be negligible. But when does it not become negligible? What if react adopted the change and every react app What about for every react app in use suddenly used a fraction less computational power each render? And is it just a monetary cost? Yes, if energy use is your primary concern there are easier ways to reduce it. But in the above context it seems clear that you should take your gains where you can get them.
- sgb_QQ 4y agoOP, 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.
- aidenyb 4y agoI'm aware! AFAIK it's just a auto memoizer for React currently
- aidenyb 4y agoHey, 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 :)