5 ms·

Single language is an advantage if you're trying to save money on hiring people that know both. We don't really share any code between our JS frontends and node

Single language is an advantage if you're trying to save money on hiring people that know both. We don't really share any code between our JS frontends and node backends, and I've never worked at a place that did. As far as I can tell that's a hopeful myth. Working between languages is easy as long as you use a cross-language object format like gRPC.IMO single language is overrated and context switching cost is basically zero. Is it hard to switch between two verbal or written languages you know? People do it mid sentence, I don't see how it's any different with programming languages. Node packages tend to be smaller but there's far, far more of them in an average project. And unlike Java they're not stored as zip on disk and class files when built, so in both cases they're using a lot more space. Java bytecode was designed to be compact like WASM, it takes way less space than even minified source and it's zip compressed for deployment into a jar on top of that. Node dependancies being more fragmented is generally a bad thing. I constantly have to replace libraries when our code scanners find vulnerable npm packages that are no longer maintained. Since Java is far less fragmented I hardly ever have to do this with our Java codebases. Node's standard libraries are terrible compared to Java and Python but I can't make a case for that besides saying they clearly are. I agree with you on front vs backend being a bad comparison, but even our regular express apps take up more space and memory. Java using lots of ram is also a myth. It might have been true many years ago, but Java generally uses about 1/3 the memory storing the same structures because there's a lot less overhead per object and field. The only reason most Java apps use lots of ram is because people configure the garbage collector to use as much RAM as possible so it collects less often. Node doesn't use as much ram because nobody really changes the GC defaults.

chrisco255 7y ago
Humans have a huge context switching penalty when switching between operating systems, written languages, and of course programming languages. Hell even switching browser tabs incurs a context switching cost. The more complex the interface the more the difficult the context switch is. The process and mindset for debugging Java and JavaScript are totally different. The tools used for each are different. Thinking about the data structures of Java vs. JavaScript alone, is a context switch. Onboarding new devs requires them to learn architectural patterns (as well as master two languages) that are totally different in most cases because JS code tends to be written much differently than Java as a result of Java's heavy focus on OOP. Nothing wrong with any of this and I'm not attacking Java by any means, we could easily have the same convo about C++ vs. Go or Python vs. Rust. It's not about "sharing code" between front end and back end. Although you can share code and I have in several projects, what I mentioned above was sharing libraries. That's very common, for example, Moment.js, Lodash, and i18n utils. I also use Chrome debugger tools on both front end and back end. I have even shared architectural patterns for state management. I agree Java dependencies are less error prone because they're bundled up as Java byte code and I get the appeal there. I agree Python has a fantastic standard library and Node is spartan by comparison. That was always a trade-off that Node consciously made from the beginning though. Didn't know that about the GC defaults.
- freeopinion 7y ago
  I don't see much trouble context switching between HTML, CSS, and JS on the frontend. I don't see much trouble switching between some other language on the backend and SQL, JSON, macro, etc. Context switching is a real thing, and sometimes creates penalties. But sometimes it increases productivity. For me it is very helpful to switch into SQL mode when grabbing data from a store, then switching to Go/Python/JS/Rust/C++/Ruby/etc thinking for the business rules around that data. Frontend JS and backend JS are not really the same language or environment. They are different in important ways. But they are so very similar that it can be easy to be in "frontend" thinking mode when working on the backend, or vice versa. And I have many many times seen that cause problems. That's not to say that it is bad to use the same language in both places. I'm just pointing out that there are pluses to context switching as well as negatives.
acephal 7y ago
> Is it hard to switch between two verbal or written languages you know? People do it mid sentence, I don't see how it's any different with programming languages. Well, to be fair, humans have dedicated hardware for natural language encoding/decoding ;)

chrisco255 7y ago

Humans have a huge context switching penalty when switching between operating systems, written languages, and of course programming languages. Hell even switching browser tabs incurs a context switching cost. The more complex the interface the more the difficult the context switch is. The process and mindset for debugging Java and JavaScript are totally different. The tools used for each are different. Thinking about the data structures of Java vs. JavaScript alone, is a context switch. Onboarding new devs requires them to learn architectural patterns (as well as master two languages) that are totally different in most cases because JS code tends to be written much differently than Java as a result of Java's heavy focus on OOP. Nothing wrong with any of this and I'm not attacking Java by any means, we could easily have the same convo about C++ vs. Go or Python vs. Rust. It's not about "sharing code" between front end and back end. Although you can share code and I have in several projects, what I mentioned above was sharing libraries. That's very common, for example, Moment.js, Lodash, and i18n utils. I also use Chrome debugger tools on both front end and back end. I have even shared architectural patterns for state management. I agree Java dependencies are less error prone because they're bundled up as Java byte code and I get the appeal there. I agree Python has a fantastic standard library and Node is spartan by comparison. That was always a trade-off that Node consciously made from the beginning though. Didn't know that about the GC defaults.

freeopinion 7y ago
I don't see much trouble context switching between HTML, CSS, and JS on the frontend. I don't see much trouble switching between some other language on the backend and SQL, JSON, macro, etc. Context switching is a real thing, and sometimes creates penalties. But sometimes it increases productivity. For me it is very helpful to switch into SQL mode when grabbing data from a store, then switching to Go/Python/JS/Rust/C++/Ruby/etc thinking for the business rules around that data. Frontend JS and backend JS are not really the same language or environment. They are different in important ways. But they are so very similar that it can be easy to be in "frontend" thinking mode when working on the backend, or vice versa. And I have many many times seen that cause problems. That's not to say that it is bad to use the same language in both places. I'm just pointing out that there are pluses to context switching as well as negatives.

acephal 7y ago

> Is it hard to switch between two verbal or written languages you know? People do it mid sentence, I don't see how it's any different with programming languages. Well, to be fair, humans have dedicated hardware for natural language encoding/decoding ;)