The worst is, if you don't keep up with this, good luck getting a web job five years from now, you'll be the equivalent of a Cobol programmer. Can't get off the train.
HN (and perhaps SV) might be a bit of an echo chamber that doesn't reflect industry overall.
In most decently sized cities, there seem to be plenty of development jobs available that make heavy use of solid software engineering and architecture using reliable, proven technology.
It's only anecdotal, but I know plenty of developers working for banks, manufacturers, and government who enjoy their jobs and get to solve problems that are interesting and challenging from both business and technical perspectives. They're not using outdated technology, either. The perception here sometimes seems to be that Java and .NET are slow moving dinosaurs, but they're both evolving, and organizations that from the outside seem stuffy and boring actually aren't afraid to keep up with the changes.
Interestingly, the devs I know at these companies also seem to enjoy a much higher status among their non-dev coworkers than devs at many startups and software product companies. I'm not sure why it has worked out this way, but it seems that in businesses where software isn't the end product, it's often easier for developers to be seen as trusted solvers of business problems rather than assembly line workers who are just stitching together raw materials to reify someone else's visions and ideas.
Before I digress too much, I'll circle back around to my point: it's still very possible to ignore the current front end development circus and enjoy a good career as a developer without the risk of turning yourself into an out of date dinosaur.
I'm also not implying that the worldview on HN is wrong, or that startups are bad, or that the current JS ecosystem is the worst thing ever. I'm just trying to remind everyone that there's a pretty big world out there where development skills are in demand, and a huge portion of that work doesn't involve front end work at all! It's even better if you're a developer who understands business (or is willing to learn). If you're a developer at a non-tech company, your ability to quickly create software that solve business problems can make you seem like a magician.
I wouldn't pick on the COBOL programmers too much – they've had a half a century of decent jobs, after all.
The lesson I'd draw from that is that you want to avoid siloing yourself. Most of those COBOL developers worked on the same kind of systems, often in the same place, for long periods of time. That kind of deep specialization is useful but also dangerous to you in direct relation to where that larger field is going.
In the web space, this is complicated by the somewhat unusual browser environment: in 5 years, you will always be glad that you spent time understanding the DOM, ES2016 and later, modern CSS, how to debug in every browser, etc. because ultimately everything is built on top of them.
You may or may not benefit from having spent time learning the framework of the day and that will be in direct relation to how much of that time was spent understanding broader concepts and styles versus dealing with idiosyncrasies and technical debt in the code-base. That's especially true for things like build tools which are easily replaced without visible changes to a project – they're useful and to be appreciated, but they're more overhead than part of your value as a developer.
And the best is, if you have a fundamental understanding of plain, vanilla javascript all these new frameworks are pretty easy to pick up. I went from jQuery -> Angular 1.x -> Ember 1.6 -> Ember 2.0 -> React and Redux in basically no time. It really wasn't that hard.
My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.
I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.
I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.
Hah, I just posted elsewhere this exact sentiment. My first "framework" was Javascript. Every new fancy thing that comes along is just more Javascript to me.
There's still quite a lot of people doing Angular 1.x though, so at least the train isn't that fast.
I sorta agree with you. I personally like JS and really like Node. Node can actually be pretty simple and fun to mess around with and experiment. I know HN likes to hate on it, but I have fun with it.
Frontend apps always end up seeming like a mess to me especially when suing the latest "best practices" for "maintainability" (ironic as most web apps are abandoned after a couple of years). Unfortunately JS being the only language I'm productive in sorta means I'll be doing some sort of frontend for a while.
As goes the software world, the majority of these "applications" won't exist in 5 years.
Conversely, for those that do still exist, the new developers can simply bash the old technology stack and code and demand to rewrite in the new flavor of the week anyway.
In most decently sized cities, there seem to be plenty of development jobs available that make heavy use of solid software engineering and architecture using reliable, proven technology.
It's only anecdotal, but I know plenty of developers working for banks, manufacturers, and government who enjoy their jobs and get to solve problems that are interesting and challenging from both business and technical perspectives. They're not using outdated technology, either. The perception here sometimes seems to be that Java and .NET are slow moving dinosaurs, but they're both evolving, and organizations that from the outside seem stuffy and boring actually aren't afraid to keep up with the changes.
Interestingly, the devs I know at these companies also seem to enjoy a much higher status among their non-dev coworkers than devs at many startups and software product companies. I'm not sure why it has worked out this way, but it seems that in businesses where software isn't the end product, it's often easier for developers to be seen as trusted solvers of business problems rather than assembly line workers who are just stitching together raw materials to reify someone else's visions and ideas.
Before I digress too much, I'll circle back around to my point: it's still very possible to ignore the current front end development circus and enjoy a good career as a developer without the risk of turning yourself into an out of date dinosaur.
I'm also not implying that the worldview on HN is wrong, or that startups are bad, or that the current JS ecosystem is the worst thing ever. I'm just trying to remind everyone that there's a pretty big world out there where development skills are in demand, and a huge portion of that work doesn't involve front end work at all! It's even better if you're a developer who understands business (or is willing to learn). If you're a developer at a non-tech company, your ability to quickly create software that solve business problems can make you seem like a magician.