Hacker News new | past | comments | ask | show | jobs | submit login

I feel like I am the only one in the world not liking typescript. It is not that I don't like types, it is what those types do to the readability of the codebase in terms of verbosity. My original programming language was Java but I switched to Node.js because I liked the simplicity of the code written in it. Nowadays every Javascript project seems worse than a Java project in terms of verbosity.

My main gripe with projects becoming verbose is that the code becomes hard to understand at a glance. Functions that usually could be 10 lines are now 15 lines becomes of the formatter and each line looks more gibberish because everything has a type. You have to manually filter out that noise. The best way I can describe it is that entropy is increased in order to get type safety.




I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.


I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types).

Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort.

I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing).

To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound.

Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.


You're not alone, and I suspect TS crowd is still a vocal minority.

But TS is very viral by nature. You can only go in one direction (JS -> TS). TS promises "type safety", which is mostly a lie, but sounds really good. It also promises to be purely additive, so choosing it seems like a no-brainer. TS is a next step in a JS-engineer career, once you learn it it's hard to admit that it was a waste of time. Especially when there's nothing but praise around, humans are conformist by nature.

Being viral doesn't make it good. But it means that it will keep spreading, until community gets a TypeScript fatigue.


I tried to find an example to see what you mean, take this file - https://github.com/microsoft/vscode/blob/main/src/vs/editor/...

The typings on the class variables are useful to have. There are also typings on the function signatures, not a huge deal.

In the method bodies there are almost no typings as all of it is already inferred. Seems pretty readable to me.


How about this one: https://github.com/microsoft/vscode/blob/427530e884b33be2451...

  export interface IDomEvent {
   <K extends keyof HTMLElementEventMap>(element: EventHandler, type: K, useCapture?: boolean): BaseEvent<HTMLElementEventMap[K]>;
   (element: EventHandler, type: string, useCapture?: boolean): BaseEvent<unknown>;
  }


I agree that in your example it is not bad. Throughout that codebase it is clear though that they don't have a formatter that enforces a char-limit per line. It is when you combine those things it gets messy. Prettier uses a default of 80.

Looking at the code there is an awful lot of 'null's returned which I find hard to work with but that is a different topic.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: