Deku: How we built our functional alternative to React

Great work guys, but correct me if I am wrong but it seems the reasons you decided to build Deku (if I am understanding what you have written) did not seem to be anything other than you were not a fan of how React doesn't take a completely functional approach to building components. Is that an appropriate assumption to make based on what you have written in your article?

I feel a little disappointed to be honest. Because as I was reading, I was expecting to read that you somehow had created a dom-diffing algorithm and matching library that was more performant than React.js, but really it just came down to the fact you didn't like how React.js looks. I was rooting for you from the beginning, expecting to see someone had created something superior to the much hyped React, but it didn't happen.

I don't want to hate on what you've done, looking through the code reveals that you put some considerable effort into Deku, but it makes me wonder if that effort could have been spent on perhaps learning the inner-workings of React.js and adapting it to your needs in its own fork. But having said that, Deku to me only has a few slight differences to React.js, the way components are built in Deku in comparison to React.js doesn't appear to be that dramatically different.

I don't want this comment to come across as yet another cynical HN commenter, but I just cannot see anything comprehensively different to existing solutions. I hate seeing talented development hours going to waste that could have been used to make an already existing project better.

So we looked for smaller alternatives, like virtual-dom and mercury. The documentation for virtual-dom was slim and we didn’t think the API for mercury was very user friendly.

Really? You found that it was better to write everything from scratch instead of modifying mercury for your use (thus making use of the very good virtual-dom library)? Do you know that the whole mercury source code[1] is only 126 lines of code?

Perhaps you should also know that your library usage examples, in the end, look just like mercury usage examples.

[1]: https://github.com/Raynos/mercury/blob/master/index.js ↗

Excellent work. I just went through the source code; lean and neat. I am going to offer this as an alternative to React in something I'm building.

To the new-to-JS programmers out here, I'd recommend waiting until a framework reaches a certain level of maturity. React is not just about the core library itself, it is also about the tooling and ecosystem. For example, you can use React dev tools in Chrome. You are more likely to find how-tos and documentation if you're using React. React Native might help with sharing code if native mobile is in your plans.

Like the documentation says, what this framework really gives you is the ability to skip the OO-style coding that React mandates, and use just functions and modules.