There's a difference between front-end and back-end frameworks.
If your app is very task-based then you may not need a front-end framework.
But, a back-end framework I would say is pretty much necessary for any non-trivial applications.
They handle things like:
HTTP routing
HTTP validation
security
authentication
authorization
serialization
dealing with assets
database integration
web server configuration
documentation scaffolding (like swagger)
etc.
Trying to build that stuff on your own in a secure way is asking for trouble.
The alternative of "picking and choosing" lots of little libraries to do these things can have serious drawbacks: lack of documentation, lack of support in general, hard to find other developers who are experienced with the tools you chose, lack of holistic integration, etc.
One of the worst things that I keep seeing over-and-over in the industry is this desire to build custom ways to solve problems that have already been solved.
It's always better to spend time researching how other people have solved problems XYZ instead of putting your head down and writing code.
I've seen systems that were built using custom conventions and tools piled on top of each other. These teams will get new hires and have people leave... and now you have a team that has no idea how to even debug the system, build it, or just plain find stuff.
Back-end: use a web framework
Front-end: it depends
I tend to agree with you regarding the use of frameworks on the back-end. I may be wrong but I really feel like they are usually more focused and it's easier to understand how they work under the hood.
I'm more interested in the front-end frameworks for this discussion. You said "it depends". On what? Can you give us examples of projects / situations / contexts where you would choose to use a front-end framework and some where you would choose not to?
If you need a really snappy UI experience then front-end framework is probably the way to go. On the other side of the spectrum is an enterprise task-based app that needs to have top-notch security.
Security agreements in certain industries might actually prevent the use of front-end frameworks in general (I've heard of this but don't have any examples).
Something like this government standard might force you to go with the simple route (no front-end framework).
One might opt not to go with front-end frameworks for the overhead of having to manage multiple projects (front and back), extra build steps, etc.
One reason I love vuejs, for example, is that I don't need to build my entire UI with it. It's super easy to just drop it wherever I need - whether on a specific page, section of a page or even as a mini app within the larger app.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a difference between front-end and back-end frameworks.
If your app is very task-based then you may not need a front-end framework.
But, a back-end framework I would say is pretty much necessary for any non-trivial applications.
They handle things like:
Trying to build that stuff on your own in a secure way is asking for trouble.
The alternative of "picking and choosing" lots of little libraries to do these things can have serious drawbacks: lack of documentation, lack of support in general, hard to find other developers who are experienced with the tools you chose, lack of holistic integration, etc.
One of the worst things that I keep seeing over-and-over in the industry is this desire to build custom ways to solve problems that have already been solved.
It's always better to spend time researching how other people have solved problems XYZ instead of putting your head down and writing code.
I've seen systems that were built using custom conventions and tools piled on top of each other. These teams will get new hires and have people leave... and now you have a team that has no idea how to even debug the system, build it, or just plain find stuff.
Back-end: use a web framework
Front-end: it depends
I tend to agree with you regarding the use of frameworks on the back-end. I may be wrong but I really feel like they are usually more focused and it's easier to understand how they work under the hood.
I'm more interested in the front-end frameworks for this discussion. You said "it depends". On what? Can you give us examples of projects / situations / contexts where you would choose to use a front-end framework and some where you would choose not to?
If you need a really snappy UI experience then front-end framework is probably the way to go. On the other side of the spectrum is an enterprise task-based app that needs to have top-notch security.
Security agreements in certain industries might actually prevent the use of front-end frameworks in general (I've heard of this but don't have any examples).
Something like this government standard might force you to go with the simple route (no front-end framework).
One might opt not to go with front-end frameworks for the overhead of having to manage multiple projects (front and back), extra build steps, etc.
One reason I love vuejs, for example, is that I don't need to build my entire UI with it. It's super easy to just drop it wherever I need - whether on a specific page, section of a page or even as a mini app within the larger app.