Ultimately there will never be just one way to do front-end JavaScript because everyone brings their own opinions on solving computer science problems, heavily influenced by the language(s) they use on the back-end (or that they learned in school). Java, C#, and C++ developers will always fiend for some syntactic sugar that makes them feel like they're writing object oriented code in their "preferred" language. Ruby developers like their Emberjs and/or Coffeescript. PHP laravel developers tend to love Vue. Haskell devs love Purescript and/or Elm. And the list goes on and on.
If you're thinking back-end JavaScript is lacking this kind of churn you're mistaken (or just missed what's out there). Sails, Nest, Feathers, Nodal, Polka, Fastify, Hapi, Restify, and Express are all different, and mostly they are drastically different from each other.
It takes longer than a year to "learn JavaScript". Kyle Simpson brings this up in the intro to one of his books in the "You don't know JS" series that the fundamental flaw is that it's easy to get started with JavaScript and easy to hit a plateau with it and not realize how broad and deep journey into JavaScript mastery will take you.
The key point is not to over simplify or give up on learning the variety of dialects that are possible. JavaScript is still the most widely used programming language and when so many other brains are all doing a thing together you're inevitably going to see complexity, but you'll also find a ton of innovation and elegance.
If you choose to be a career JavaScript developer there's no escaping that, as you'll rarely get to decide how you get to code in JavaScript at a given employer. Becoming versatile and fluent in a variety of dialects is much wiser than searching for a sliver bullet. And that goes for front end as well.
Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
I think that's also because some libraries like Express are so low-level. It's just begging for a controller implementation or something else so you aren't working at every project as a middleware-oriented, request-based boilerplate extravaganza. And then from there, you realize how much responsibility is in your controllers and start layering down that responsibility. The building blocks have more or less all been agreed upon, whereas it seems like every front-end framework focuses on how to reinvent the wheel. Everyone talked about all the possibilities these frameworks would bring about and how it was going to change development forever, and now most companies are scrambling to build a reusable component set so they can get out of the game.
Ultimately there will never be just one way to do front-end JavaScript because everyone brings their own opinions on solving computer science problems, heavily influenced by the language(s) they use on the back-end (or that they learned in school). Java, C#, and C++ developers will always fiend for some syntactic sugar that makes them feel like they're writing object oriented code in their "preferred" language. Ruby developers like their Emberjs and/or Coffeescript. PHP laravel developers tend to love Vue. Haskell devs love Purescript and/or Elm. And the list goes on and on.
If you're thinking back-end JavaScript is lacking this kind of churn you're mistaken (or just missed what's out there). Sails, Nest, Feathers, Nodal, Polka, Fastify, Hapi, Restify, and Express are all different, and mostly they are drastically different from each other.
It takes longer than a year to "learn JavaScript". Kyle Simpson brings this up in the intro to one of his books in the "You don't know JS" series that the fundamental flaw is that it's easy to get started with JavaScript and easy to hit a plateau with it and not realize how broad and deep journey into JavaScript mastery will take you.
The key point is not to over simplify or give up on learning the variety of dialects that are possible. JavaScript is still the most widely used programming language and when so many other brains are all doing a thing together you're inevitably going to see complexity, but you'll also find a ton of innovation and elegance.
If you choose to be a career JavaScript developer there's no escaping that, as you'll rarely get to decide how you get to code in JavaScript at a given employer. Becoming versatile and fluent in a variety of dialects is much wiser than searching for a sliver bullet. And that goes for front end as well.
I know there's backend churn. It just seems slower and less frantic.
I think that's also because some libraries like Express are so low-level. It's just begging for a controller implementation or something else so you aren't working at every project as a middleware-oriented, request-based boilerplate extravaganza. And then from there, you realize how much responsibility is in your controllers and start layering down that responsibility. The building blocks have more or less all been agreed upon, whereas it seems like every front-end framework focuses on how to reinvent the wheel. Everyone talked about all the possibilities these frameworks would bring about and how it was going to change development forever, and now most companies are scrambling to build a reusable component set so they can get out of the game.
That's ONLY because there are far, far fewer coding back-end JavaScript than front-end.