3 ms·

I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You wri

I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The barrier is not cultural fear, it is practical convenience.

ivan_gammel 7mo ago
With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.
winrid 7mo ago
What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.
chii 7mo ago
> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity. I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).
- rossjudson 7mo ago
  GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly". It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT. For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.
  - gf000 7mo ago
    Yeah, I believe some ex-Googlers even claimed that writing Gmail was simply impossible at that time with ordinary JS, and the abstraction behind GWT was an absolute necessity (though maybe the frontend part was not all that important - closure compiler is still alive though)
    - chii 7mo ago
      On the other hand, gwt did not gain much traction, and the majority of frontend developers disliked it (granted, they do prefer javascript+css rather than coding the frontend via gwt widgets).
rossjudson 7mo ago
Different tools for different purposes...which is good/right. TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality). Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.
9rx 7mo ago
The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.
gbear605 7mo ago
My experience has been that developers say that they’ll share types between the frontend and backend, and then in practice they just duplicate it.

ivan_gammel 7mo ago

With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.

winrid 7mo ago

What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.

chii 7mo ago

> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity. I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).

rossjudson 7mo ago
GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly". It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT. For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.
- gf000 7mo ago
  Yeah, I believe some ex-Googlers even claimed that writing Gmail was simply impossible at that time with ordinary JS, and the abstraction behind GWT was an absolute necessity (though maybe the frontend part was not all that important - closure compiler is still alive though)
  - chii 7mo ago
    On the other hand, gwt did not gain much traction, and the majority of frontend developers disliked it (granted, they do prefer javascript+css rather than coding the frontend via gwt widgets).

rossjudson 7mo ago

Different tools for different purposes...which is good/right. TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality). Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.

9rx 7mo ago

The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.

gbear605 7mo ago

My experience has been that developers say that they’ll share types between the frontend and backend, and then in practice they just duplicate it.