As I learned Javascript over the past year, I was focused mostly on the front end. I think that tends to be the direction that most learning materi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I'm not really sure what the point of this article is. I feel like I see a lot of people taking shots at front end, and I don't think there are any better solutions than what we've been doing. Backend sits on top of tech that hasn't really changed in who knows how long. Meanwhile front end has had to grow to support all kinds of new UI/UX's.
Frontend is dreaming up new easier ways of doing things. That causes a lot of churn. Yes a big problem is backward compatibility. I can tell you now that web components, while great, still aren't the solution to the constant learning that we must do. There are lots of problems with web components that have yet to be solved. Styling is a sore point for one. For two you're still using a library to develop web components. Polymer had 3 major versions with big breakages between 1 and 2. Ultimately Polymer was superceded by lit-element. There are also a number of other competing libraries. And to top it off web components only solve the component aspect. They don't manage state, handle routing, work as services, do form stuff, etc. All things that frameworks would still be useful for in a world where web components are king.
There are lots of questions we have to answer on the front end and the consequences of those choices extend into areas we had no idea they could. You could have a negative outlook on the whole thing or you could stand back and marvel at the fact that we've done some impressive as hell work over the years. There's still more work to be done, and we'll get it done.
The point was me to share my thoughts and ideas. That's what blog posts are for.
Fair enough. Apologies if that came off harsh.
That's why I love backend. Tricks from old and obscure PHP blogs/forums can still be valid today.
You really only have to worry about the server your code is running on, instead of any browser+os combination the user can have.
As someone who started writing core javascript 20 years ago, I can say that JS frameworks and libraries have saved me far more time than they've wasted. Yes, there have been headaches along the way (I'm looking at you, AngularJS), but they have unquestionably enabled me and my teams to get to market more quickly than without them.
That said, JS has definitely evolved -- as you mentioned, ES6+ makes life much easier for us, and the language continues to evolve in ways that are helpful. It'd be great to have the language progress to the point where frameworks feel unnecessary, but that's a looooong way off.
You should really look into Aurelia. Unlike most frameworks and libraries, it has a small learning curve and doesn't have a virtual DOM either and can be used without a compiler. It has also regularly beat Angular and React in numerous benchmarks. It has also been around since 2015 with a v2 around the corner.
I have followed the same path as you when i started "re-inventing" myself as a JS engineer. Started on React, ES6, ES7 and a lot of different packages and then slowly started moving on towards back-end, NodeJS, Express, etc.
Noticed same exact issues, backend and way more stable and even fun place to be also IMO even more easier to work with.
On FE simply there is just too much to worry about and too much to learn and FE is less standartized then backend.
Not saying that we shouldnt update our knowledge, we should update our knowledge but its another thing learning new stuff and putting them to practice and another thing being afraid to update a simple dependency because it could break your whole app.
My only question regarding your ideas is what about enterprise grade applications?
I totally agree that with small-medium size applications & businesses, this is totally applicable. But when you have hundreds or possibly thousands, or even more developers all working within the same ecosystem, surely then you'd have to agree that utilising such frameworks makes sense? Not to mention the extensive documentation stating all associated risks around using a stated ecosystem or set of technologies.
Talking about constantly learning, even with the back end we need to think about the browsers that customers are likely using. An example being how in one of the applications my team has been working on, a HTPP only cookie that was being set server side wouldn't persist on the client device when using IE... All because it had the secure flag.
But talking about frameworks & reinventing the wheel, personally I think that the vast variety of technologies to handle application state is getting a little obscene, I've personally been using my own solution for personal projects which is essentially just a wrapper around using custom events. If you're interested at all, by all means take a look at the repo.
Nice, I'll take a look!
Checkout my project.. nimble-ide.com
If you like Svelte, try Riot JS. It's much the same and has been around for years. Currently at v4
Amen to that! Biggest programmer fatigue comes from ever changing front end libraries and frameworks.
And agree on web components, been an advocate since day 1, polymer and lit have so much promise
Solving problems, that's what a Full Stack Dev defined. Nice thoughts by the way. Keep up the great works, Dude.
Polymer is deprecated/replaced in favor of LitElement