I am often frustrated in this ecosystem by how people build things without any clear conceptual model, and then they document them by saying "it is so fast, it just works like magic". It is impossible to compare two approaches because there are no facts available to compare them on.<p>Like for this one from a peek at the source code it appears to try to parse JavaScript at runtime using regexes (<a href="https://github.com/radi-js/radi/blob/master/src/index.js#L4" rel="nofollow">https://github.com/radi-js/radi/blob/master/src/index.js#L4</a>) which is great for demoware and not at all something I'd want to use in production, but that is not mentioned anywhere in the site or blog post.<p>I don't mean to just dump on this project in particular, which could just be a fun toy side project for the author, because this problem is endemic. (But then why go to all the effort to make all the marketing materials for it without actually writing any docs?)
They compared Radi to React Stack, not React Fiber. That's being sneaky.<p>If you run the React Fiber demo, you'll see it's just as fast: <a href="https://claudiopro.github.io/react-fiber-vs-stack-demo/fiber.html" rel="nofollow">https://claudiopro.github.io/react-fiber-vs-stack-demo/fiber...</a>
I'm not primarily a Javascript developer, but I seem to remember that attaching event listeners to Object fields and modifying the DOM in event handlers is how Javascript development was done 5-10 years ago. Am I missing something? Are we going full circle?
I'm not a frontend developer and don't know really know JavaScript frameworks. That said, it seems like something very well established like React would choose to have a virtual DOM for a good reason.<p>Surely there must be some tradeoffs that the author makes for his design to get better performance. Could somebody explain the cost/benefit of doing things one way versus the other?
Surplus [1] is the fastest framework in the big JS benchmark challenge, and it too uses the native DOM directly rather than a virtual DOM. Looking forward to seeing Radi.js added to that benchmark suite to really put it to the test.<p>[1] <a href="https://github.com/adamhaile/surplus" rel="nofollow">https://github.com/adamhaile/surplus</a>
This looks similar in many ways to mithril[1] -- somewhat similar api - mount, view, r("input") vs m("input"). The counter example[2] looks similar[3] I'd be interested in seeing comparisons between the two.<p>[1] <a href="https://mithril.js.org/" rel="nofollow">https://mithril.js.org/</a><p>[2] <a href="https://github.com/MithrilJS/mithril.js/blob/5956314e3655a3c85f8425bffc2bd76c1c541a3b/docs/mount.md" rel="nofollow">https://github.com/MithrilJS/mithril.js/blob/5956314e3655a3c...</a><p>[3] <a href="https://github.com/radi-js/radi/blob/master/examples/counter.html" rel="nofollow">https://github.com/radi-js/radi/blob/master/examples/counter...</a>
I recently did a project with morphdom (<a href="https://github.com/patrick-steele-idem/morphdom" rel="nofollow">https://github.com/patrick-steele-idem/morphdom</a>) using only ES6 template strings and a render loop that checked for changes to a global state object and patched a re-computed DOM string using morphdom. Couldn’t have been an easier and more pleasurable experience.
The reason diffing and virtual doms are used are to prevent unnecessarily repainting the browser window 1000 times a second. If I have 5 updates to make, I want to do those in one paint, instead of 5. So the process is change -> change -> change -> paint.<p>With this framework's model, the process would be change -> paint -> change -> paint etc. etc. Sure, you get nice FPS (because it's painting a LOT), but that will destroy battery performance on mobile phones and I don't need 60 FPS in my shopping web app.