Hacker News Reader

Comment by hvidgaard | Hacker News Reader

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.

View on HN

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.

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++.

That is very true. But I still have a hard time to see the justifications of using JS on the server.

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

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.

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.

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.

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 :))

Reply on news.ycombinator.com