I know what you're getting at, it would be very nice to have a standardised way of doing something, and only ever use that one way.
However, I whole heartedly disagree.
My first point on why I disagree: if we all work inside the box, where's the space to innovate and create something better?
Next up. Your attack on frameworks and libraries and how overchoice leaves you paralysed.
Firstly, frameworks and libraries are different. Frameworks are an out-of-the-box solution for most of the problems that a developer will run into when developing their app. Routing, forms (to give your examples), state management, XHR, debugging, testing, performance optimizations etc. The framework will also usually come with a set of best practices, and guard rails to ensure you are working within a set of constraints that will empower your and your colleagues and allow for more maintainable codebases.
Libraries on the other hand are generally focused on solving one problem and solving it well.
React can be composed with many different libraries and solutions meaning every react project could have a different architecture, but one that could fit the business problem more efficiently than a set in stone standard provided by a framework.
By having different options out there, it gives every frontend architect the chance to look at each option and analyse which option will suit their team better, and will solve the problem that they are trying to solve best.
Who is to say by choosing one you can't use any of the others? With tools such as Nrwl's Nx Workspaces you can have React, Vue and Angular projects live side by side and share code between each other.
Next up, web components. Amazing, truly standardised way of creating reusable pieces of code that can be shared across projects and dropped in. But does it out of the box solve your state management issues? Provide a maintainable approach to structuring your app? To guide developers on how they should be internationalising their small reusable component?
Frameworks and libraries aid development as they provide a starting point and guide on how to wire together all the components that make up the full application.
Out of the box, web components, and correct me if I am wrong, do not support server-side rendering which could lead to performance and potentially SEO issues for customers down the line right?
There can never be a one size fits all in software development, otherwise we would all only be writing in one language, Assembly, and we wouldn't have libraries and frameworks, and we would absolutely hate being a programmer and we would never be able to innovate or prototype or scale out applications to the global scale we can now.
Web component do support SSR. You just need to extend existing html components instead of just creating new ones. Some libraries facilitate this. Take a look at heresy and heresy-ssr (there are other).
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 know what you're getting at, it would be very nice to have a standardised way of doing something, and only ever use that one way.
However, I whole heartedly disagree.
My first point on why I disagree: if we all work inside the box, where's the space to innovate and create something better?
Next up. Your attack on frameworks and libraries and how overchoice leaves you paralysed.
Firstly, frameworks and libraries are different. Frameworks are an out-of-the-box solution for most of the problems that a developer will run into when developing their app. Routing, forms (to give your examples), state management, XHR, debugging, testing, performance optimizations etc. The framework will also usually come with a set of best practices, and guard rails to ensure you are working within a set of constraints that will empower your and your colleagues and allow for more maintainable codebases.
Libraries on the other hand are generally focused on solving one problem and solving it well.
React can be composed with many different libraries and solutions meaning every react project could have a different architecture, but one that could fit the business problem more efficiently than a set in stone standard provided by a framework.
By having different options out there, it gives every frontend architect the chance to look at each option and analyse which option will suit their team better, and will solve the problem that they are trying to solve best.
Who is to say by choosing one you can't use any of the others? With tools such as Nrwl's Nx Workspaces you can have React, Vue and Angular projects live side by side and share code between each other.
Next up, web components. Amazing, truly standardised way of creating reusable pieces of code that can be shared across projects and dropped in. But does it out of the box solve your state management issues? Provide a maintainable approach to structuring your app? To guide developers on how they should be internationalising their small reusable component?
Frameworks and libraries aid development as they provide a starting point and guide on how to wire together all the components that make up the full application.
Out of the box, web components, and correct me if I am wrong, do not support server-side rendering which could lead to performance and potentially SEO issues for customers down the line right?
There can never be a one size fits all in software development, otherwise we would all only be writing in one language, Assembly, and we wouldn't have libraries and frameworks, and we would absolutely hate being a programmer and we would never be able to innovate or prototype or scale out applications to the global scale we can now.
Web component do support SSR. You just need to extend existing html components instead of just creating new ones. Some libraries facilitate this. Take a look at heresy and heresy-ssr (there are other).