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.
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++.
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.
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.
If you really believe that I think my story will blow your mind.
I've been a full stack developer since my very first job creating a Java based web app for a startup where the only other coder was the CIO. The CIO didn't know Java and primarily worked on C/C++ embedded code for unrelated projects. Back at this time raw Java servlets were still "the thing" and javascript with jQuery was state of the art on the front end. With just these primitive tools I built a fairly modern even by today's standards reactive web app. Lots of stuff loaded dynamically based on user interaction without switching pages. It was a legit web app, not just a web page. Actually, I was more than a full stack developer. I was also the sysadmin, dba, and network engineer. I physically installed the hardware at the AT&T data center, created a DMZ with the firewalls, configured load balancers, installed the DB and set up a hot backup, literally everything that needs to get done to make a working web application. There was no one around to learn from, it was all web searches: how to secure Apache, how to set up certificates, how to create indexes on the database... everything.
I ultimately decided I prefer back-end development so that's where I spend most of my time these days. However, in recent years I've picked up Angular and Backbone because sometimes the front end team needs some extra bandwidth and being able to help out is really valuable. I'm not as good at that stuff as the dedicated front end guys. I certainly didn't do as good of a job setting up the network or eeking out max performance on the database at my first job as dedicated professionals would have. But I got the job done at a professional quality level. My first job was surely a rather unique experience, but everywhere I've worked multiple people on the team have been comfortable all the way up and down the coding stack, even if they might have specialized in just one area.
This actually sounds pretty ideal for someone early in their career. Having to do that much must have been a great learning experience -- one of the perks at working at a startup.
Definitely. In spite of the insane hours I worked sometimes to keep that ship a float, it was a really amazing and unique experience. I feel really lucky to have started out there. I left the company about 13 years ago and the product is still running and profitable. I did one rewrite from raw servlets to Struts while I was there. They've tried two rewrites since I left to get it into more modern tech, but both rewrites failed, so a LOT of my code lives on. That's a really great feeling knowing that something I created is still valuable and useful over a decade later.
That depends on a lot of factors. "Fullstack developer" can often mean "we just want a donkey to ride for whatever purposes we need", often overworked and underpaid. But not always. Plenty of people have very broad skillsets and can work on projects that go from systems software dev. to front end web design to sysadmin duties to customer service. In really small companies often there just isn't a possibility to hire people to fill out all the jobs that need to be done as different roles. What one should evaluate is what the tradeoffs are. Do you have a lot of autonomy and authority married to all of that responsibility? Is there some acknowledgement that you'll need downtime (e.g. vacations)? Are there non-monetary compensations built-in like flexible work hours, ability to work remotely a lot, ability to prioritize one's own work and make decisions on scheduling? And, of course, equity. In other words: are you treated as a peer, a co-founder, or an underling?
I think it's 'fine' for there to be different technologies/language on different sides.
Typescript/JavaScript front end.
Python, Java, .net on the back end.
Database written in C++
OS written in C.
There are certainly jack of all trades developers that can do that for you. You will get a jack of all trades solutions that may have oddities here and there. Which could be okay depending.
I mean, there are a lot of languages that can be used both on the server and in a browser. JavaScript is the obvious one, but anything that compiles to js works, too.
Until probably the last 5 or so years this was the norm. Until Node.js became widely used as a web developer you were essentially required to know JavaScript and at least one of Python, Ruby or PHP. For companies trying to shift away from these legacy environments or those who haven't started yet it's pretty reasonable for them to try and hire those kinds of devs still
Since people realised writing the same code in two different languages is a waste of time and the async-first nature of NodeJS/libuv is ideal for use in microservices.
Compare implementing back-end form validation in PHP and a completely different implementation front-end validation in JS vs using the exact same implementation on both sides. The former approach requires more work, creates a larger maintenance burden and a greater area for inconsistency and error because you need to maintain functional consistency between the two different implementations in the two different languages
