Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

And pulling ~67 dev dependencies just to be able to transpile TS to JS? No thanks.

https://www.npmjs.com/package/typescript

This comment shows perfectly that people has no clue what they're talking about, these dev dependencies will never be pulled into your project, they're just for typescript's own development.

> these dev dependencies will never be pulled into your project,

Please, don't ruin "JS bad" thread with facts. It's rude.

Do these dependencies actually matter when you deploy or are they just used for the actual compiling?

If they are required for the compile and someone manages to get something malicious into them, they can certainly affect the produced/deployed artifact.

See Ken Thompson, Reflections on Trusting Trust, 1984 https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Typescripts has an insanely complicated type system (at least for the low level of type safety you get), is dog slow to compile and has cryptic error messages.

With PHP you can have your cake and eat it too. Have the productivity of a dynamic language, no compile step and a really smooth gradual typing experience with great tooling and linting.

I really can't think of anything other that familiarity why one would prefer JS/TS for server side stuff. Maybe async story but PHP 8 got fibers now so it might be catching up soon as well.

> Typescript ... has cryptic error messages.

This is very strange to hear. Typescript error messages will show you a type mismatch and explain why one type isn't compatible with the other. What's an example of a cryptic typescript error message?

Have you ever used Elm or Rust? Maybe you expectation of how decent error messages should look like is just lower.

The problem is that the type system in TS can get crazy complex and has many uncommon features like structural typing. You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.

> You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.

Won't this sentiment hold true for Rust as well? You need to have a good mental model of how Rust works, with all its borrowings and lifetimes, to understand what its errors are trying to tell you, and especially how to fix the problem?

Actually no. Rust will teach you.

The difference is that errors do a great job and telling you what went wrong and how you can fix it. You just fix one error after another and the borrow checker will guide you to the correct solution.

For example you get an error like:

  error[E0433]: failed to resolve: use of undeclared type `Environment`
   --> src/main.rs:9:19
    |
    |     let mut env = Environment::new();
    |                   ^^^^^^^^^^^ not found in this scope
    |
  help: consider importing this struct
  |
  | use foobar::test::Environment;
  |

You could fix this error without knowing Rust.

You obviously need to know the basics of systems programming to effectively program in Rust and some type errors get tricky, still it is a more interactive experience and you can just jump in while in TS just jumping in does not really work and the level of type safety relies on your skills as a developer.

Hah, let me just chime in with a recent TS error that almost drove me nuts[1]:

  Type 'Record<string, any>' is not assignable to type 'T'.
  'Record<string, any>' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'Record<string, any>'. (2322)

Would you have figured out that the solution to the problem was to omit the - factually correct - return type of the method? Rust is not just better at error messages, it's playing an entirely different game.

[1]: https://stackoverflow.com/q/67397978/2532203

> Would you have figured out that the solution to the problem was to omit the - factually correct - return type of the method?

While I would not be able to figure out the solution to this problem from the error message alone, I would gather from it that typescript is telling me here that it cannot guarantee that it will satisfy the type contract, i.e. that the function will return a thing of the same generic type T as it received. This is useful information in debugging the type declaration of the function.

Use JS + JSDoc comments with types + TypeScript to check types. No compilation step, but code is type safe.

TypeScript is nice, the nodejs community is not. It is a shame that such a nice language as TypeScript is stuck in such horrible community.

Can you give some examples of why the nodejs community is not nice?

Perhaps ecosystem is a better word than community.

How npm works and the policies by company behind it.

PHP composer is much more sane than npm.

And all the different package controversies like leftpad.

Lots of bogus and malware packages.