I recommend every junior developer start out by building a few websites from scratch (vanilla js/css/html).
Only THEN can you understand the benefit of what any framework brings to the table. Otherwise you can't differentiate between what's doing what.
Having said that, React/Vue/Ng/Svelte are popular frameworks because:
they take care of redundant plumbing in every project
force some best practices including security (like no XSS/CSRF)
have nice plugin systems for adding yet more time-saving libraries
create a shared set of how-to-do's for teams (like code structure, unit testing, etc)
hopefully reduce some code bloat / wiring due to abstractions and namespacing
In one word, frameworks enforce STANDARDS, which are critical on team projects. There is also much flexibility there, so no they are not a silver bullet, and not even essential. But they do help a lot!
I'm at the point of applying vanilla JS to exercise projects after a few months of learning and I'm happy that when I started some friends told me to stick to vanilla before any framework, and of course I listened to their advice.
The only thing that's catching my eye at this point is Jquery, because I saw some easy solutions in Jquery vs vanilla JS.
But, until I'll have a good grasp and understanding of how and what can I use in order to finish my projects with JS, I won't move to any framework because I firmly believe that we need to crawl before walking or running.
These days, almost nothing is easier in jQuery unless you're targetting older browsers. Many "jQuery vs. Vanilla" examples specifically use very old APIs that are even less relevant now than however many years ago those comparisons were made.
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.
I recommend every junior developer start out by building a few websites from scratch (vanilla js/css/html).
Only THEN can you understand the benefit of what any framework brings to the table. Otherwise you can't differentiate between what's doing what.
Having said that, React/Vue/Ng/Svelte are popular frameworks because:
In one word, frameworks enforce STANDARDS, which are critical on team projects. There is also much flexibility there, so no they are not a silver bullet, and not even essential. But they do help a lot!
I'm at the point of applying vanilla JS to exercise projects after a few months of learning and I'm happy that when I started some friends told me to stick to vanilla before any framework, and of course I listened to their advice.
The only thing that's catching my eye at this point is Jquery, because I saw some easy solutions in Jquery vs vanilla JS.
But, until I'll have a good grasp and understanding of how and what can I use in order to finish my projects with JS, I won't move to any framework because I firmly believe that we need to crawl before walking or running.
These days, almost nothing is easier in jQuery unless you're targetting older browsers. Many "jQuery vs. Vanilla" examples specifically use very old APIs that are even less relevant now than however many years ago those comparisons were made.
Thanks for the tip. 👌
You're taking the right approach! A framework can only make something "easier", but you need to know what is "hard" first.
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.