The shiny new framework can create a static site and a true web app and is likely well documented with examples. The tradeoff is a subset of users have longer load times.
The shiny new framework can create a static site and a true web app and is likely well documented with examples. The tradeoff is a subset of users have longer load times.
I don't know that we spend enough time questioning whether that complexity is necessary.
Because, yes, if we want to transmogrify Web standards largely intended for a static document model into a full-blown application platform then there will definitely be complexity involved. Especially true if we do so while keeping those Web idioms fully surfaced.
But, how often do we really need SPAs versus traditonal Web apps that feature judicious use of dynamic behavior? I doubt that the complexity chasm is frequently worth it.
But, if it is, then we need to commit to standards/frameworks that push down the complexity by abstracting away the underlying Web idioms that create it.
The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux.
If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.
It's almost easier to learn JEE and Glassfish than stuff such as Next.js...