In short, the OP changed the architecture from a client-side rendered app (in React) to a server-side rendered one (built on a custom-made framework cloned from Intercooler.js) and that resulted in a significant performance improvement for their app.
Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from the read. Maybe just "if YOU build/find YOUR own framework for YOUR problem space excitement will follow."
On the other hand, I doubt the complexity issues, also mentioned by the OP throughout the article, was solved by using the new framework. In fact:
> On the developer side, I think React is better still
Okay, maybe I should elaborate a bit on that. But React is better for developer experience like it is. But when you're talking about code splitting and service workers and other crap it's just a deepest rabbit hole out there. It's unmanageable.
6-12 months from now another article will be warranted, the author will have changed their mind again. That's the pattern you see throughout the entire thing, non-stop jumping. It's a solid bet as an indicator of the lack of maturity as a developer, incessant tech hopping.
Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from the read. Maybe just "if YOU build/find YOUR own framework for YOUR problem space excitement will follow."
On the other hand, I doubt the complexity issues, also mentioned by the OP throughout the article, was solved by using the new framework. In fact:
> On the developer side, I think React is better still
So tit-for-tat.