3 ms·

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 be

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.

pests 8y ago
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.
blackflame7000 8y ago
One scenario that might become more common is a C++ front and backend using web assembly at the frontend.
- corn_dog 8y ago
  then again it might not.
- mikekchar 8y ago
  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).
  - steveklabnik 8y ago
    It can access it via JavaScript, meaning it’s slower than it could be.
  - blackflame7000 8y ago
    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++.

pests 8y ago

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.

blackflame7000 8y ago

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

corn_dog 8y ago
then again it might not.
mikekchar 8y ago
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).
- steveklabnik 8y ago
  It can access it via JavaScript, meaning it’s slower than it could be.
- blackflame7000 8y ago
  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++.