In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade.
That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server.
> Me, I never really did any site-generation or server-side rendering stuff
> I find [...] reflect the skillsets of their authors
I disagree, but I am 100% with you on the imperative for structure and order in the codebase.
A typical angle - and it used to be very good - is that vanilla JS doesn't offer a good way to organize common code or impose some sort of structure. I find this to be at the heart of "wont work with a team" arguments. This is no longer the case and hasn't been for some time now (~10 years):
>In the current landscape doing things "the hard way" in plain JS is often simpler than with React.
I'm not sure what "simpler" means to you.
It is extremely simple to create and deploy a framework based app; `npm create vue` give it a name, answer a few questions or accept the defaults.
I find programming in such an environment very "simple", because the framework is hiding a lot of complexity.
> You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system.
All I can say is: if you have a codebase that has those issues, then the alternative implementation without a framework would be much more difficult to manage.
It's true that Webpack can be very complex to configure, but out of the box configuration gets you pretty far.
In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade.
That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server.
> Me, I never really did any site-generation or server-side rendering stuff
> I find [...] reflect the skillsets of their authors
now I'm unsure if this is satire...