To be even more explicit, I can't actually see any benefit of trying to keep the technologies the same on both sides of a TCP/IP border. Use the tool that's best for the job, whatever it is.

I think a lot of the worry comes from developers that are relatively inexperienced. We put "senior" tags on positions filled with people with only a few years of experience. Sometimes I think it's hard for newer developers to imagine what it's going to be like 10 or 20 years down the line. Being good at 2 language (or frameworks or whatever) is almost laughable. If you don't have half a dozen hanging from your belt once you've got a quarter or a third the way through your career, I think it's a big problem that you should aim to fix. Picking up something new and being effective and efficient with it very quickly is an incredibly important skill -- one which no programmer that wants to work in the field long term should avoid.

Now, if you happen to have a very young team that realistically can't handle the challenge, then that's a completely different story. It's also very important to understand what your team is capable of.

I agree with all your posts in this thread so far and thanks for giving me a sanity check. I was starting to question my range of interests versus what others were claiming are standard.

I find knowing both backend and frontend to be hugely important in the design of both systems independently.

I've been involved in tech for 2 decades now. I currently follow frontend / backend JS, Docker/Kubernetes, native mobile as well as RN and Flutter, and general DevOps. In the past I've done Office add-ons in C#, game bots in Java, PHP pre 3.0, Visual Basic GUI wayyy back in the day, done API's in Python/Ruby, and used languages I don't even remember anymore due to preexisting codebases or the team choosing something that fits better.

One scenario that might become more common is a C++ front and backend using web assembly at the frontend.

At the moment I think that's unlikely because as far as I know web assembly can't access the DOM. Once that's fixed, C++ and Rust and a few other platforms will be a lot more viable. I'm not sure how popular it will get, though. For example, GWT gives you a pretty complete Java implementation that compiles to JS (I even use it on a project!). Even as popular as Java is, GWT is not so popular. My experience with GWT has been that it's pretty awkward to use. I can't think of a single thing that's easier to do than in native JS. Personally, I think Typescript is probably a better fit for frontend work for people who want types. Disclaimer: I'm an old school C++ programmer that actually likes writing JS ;-) Where I see web assembly being more compelling is where you want to write native apps and port them to a web or mobile platform. JS applications on the desktop require a pretty massive runtime system and if that's your main goal, JS is not really a great option (IMHO).

I'm right with you in terms of being an old school c++ programmer. I'm really fond of the QT framework and they have been doing a lot of work to port their widgets for WebAsm use. This made taking our existing Desktop GUI application and embedding it straight into a webpage super easy. Our backend servers are C++ based and speak JSON via WebSockets so reusing the same objects on the front and backend was also convenient. Also, I would imaging web assembly could open the doors for much more advanced game engines since a lot of them are written in C++.

It can access it via JavaScript, meaning it’s slower than it could be.

then again it might not.

Both backend and frontend code has an ecosystem that goes with it and the job descriptions are for the entire thing. Some js framework, css. Linux and databases.

Yes but usually you’re not expected to be an expert in all of them. The database and Linux part are expected competencies not expert level.

A decade ago it was possible to be a true full-stack developer that kept up with both ecosystems. Much, much more difficult to do nowadays. Hence the explosion of “frontend engineer” positions.

I've been around a long time. I don't think it's any more difficult than it used to be. On the contrary, I think it's considerably easier -- everything comes with source code and all these new fangled frameworks are practically the same anyway.

Back in the day we had client server architectures and it was exactly the same thing. Even more tiers would sometimes be added and there were frameworks for all of them. We didn't get source code. The frameworks were full of bugs. There was no stack overflow. Documentation usually consisted of a few trivial examples. You just had to hack, hack, hack and figure out how it worked. I remember when Swing came out and being very excited about being able to work on something that wasn't completely insane for client stuff (that's how bad it was ;-) ).

This is just the life of the computer programmer. If you like learning new things, it's never a dull moment!

It's not any more difficult than it once was. You don't need to write a mico-servicized containerated whatever system right out the gate just because that's the way some people like to do it at scale. There are tons of people out there making bank off of sites that are just highly customized wordpress instances, after all. You've got to use the tool appropriate to the job. Certainly today the high end of what's built on a regular basis in terms of web apps is a lot higher than it used to be, but if you have a need to support that level of traffic you either have the ability to hire a team of devs or your business / monetization plan is dysfunctional.