I started this project out of interest in building a UI framework for a completely different language/platform inspired by React. Quickly realized I didn’t understand everything React was doing to allow their API. Rebuilding React was extremely useful for learning more about the framework. Hopefully, this article is useful to other people in the same way.
Also sometimes known as “not invented here syndrome”.
Sometimes it’s useful to know how something works and to be easily able to change every piece of the stack, other times it’s a massive waste of time and the end result is a worse documented and worse developed solution than what hundreds if not thousands of people have built and tested over the years.
Depends on what you’re working on, really, I’ve seen some really unfortunate stuff once people start rolling their own security stuff and it’s not like you can ask StackOverflow about why some random bespoke library or framework is full of weird behaviour.
as he probably should. but building everything from scratch just is the autistic urge to actually understand what you're doing. not implying you're autistic or anything, but I am and I can't always stop myself from doing the same thing, hehe.
Good on ya. I gave a presentation a few years ago on building Promise from scratch and learned a lot in the process. I’ve always wanted to do the same for React.
Sciter has Reactor - its own native and built-in implementation of React.
Main difference is that component is instanceof Element - components are DOM elements. This allows to unify React and WebComponent under the same umbrella/mechanism. Yet to extend standard DOM methods by use of JSX, so this
someDomElement.append(<div>Hello</div>)
works just fine - appends content from the vDOM.
In fact Reactor is three entities implemented natively:
Nice! I did a similar project, more focused on creating an Elm architecture framework in TypeScript here[1]). I based it on implementing virtual-dom logic for both Elm codebases and Derw's renderer. Since it's a decent amount of code, I couldn't find a good way to represent it in a blog post, and ended up making a commit-by-commit example on Github instead. Since it's FP-focused, it doesn't support useEffect/useState like this post, but rather has an external subscription/message system instead.
It does support server-side-rendering, hydratation, and async events. It's a bit different in implementation in the OP's post, but I think the most important thing any reader should take away is that at the core, virtual-doms can be quite simple with plenty of room for further optimization.
