XML is the future

Because they don't see technical debt as a bad thing. Go back to the original pitch for technical debt by Ward Cunningham. He was working for a finance company and used the debt metaphor to advocate in favor of "borrowing against the future" when implementing new code. The idea was that you could use the latest stuff without reinventing everything. Like mortgage payments, the reinvention could happen over time, in increments, until it's "paid off". The problem is that nowadays, especially in finance, you're dealing with people who are used to over leveraging everything. To them, the idea is to pile on debt until it becomes unmanageable: and then sell. Or go into Chapter 11.

So.. there's a lot to unpack here.

There's a few ways to interpret the "hype-train" of mainstream development

1 - it's gonna solve all my problems

2 - everyone else is talking about it so I should learn it

3 - incremental ad-hoc solution to a real problem someone encountered, may or may not apply to me

Many juniors are guilty of 1 & 2, few make it to realize that most of the time these lie in camp 3. There's a real use case for this, but you have to train your mind to not see it as a silver-bullet or worry about hype train.

The difference between academia & industry is that academia tends to develop general solutions to problems few if any people encounter. The best of the industrial programmer will take the bits of academia & try to make our ad-hoc solutions slightly more general while staying practical.

This is endless, and depending on your perspective its fascinating OR exhausting.

To me its a bit of both, but with distance & the realization that I do not need to care about virtually any new tech, I usually lean to the fascinating side.

As a language designer its humbling to see the milage people get out of many half-baked solutions in the JS ecosystem, and a sign that generality isn't the whole picture.

Wondering why web apps that do genuinely need to be react based or similar because of complex interactivity aren't being built as cross platform desktop apps using something like GTK. Performance would be much better, there would be a rich set of ready to use GUI components to use etc

All development frameworks and new tech are about reducing the amount of labor required to produce outcomes. This can mean reducing the amount of up-front labor required (running JS on the frontend and backend means that junior devs only need to know one language), or reducing the amount of refactoring required later on (more structured SPA frameworks like angular turn everything you want to do into a matter of boilerplate CRUD). In both cases, it's about having a uniform pattern for anything you want to do so that onboarding new people to the project is easier. Want to get some blog posts for this view? Inject the IBlogService. Want to get a list of all authors? Inject the IAuthorService. Without having read the docs, you can starting typing "I{ThingIWant}Service" and your IDE will pop up whatever services are available.

I see a lot of old school developers complaining about the abstraction of frameworks and how it was simpler to code things in CGI, PHP, C, etc. when you were closer to the machine, or at least were managing the state of the program manually and not through some framework which uses reflection and @Decorators/Annotations everywhere to declare things. But such systems mean that whenever you bring some new junior dev on, they have to spend 6 months learning how your system works, being totally useless to the company in the meantime (especially since college doesn't seem to teach useful job skills anymore).

As it is now, even though there's a million different fad frameworks out there, they're mostly all about the same. I can easily transition between nestjs, .net mvc, or spring boot because they all imitate spring. Frontend frameworks are usually about the same too, and sometimes the frontend is shockingly similar to the backend (like Angular).

I'd much rather work with the banality of angular/react CRUD/boilerplate than have to write another line of unframeworked PHP, or manually write another Apache2 routing config file ever again. That's not to mention operations stuff: CI/CD, despite all of its attempts to boil all possible program states and logic down into infinitely complex declarative yaml files and containerizing everything, is better than the alternative: SSH'ing into a server, manually dealing with system library dependencies, and copying files into /var/www

I've been in the industry for over 30 years and I absolutely get where you're coming from. It is an ever changing field and it can be exhausting. I hear this repeatedly from many coworkers (and workers from the same field).

All I can give is some advice from my lengthy experience.

Most of the changes happen on the "edges". Those edges are primarily three fold:

First, the user interface: everything that deals with input parsing and formatting. This also includes protocol marshalling (Http, JSON, XML, ...)

Second the data persistence. This involves choice of database or any other persistence. Including serialisation of your data. Any I/O really.

Third, anything to do with deployment. This includes environment isolation, configuration management, process automation and so on.

These the edges have nothing to do with your core application logic.

You can reduce the impact of a switch to a new stack by inflating your core logic and shielding it from the rest of your stack.

This is tricky and I still catch myself all the time doing it wrong. Because doing it wrong is tempting and easy.

For example, consider a connection to the db: you will need a connection string. You can fetch that from an environment variable somewhere deep in your core code. But by reaching out to the system like that, you make that core piece of code dependent on the deployment strategy. Instead, you can move that part as close as possible to the entry point and then pass it down as function/class arguments. You can group similar operations together, close to the entry point. That way, if the dependent e strategy or the stack changes, your core code does not need to change.

Another example is the case where your core code is dependent on a library from your stack. For example, when working with python and flask, it's easy to import "request" or "g" from the framework. But every piece of code relying on that will be tightly coupled to the framework and subject to change whenever the framework changes (either same framework with breaking changes, or framework switch). The solution is the same. Move those elements as close as possible to the entry points. In this example of flask, keep this as close as possible to your routes. But also keep your routes clean of core logic. Interact with the HTTP layer only and pass the values as arguments to your core.

Finally, a similar situation, but much more sneaky and hard to spot is reliance on data types from your stack. Spotting cases where you rely too much on library modules can be done by investigating imports. But reliance on data types is harder to spot. Sticking with the flask example: the http headers are encapsulated by an object of the flask stack (werkzeug in this case). You may be careful and extract the headers in the route to follow my earlier example. But if you then pass the headers unmodified down into your core logic you will again be coupled to the stack. Instead you should extract only the values you care about and hand only those down to break the coupling.

Finding the right balance where to cut the coupling is challenging. The more you cut, the better you will be shielded from changes. But the less you can benefit from pre existing implementations from the stack. Where to cut is ultimately a design decision.

When done well, it will be far less frustrating to jump on the bandwagon of the latest tech. Not completely painless but far less stressful. Not least because you will have confidence that you didn't accidentally break core logic.