What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.
If you're unaware, "fanboys" is a grenade to incite juvenile flamewars instead of collegial discussion.
>What's missing is that you can make complex web apps without any of these things,
To attempt better instructive discussion instead of arguing from vague and generic platitudes about "needless complexity", can you explain how your simulacra.js (~12kb) is better than reactjs (~130kb)?
For example, does Simulacra have the same features that React? If so, how did you eliminate ~100kb of Javascript to accomplish it, or conversely, what redundant or incompetent code takes up additional ~100kb of wasted bytes in React?
If Simulacra accomplishes its smaller 12kb footprint by having less features, which features in React do developers no longer need because of "modern browsers have standards-compliant DOMs".
In other words, some concrete analysis would be a more productive discussion.
But if you're going to accuse React's value proposition as being just a marketing pitch, I'd love to hear what evidence that virtual DOM is in fact pointless, and then why Angular 2 and Ember are doing the same sort of thing despite this, even though they have vastly different programming models than React.
Also, regarding your last point, I really doubt Facebook accidentally made DOM diffing without realizing it would improve performance of reactive programming in JS.
> significantly nicer to code for than DOM binding
There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.
A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done.
Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many components, React (and Preact and etc.) absolutely will beat the naive answer because it will get rid of needless DOM updates. And it will do that without you having to do caching everywhere, because it's all done in one place at the lowest level before hitting the page. I'd love to see the horrible abomination of hand DOM updates that can magically beat a large React app.
edit: Just noticed this wasn't a reply to me, but I think the points I raise here are still fairly valid, if I'm understanding your reply correctly. Sorry if that was confusing.
https://github.com/guscost/protozoa
Performance optimizations, cross-browser events, and safety features not included. Good luck if you ever have to build a huge UI with it, you'll be the first person to try!
Seriously though, while it's pretty cool for embedding interactive DOM nodes in a webpage, don't think that you always need "simple" when sometimes "easy" is a much better idea.
