6 ms·

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

robpalmer 6y ago
No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.
- hvidgaard 6y ago
  That is very true. But I still have a hard time to see the justifications of using JS on the server.
  - robpalmer 6y ago
    I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions. Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary. Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng https://www.youtube.com/watch?v=GrnBXhsr0ng
    - hvidgaard 6y ago
      I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.
  - thelazydogsback 6y ago
    I think TS on the server is a great choice for all the reasons that make TS interesting -- esp. the expressive structural typing system which is not found in the other languages. What is missing is a better runtime that supports true shared-memory (w/o serialization overhead between workers) multi-threading (for async thread pools or true parallel workloads) like other modern servers. This would be ideal for me at the moment.
    - hvidgaard 6y ago
      I like the structural type system, but it's not my experience that the power of it is unquestionably a good idea to use for long lived projects. The simpler something is, the easier it is to maintain.
      - thelazydogsback 6y ago
        Agree, but I think it excels at it's intended purpose, as a "gradually typed" system where types can be added at the various places, and inferred types that "meet in the middle" will structurally type as intended. If you want to simulate nominal typing in places, you can always use tagged unions, as TS now offers several different ways to do this. (However, this info will typically not get erased at run-time, so you get reflection whether you like it or not :))
addicted 6y ago
They adopted in 2005. It was almost certainly the opposite then. This predated node, and was just about the time GMail came into the picture. It’s almost certain finding actual developers (As opposed to web designers with a sprinkling of JS knowledge) with JS experience was extremely difficult then, so it’s not likely to be a reason at all.

robpalmer 6y ago

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

hvidgaard 6y ago
That is very true. But I still have a hard time to see the justifications of using JS on the server.
- robpalmer 6y ago
  I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions. Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary. Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng https://www.youtube.com/watch?v=GrnBXhsr0ng
  - hvidgaard 6y ago
    I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.
- thelazydogsback 6y ago
  I think TS on the server is a great choice for all the reasons that make TS interesting -- esp. the expressive structural typing system which is not found in the other languages. What is missing is a better runtime that supports true shared-memory (w/o serialization overhead between workers) multi-threading (for async thread pools or true parallel workloads) like other modern servers. This would be ideal for me at the moment.
  - hvidgaard 6y ago
    I like the structural type system, but it's not my experience that the power of it is unquestionably a good idea to use for long lived projects. The simpler something is, the easier it is to maintain.
    - thelazydogsback 6y ago
      Agree, but I think it excels at it's intended purpose, as a "gradually typed" system where types can be added at the various places, and inferred types that "meet in the middle" will structurally type as intended. If you want to simulate nominal typing in places, you can always use tagged unions, as TS now offers several different ways to do this. (However, this info will typically not get erased at run-time, so you get reflection whether you like it or not :))

addicted 6y ago

They adopted in 2005. It was almost certainly the opposite then. This predated node, and was just about the time GMail came into the picture. It’s almost certain finding actual developers (As opposed to web designers with a sprinkling of JS knowledge) with JS experience was extremely difficult then, so it’s not likely to be a reason at all.