Going at this with a bit of unix philosophy: I think all these are very valuable things, but I'd much rather see them taken care of by different tools. Behind-the-scenes plumbing is really a task of its own, and should thus be taken care of by a distinct component.
The same goes for your other points, but one of them is specifically interesting: the "plugin system"; this is precisely what a module system on a language-level should do. A well built module should work almost like the plugins you're describing: pull them into your project somehow, maybe add minimal boilerplate, and have a new functionality that just works.
Lastly, the best practices part can also be achieved in a more modular way: using code standards and enforcing them with automation. No need for frameworks here; just throw a linter into your CI.
UNIX is a good analogy. Individual, specific tools can go a long way to abstracting out manual/redundant details. However, even the wiring up of these specialized tools can cause a high cognitive burden, which usually slows down the project development in a team environment. With a framework, you can point a new developer at good documentation to get them onboarded quickly for example.
I agree that languages can (and should) have a "plugin" system -- that doesn't mean frameworks shouldn't or can't too! It's a design principle more than a feature.
Not sure where to put this point, but many security "best practices" disappear from a developer's cognitive load because the framework just enforces them out-of-box. This cannot be understated. It's only a convenience, but a HUGE one.
Again, I'm not saying everyone has to use a framework for everything. I'm saying that there are definite reasons that frameworks are popular and useful. Marketing landing pages almost never need one, for example, but web apps bigger than one page typically do. My general advice is simple: don't use a framework unless you (might) need one for your project :) Like all good answers, "it depends".
I agree that languages can (and should) have a "plugin" system -- that doesn't mean frameworks shouldn't or can't too! It's a design principle more than a feature.
Indeed. I wasn't so much trying to argue that frameworks, when they are built, shouldn't have a plugin system, but that we don't need frameworks for their plugin system, because most languages already have similar mechanisms.
Not sure where to put this point, but many security "best practices" disappear from a developer's cognitive load because the framework just enforces them out-of-box. This cannot be understated. It's only a convenience, but a HUGE one.
As I mentioned, this can be mitigated to some extent using automation, like code linting and automatic testing, but even before that, smaller libraries can build their APIs around enforcing best practices just as frameworks can.
Like all good answers, "it depends".
Not only that, but it's also that different people will draw the line at different places. 😁
Not sure where to put this point, but many security "best practices" disappear from a developer's cognitive load because the framework just enforces them out-of-box. This cannot be understated. It's only a convenience, but a HUGE one.
Also malicious NPM security vulnerabilities.
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.
Going at this with a bit of unix philosophy: I think all these are very valuable things, but I'd much rather see them taken care of by different tools. Behind-the-scenes plumbing is really a task of its own, and should thus be taken care of by a distinct component.
The same goes for your other points, but one of them is specifically interesting: the "plugin system"; this is precisely what a module system on a language-level should do. A well built module should work almost like the plugins you're describing: pull them into your project somehow, maybe add minimal boilerplate, and have a new functionality that just works.
Lastly, the best practices part can also be achieved in a more modular way: using code standards and enforcing them with automation. No need for frameworks here; just throw a linter into your CI.
UNIX is a good analogy. Individual, specific tools can go a long way to abstracting out manual/redundant details. However, even the wiring up of these specialized tools can cause a high cognitive burden, which usually slows down the project development in a team environment. With a framework, you can point a new developer at good documentation to get them onboarded quickly for example.
I agree that languages can (and should) have a "plugin" system -- that doesn't mean frameworks shouldn't or can't too! It's a design principle more than a feature.
Not sure where to put this point, but many security "best practices" disappear from a developer's cognitive load because the framework just enforces them out-of-box. This cannot be understated. It's only a convenience, but a HUGE one.
Again, I'm not saying everyone has to use a framework for everything. I'm saying that there are definite reasons that frameworks are popular and useful. Marketing landing pages almost never need one, for example, but web apps bigger than one page typically do. My general advice is simple: don't use a framework unless you (might) need one for your project :) Like all good answers, "it depends".
Indeed. I wasn't so much trying to argue that frameworks, when they are built, shouldn't have a plugin system, but that we don't need frameworks for their plugin system, because most languages already have similar mechanisms.
As I mentioned, this can be mitigated to some extent using automation, like code linting and automatic testing, but even before that, smaller libraries can build their APIs around enforcing best practices just as frameworks can.
Not only that, but it's also that different people will draw the line at different places. 😁
Also malicious NPM security vulnerabilities.