10 ms·

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many language

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of the cruft and process that makes Java and C# especially so "uninteresting". Java especially is kind of a joy to work in if you ignore the cruft. Everything is generally well documented, the libraries are mostly very solid, code is almost always backwards compatible, there isn't a zillion ways to do everything, frameworks tend to live for a decade or so. And it's faster than JS, and uses way less memory, and mostly solved dependency hell and bloat over a decade ago. Java feels like it was designed, not grown. Everything follows similar convention so it's easy to pick up new libraries. The advantages are many. The drawbacks are few as long as you use things like Lombok and code generation liberally. By the way; code generation using agents, annotation processors, and bytecode manipulation is pretty much standard and a godsend for doing interesting things (and getting around the cruft) . In java, I can write code on the fly at runtime, or even during compile time using standard tools. Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated

pwaivers 8y ago
Since JavaScript is a prototype language, doesn't reflection come in automatically?
- MarsAscendant 8y ago
  Not for most coders, unfortunately.
- spricket 8y ago
  Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful
undersheet 8y ago
> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries
- spricket 8y ago
  I agree about critiques for most of those languages but not java. If you reach out to the Java ecosystem you can find libraries, frameworks, and language extensions that make it relatively easy to code in. For example, with Lombok you don't have to write any getters and setters, or catch checked exceptions. Java 11 also makes good improvements to lamdas making method chaining a lot nicer. The Java I write at work is barely more verbose than the TypeScript, maybe 15% more code to do the same thing. Java devs also get paid really well honestly, pretty sure it's better than the pay for JS and Python actually.
  - undersheet 8y ago
    Python maybe but JS not. React devs are paud higher than any Java coder.
- optimuspaul 8y ago
  > Python not as scalable Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.
  - undersheet 8y ago
    > I can think of Mayne that is your problem. Try new stuff. V8 is still one of the fastest and most optimized VMs.
    - Daishiman 8y ago
      That has absolutely no relationship to backend scalability whatsoever.
orangeeater 8y ago
> Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated Can you explain what Java offers with regard to reflection that JS doesn't? My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection. There is a Reflect object with a bunch of static methods on it in ES6. It mostly just replicates functonality that already exists in the language, and my suspicion is that it's mainly there so it can be extended at a later date without breaking backwards compatiblity.
- spricket 8y ago
  Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time with reflection and know it will generally work (type checked) is nice.
  - kangoo1707 8y ago
    Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?
    - buerkle 8y ago
      http://immutables.github.io/ http://immutables.github.io/ makes great use of this feature in Java
    - gwright 8y ago
      In general this what java annotation processors are all about. As a specific example, Dagger, a compile time, type safe dependency injection framework. https://google.github.io/dagger/ https://google.github.io/dagger/
bryanrasmussen 8y ago
JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their syntactical DNA with C but each have their own fun little differences.
- danenania 8y ago
  This advantage is further multiplied with TypeScript, since you can easily share types between backend and frontend. Working with a single set of types that enforce contracts (and supply IDE autocompletion) across the entire stack is amazing. It provides a huge productivity boost and eliminates a whole class of extremely common bugs.
- spricket 8y ago
  I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem
  - TeMPOraL 8y ago
    It's not about RPC, it's about a way of DRYing code between the backend and frontend, using libraries as your copy-paste engine. You pull in the same library (or extract common code to a library) both on the page and on the server, and assume they're both identical. I have mixed feelings about this. I don't feel comfortable with assuming that just because I use the same library in backend and frontend, I don't have to ensure consistency and behaviour. But then again, I've used this approach in one ClojureScript project (ClojureScript can transpile a lot of Clojure libraries to JS), and it is convenient.
    - spricket 8y ago
me551ah 8y ago
You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.
- spricket 8y ago
  Highly recommend TypeScript. It brings so much method to the madness. Build tools are another clusterfuck but at least with TS you have a decently structured language with "standard" ways of doing things
- z3t4 8y ago
  Highly recommend vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.
  - me551ah 8y ago
    I am quite decent at vanilla javascript, but building a website in vanilla javascript is like building a REST API in vanilla C. It's possible but will take a long time.
- tracker1 8y ago
  I can't speak for anyone else... but I learned javascript and even liked it for most of the reasons outlined before the Good Parts book came out. Since ES6 it's even better.
2trill2spill 8y ago
While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give me much better code reviews because they all know the language. But we will see going forward, still very much a green field project.
- johnwyles 8y ago
  My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.
  - 2trill2spill 8y ago
    Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
    - BigJono 8y ago
      > Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
      - 8y ago
_hardwaregeek 8y ago
I will say that isomorphic [1] JS apps are really fun to write because with well abstracted APIs, the back end and front end don't feel like a discrete API and a discrete front end, but one entity that communicates via asynchronous function calls. For instance, working with firebase functions just feels like working with a local async function. But that's really a minor benefit to the fair criticisms you give. [1] Whoever came up with isomorphic really liked their fancy math terms. Personally I'd have chosen automorphic, as it's all contained inside JS.
austincheney 8y ago
The problem I have with Java is that its a tremendous amount of code to do tiny things. There is a cognitive load that comes from reading. The more code you have to read to perform the equivalent action the more tired you get and the more opportunity you have for errors. There is something precious to being able to do more with substantially less code, which is why I avoid OOP all together. You can't do that in Java.
sonnyblarney 8y ago
Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a different comparison. I quite like using Typescript on Node.js over Java - development speed is faster, and this is a really important thing.
- adrianN 8y ago
  JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.
  - gwillz 8y ago
    I was reading something on HN recently and I ended up on this wiki article. https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack It got me thinking about it. JSON is annoyingly simple at times, yes. But that also protects it from some pretty gnarly stuff seen in XML and YAML. I suspect it's a considerable contributor as to why it's the choice transport format. I wouldn't toss it in with XML just yet.
  - pjmlp 8y ago
    It is already on its way out, thanks to gRPC and need for performance instead of parsing text all the time. It is only a matter of browsers getting native support for gRPC.
    - sonnyblarney 8y ago
      It's available now! Yay! [1] With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh. [1] https://github.com/grpc/grpc-web https://github.com/grpc/grpc-web

