One ever present debate in the React community had been whether you should `useMemo`/`useCallback` all non-primitive props or not. I've often taken the position that you should in real world teams because it's too much work to determine exactly when to otherwise , whereas others argue that it's too much runtime overhead (and noise) and not worth it. u/acemarke has a good summary of the arguments . All that to say, I was curious if this compiler is essentially the React team conceding that you _should_ memoize everything. The answer is pretty interesting - the compiler actually memoizes things in a more efficient way than `useMemo` can . So it's almost the best of all worlds: improved rendering performance from memoization, cheaper memoization cost, and none of the noise of `useMemo`s sprinkled everywhere. I think we'll have to wait a bit longer to see if this works out in practice, and I'm not crazy about having to add another layer of transpilation, but if it works well this will be a pretty big win for React projects in general I think. More on reddit.com

Hey folks! This is something that I have been working on for a few months.  It's a browser based "runtime" where you write code, the compiler transforms it, and the runtime executes it visually. I built this because I hate designing software/systems in http://lucid.io/ and even the new age tools like http://eraser.io/ . The diagrams are too static and the solution too cookie-cutter. React has been a life saver honestly. Since I come from a backend background, I really needed something with an established ecosystem and something that just clicks! Every major component that I needed to pull it off, be it the IDE, state-management or actually visualising, had amazing react support. I don't think this would have been possible for me in any other ecosystem to learn this quickly and build. Here’s how it works internally: Users write class-based code, and my compiler applies my custom transformers while building the code. The transformation is simple but rigorous. It converts methods and other surrounding functions into `AsyncGenerators`, essentially something that can pause execution. With this step we convert the code into state-machines. We have a bare bones runtime, along with a heap and stack. Any object that gets created, also gets registered on the heap. And any method call that happens, gets recorded on the stack. Then we simply let things play out and render the heap and stack. This rendering is performed on https://reactflow.dev/ Here are some examples you can try right away: Here's a medium level example involving an event stream of stock prices and a system calculating its running avarage. https://app.metz.sh/template/7 Here's something a bit more complex and more real. This one is about a polling setup with multiple pollers interacting with databases. https://app.metz.sh/template/4 And this last one is my favourite and of the reason I built it. It's about a payment system which books two entries for the same payment. This one is personal since I made the same mistake a few years ago which led to an actual loss of money! https://app.metz.sh/play/0286b754d9e4408ba172e344eeac47b9 Github: https://github.com/metz-sh/simulacrum Playground: https://try.metz.sh Docs: https://docs.metz.sh More on reddit.com

thanks for posting! please let me know if anything is unclear or any other general feedback More on reddit.com

Great thang. More on reddit.com