I often hear this sentiment that new languages and frameworks du jour pop up every week, and that past an age a fellow just wants to learn a single reliable stack and collect a weekly paycheck.
Am I the only one who just hasn't experienced this feeling? There used to be Rails/Django and jQuery. Now there's Node and React. Both revolve around extremely simple ideas. Spend an afternoon reading the React docs, and you'll know everything you need. Take another afternoon after that and learn Redux. If you have another few afternoons, learn Clojure, and see what the Lisp folks have gotten going with reagent/re-frame. There isn't that much to keep up with.
It's the same with complaints about JS having too many transpiled dialects. These dialects make life easier. There are good ideas in them. For example, Livescript is wonderfully concise and elegant, at no cost of readability once you grok Livescript. It makes your code more readable and faster to write. How is this a bad deal?
I sometimes wonder if people are just annoyed that they need to learn new paradigms at all. It's not like ours shift at an especially fast rate.
I follow your reasoning for the most part, but there's one core problem that inevitably comes up: everything has quirks, and the quirks add up over time. Boring stacks are partly boring because they've been around for a long time, but they are also boring in the sense that they are predictable.
The problem is that in any suitably large project, you will inevitably cover enough use cases to run into a library or language's quirks. Browser support issue in this one corner, language ambiguity in this other corner, unsupported arcane combination of theoretically orthogonal functions in yet another corner, and then a slow inner loop in some other corner. Once you've added everything together, you get a big headache.
With more mature stacks, it's easier to anticipate these issues because they are well documented all over tutorial materials, knowledge bases, and just professional experience. They've also had time to iterate and address many of the design and polish issues that would slow developers down.
Yep. Most of my experience with these kind of issues recently has been on the client side: stuff works in one browser or, worse, one version of a browser, and not in another, or it works well in the desktop browser, but not the mobile version of the same browser.
These issues tend to be huge timesinks - I literally lose count of the number of times I've lost a couple of hours or more due to some weird quirk that would never have come up as an issue in plain old .NET.
That being said, in any suitably large project, the quirks in your own codebase will inevitably start to drain resources in the same way whether your stack is boring or otherwise. The advantage with boring is that, 99% of the time, if there is a quirk you know it's probably your quirk and something that's under your control to fix.
I don't know what age we're talking about, but I'm not as young as I once was, and I still love learning new stuff.
BUT
If I'm going to invest time in something, it's going to have to pay rent. It's got to serve some real purpose, to give me something I didn't have before I learned it. And that rent is going to have to cover the initial investment, and then some.
Most new web frameworks don't pay rent.
When I was younger I always wanted to make games. I'd spend weeks building a fancy game engine that would let me make the game... and then I'd burn out, before ever actually building the game itself. Those game engines never paid rent, other than what I learned from implementing them. If you're just learning someone else's API which then becomes irrelevant a few months later, then you don't even get that payback. You just waste your time.
Sure, you can read React docs for an afternoon and get a basic feeling for it.
Then there's the million fine points to master. Like the minutiae of React.propTypes. Or how to use {' '} to avoid having spaces rudely removed. The fine details of react component lifecycle, or how you have to set "className" instead of "class", or ... ...
The rough high-level idea is ALWAYS easy. The devil is ALWAYS in the details.
It is not exactly the same though. is a non-breaking space, which means the browser will keep the elements together on the same line. With a normal space the elements could be rendered on seperate lines.
> past an age a fellow just wants to learn a single reliable stack and collect a weekly paycheck
That's a bit too strong. Surely there are people like that. But I'm "past an age" and there's always some newish thing I'm learning. However, I'm in no rush to start adopting them for real projects. I want to know the payback from switching, and neither hype nor the word "modern" cut it. I want to know what this language is good for and what it's not so good for. So I learn things and evaluate them, and over time I add things to my working set of languages and tools.
It is easy to learn new languages but as the previous commenter mentioned it has it's quirks and when you add in the complexity of working with a group of developers with different beliefs and experience levels it adds up. After a point, you are just dealing with the quirks of the framework/language than the business problem.
I think the improvement new stacks are bringing are getting more and more marginal, compared to the effort required to learn them, and instead of learning those new framework, I would rather spend time learning about new fields in programming; for example the things I am interested are, in no particular order: neural networks, compilers, 3D graphics, high performance computing, and maybe crypto and OS development.
>I often hear this sentiment that new languages and frameworks du jour pop up every week, and that past an age a fellow just wants to learn a single reliable stack and collect a weekly paycheck.
TFA clearly and repeatedly states the author learns new tools and frequently employs them for client work. The point of the article is that boring/mature stacks can offer a better ROI for in-house products.
Switching frameworks for any large system is non-trivial not so much for the technical effort necessary but for the political effort.
For any large enough system (if it were small, you could make changes and nobody would care), you're going to have to persuade the stakeholders why they need to switch. That's not something you can do with a low-touch message to everyone in the project. That's a "let's sit down with people, listen to them, figure out how we can find common ground" high-touch strategy.
Even if you get everyone on board, it still took a long time.
Am I the only one who just hasn't experienced this feeling? There used to be Rails/Django and jQuery. Now there's Node and React. Both revolve around extremely simple ideas. Spend an afternoon reading the React docs, and you'll know everything you need. Take another afternoon after that and learn Redux. If you have another few afternoons, learn Clojure, and see what the Lisp folks have gotten going with reagent/re-frame. There isn't that much to keep up with.
It's the same with complaints about JS having too many transpiled dialects. These dialects make life easier. There are good ideas in them. For example, Livescript is wonderfully concise and elegant, at no cost of readability once you grok Livescript. It makes your code more readable and faster to write. How is this a bad deal?
I sometimes wonder if people are just annoyed that they need to learn new paradigms at all. It's not like ours shift at an especially fast rate.