pwaivers 8y ago

Since JavaScript is a prototype language, doesn't reflection come in automatically?

MarsAscendant 8y ago
Not for most coders, unfortunately.
spricket 8y ago
Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful

undersheet 8y ago

> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

spricket 8y ago
I agree about critiques for most of those languages but not java. If you reach out to the Java ecosystem you can find libraries, frameworks, and language extensions that make it relatively easy to code in. For example, with Lombok you don't have to write any getters and setters, or catch checked exceptions. Java 11 also makes good improvements to lamdas making method chaining a lot nicer. The Java I write at work is barely more verbose than the TypeScript, maybe 15% more code to do the same thing. Java devs also get paid really well honestly, pretty sure it's better than the pay for JS and Python actually.
- undersheet 8y ago
  Python maybe but JS not. React devs are paud higher than any Java coder.
optimuspaul 8y ago
> Python not as scalable Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.
- undersheet 8y ago
  > I can think of Mayne that is your problem. Try new stuff. V8 is still one of the fastest and most optimized VMs.
  - Daishiman 8y ago
    That has absolutely no relationship to backend scalability whatsoever.

orangeeater 8y ago

> Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated Can you explain what Java offers with regard to reflection that JS doesn't? My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection. There is a Reflect object with a bunch of static methods on it in ES6. It mostly just replicates functonality that already exists in the language, and my suspicion is that it's mainly there so it can be extended at a later date without breaking backwards compatiblity.

spricket 8y ago
Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time with reflection and know it will generally work (type checked) is nice.
- kangoo1707 8y ago
  Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?
  - buerkle 8y ago
    http://immutables.github.io/ http://immutables.github.io/ makes great use of this feature in Java
  - gwright 8y ago
    In general this what java annotation processors are all about. As a specific example, Dagger, a compile time, type safe dependency injection framework. https://google.github.io/dagger/ https://google.github.io/dagger/

bryanrasmussen 8y ago

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their syntactical DNA with C but each have their own fun little differences.

danenania 8y ago
This advantage is further multiplied with TypeScript, since you can easily share types between backend and frontend. Working with a single set of types that enforce contracts (and supply IDE autocompletion) across the entire stack is amazing. It provides a huge productivity boost and eliminates a whole class of extremely common bugs.
spricket 8y ago
I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem
- TeMPOraL 8y ago
  It's not about RPC, it's about a way of DRYing code between the backend and frontend, using libraries as your copy-paste engine. You pull in the same library (or extract common code to a library) both on the page and on the server, and assume they're both identical. I have mixed feelings about this. I don't feel comfortable with assuming that just because I use the same library in backend and frontend, I don't have to ensure consistency and behaviour. But then again, I've used this approach in one ClojureScript project (ClojureScript can transpile a lot of Clojure libraries to JS), and it is convenient.
  - spricket 8y ago

me551ah 8y ago

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.

spricket 8y ago
Highly recommend TypeScript. It brings so much method to the madness. Build tools are another clusterfuck but at least with TS you have a decently structured language with "standard" ways of doing things
z3t4 8y ago
Highly recommend vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.
- me551ah 8y ago
  I am quite decent at vanilla javascript, but building a website in vanilla javascript is like building a REST API in vanilla C. It's possible but will take a long time.
tracker1 8y ago
I can't speak for anyone else... but I learned javascript and even liked it for most of the reasons outlined before the Good Parts book came out. Since ES6 it's even better.

2trill2spill 8y ago

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give me much better code reviews because they all know the language. But we will see going forward, still very much a green field project.

johnwyles 8y ago
My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.
- 2trill2spill 8y ago
  Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
  - BigJono 8y ago
    > Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
    - 8y ago

_hardwaregeek 8y ago

I will say that isomorphic [1] JS apps are really fun to write because with well abstracted APIs, the back end and front end don't feel like a discrete API and a discrete front end, but one entity that communicates via asynchronous function calls. For instance, working with firebase functions just feels like working with a local async function. But that's really a minor benefit to the fair criticisms you give. [1] Whoever came up with isomorphic really liked their fancy math terms. Personally I'd have chosen automorphic, as it's all contained inside JS.

austincheney 8y ago

The problem I have with Java is that its a tremendous amount of code to do tiny things. There is a cognitive load that comes from reading. The more code you have to read to perform the equivalent action the more tired you get and the more opportunity you have for errors. There is something precious to being able to do more with substantially less code, which is why I avoid OOP all together. You can't do that in Java.

sonnyblarney 8y ago

Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a different comparison. I quite like using Typescript on Node.js over Java - development speed is faster, and this is a really important thing.

adrianN 8y ago
JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.
- gwillz 8y ago
  I was reading something on HN recently and I ended up on this wiki article. https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack It got me thinking about it. JSON is annoyingly simple at times, yes. But that also protects it from some pretty gnarly stuff seen in XML and YAML. I suspect it's a considerable contributor as to why it's the choice transport format. I wouldn't toss it in with XML just yet.
- pjmlp 8y ago
  It is already on its way out, thanks to gRPC and need for performance instead of parsing text all the time. It is only a matter of browsers getting native support for gRPC.
  - sonnyblarney 8y ago
    It's available now! Yay! [1] With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh. [1] https://github.com/grpc/grpc-web https://github.com/grpc/grpc-web