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.
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 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.
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.
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.
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.
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
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
If you like Svelte, try Riot JS. It's much the same and has been around for years. Currently at v4
Polymer is deprecated/replaced in favor of LitElement
There are so many issues with Web Components as they stand. The tech will have to improve a great deal before it's worth building a framework on top of them.
Solving problems, that's what a Full Stack Dev defined. Nice thoughts by the way. Keep up the great works, Dude.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.