[buchanaf]

Short answer: maintainability, performance, cross-browser consistency, community plugins, easier developer on-boarding, and framework updates and maintenance (which amplifies most of the previous).

Obviously a lot depends on the complexity of the website, but for the most part, any web _application_ will be better served by a framework. Heck, most static sites can now be amplified by layering on frameworks if done correctly (ie GatsbyJs).

[dmytrish]

> performance – I can see how a SPA may be slower to load initially but use fewer data and be more interactive later.

> cross-browser consistency - do you mean that client-side frameworks are usually well-tested in different [versions of] browsers, much more so than vanilla javascript?

> community plugins - do you mean that ecosystems around JS frameworks are more developed and powerful than around server-side web-frameworks? Can you elaborate why?

I still can't understand the points behind "maintainability", "easier developer on-boarding" and "framework updates and maintenance" for client-side frameworks.

[buchanaf]

All of that and more.

- Performance: most major frameworks use a virtual DOM to minimize the number of repaints. Off the top of my head, Vue has computed properties that cache calculations and React has aysnc/priority rendering. I imagine there's a good deal of other stuff.

- Cross-browser consistency: React has a synthetic event system that normalizes events between all of the different browsers. There's certainly less "gotchas" between browsers than there used to be, but its nice relying on a web framework with a huge testing suite to ensure those "gotchas" are taken care of.

- Community plugins: I was more alluding to the number of UI components that are available for use. Have you ever tried to make an accessible, styled dropdown menu? How about one with search capabilities or multiple selections? There's a lot of tricky UI components that have been created by the community at large that you can just drop into your application without having to spend a day or two developing and another month or two debugging.

- Maintainability: front-end frameworks generally come with conventions. They encourage modular, reusable components. This is much more difficult to achieve with vanilla, and if it is achieved, you have in essence created your own "custom" framework.

- Easier developer ob-boarding: Like I mentioned above -- framework conventions. In addition, framework documentation and examples by the community. You can't run through a bunch of tutorials if Joe Schmoo "winged" the entire front-end code base with vanilla.js.

- Framework updates: React just released Fiber, a huge update that dramatically lowered the size of the library, increased the perceived rendering performance, and added additional APIs. There is a huge group of open source contributors continuing to perfect that library. That's pretty sweet.

[ccachor]

It is more maintainable (in the sense that functionality isn't bound to the DOM structure or class names). I'd argue there's a bit less repetition across your app, but it's not as significant if you're smart about code re-use.