> Every large server-rendered app I've worked on ends up devolving to a mess ... that is a big pain to work on. I can honestly say the same about every large S

> Every large server-rendered app I've worked on ends up devolving to a mess ... that is a big pain to work on. I can honestly say the same about every large SPA style app I've worked on and I've worked on several. Rewrites are the norm in the JavaScript arena because code devolves into a complicated mess then people look at it and say "It's just a JS app–there's no reason it should be this complicated!" Then they rewrite it with the latest framework magic, rinse, and repeat. EDIT: I have to go further and (respectfully) say this comment I'm replying to is a load of BS. It's responding to a big pile of data saying that pageload speeds are not faster today with 'well that's not my experience.' The other aspect of this comment that sets me off is what I'll call the "you don't have to use JSX to use React" type rebuttal. With this type of rebuttal, you respond to complaints about the way 99% of people use JavaScript by claiming that it's not strictly necessary to do it that way, despite the fact that "that way" is how everyone does use JS as well as the way thought-leaders & framework authors suggest you use it. It's responding to real-world conditions in workplaces with a hypothetical-world where JS is used differently than it is today. This type of argument always shifts the blame on to individual developers for "using JS wrong." When 90+% of people are "using the tool wrong" there is a problem with the tool and it's not reasonable to shift the blame to every user who's trying to follow the latest "best practices." I wish we could acknowledge the facts of the JS ecosystem (like those presented in this article) rather than deflect with "not all JavaScript apps..." when mostly what you're talking about is demos & contrived speedtests, not real-world applications. If 'ifs' and 'ands' were pots and pans, we'd have no need for a tinker.