I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.
That's such a weird requirement, maybe because I'm used to writing Go code in my day job. I work on some React webapps on the side and there's no way I would miss on TS, typing is just the only way to write code that you can actually refactor. Granted you get some of TypeScript safety for free thanks to `// @ts-check` and friends, but it's the bare minimum.
I do agree with you on the compilation, and this is the reason I'm still writing the occasional .js or .mjs file. However, the js I write starts with enabling ts-check and has all of its type information encoded as comment. This way, I'm getting the benefits of typescript while writing the code without needing the whole compilation step.
Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type.
It's probably not listed in the article because it's a nonsensical argument.
Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix.
What I need is a StupidScript to save me from the stupidity of my logic errors…
Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards unlock at the end of the match. The code is “correct” the right types go to the right place but there is a logic error somewhere that prevents certain rewards from unlocking.
Uh, yeah, that's a runtime error. Type safety tells you the error before you even hit save, let alone run and test. It's a wildly faster loop.
Yes. The point is that without type-safety and a compile-time type check, you have absolutely no way of knowing if you have an error like this until you hit that piece of code.
The very fact that you think you don't have those kinds of issues just exemplifies how you actually are just ignorant to all the type errors you have in your code because you haven't tested enough, hit the right edge case, etc.
Once you have written down the shape of the data flowing through your program in a way that a compiler can check you'll be able to reason about the whole program better and you might find issues much faster.
I think that types can directly help a lot with logic errors as well: one of the things people say most often when discussing typed programming language is that you can make illegal states unrepresentable, which means that you can encode logic into the type system itself.
Over the years I feel like I have read this comment at least ten times from different commenters (and the second time this month) and I cannot really fathom it. I consider myself a pretty good developer, and I have type errors many times a day. It is perhaps the most common error I encounter, and thankfully one of of easiest to fix with static typing.
By far the biggest recent productivity gain I have made using types is by generating the types along with client code for APIs via a swagger doc. I cannot overstate the value in seeing the types update when the backend devs have changed the API, and getting a compiler error when it doesn’t match with your code. By having the types the next developer after me is going to be spending far less time getting up to speed with the codebase.
I started programming with static types early in my career so perhaps I have become wired to lean heavily on the type system.
I have made a lot of code that works on a lot of third party APIs (The major LLMS, Image generators, E-commerce stuff) and yea it's all been easy breezy and never thought I wish I had types.
Different people just work in different ways.
https://news.ycombinator.com/item?id=35892250
Personally I like using typescript's namespaces that have no nice-enough jsdoc/js equivalent, but if tsc/tsserver had an option to mutate in-place typescript syntax to jsdoc notations where possible I would use it as much as possible.