Not OP but I do tend to avoid TS. I don't like the additional friction of working with the language (transpiling, unable to copy/paste directly into an interpreter). I also feel like the community at large writes awful baroque code that makes me want to die. Why use a function when 18 classes subclassing eachother across 4 files will do? If you're familiar with the tiktoker @khaby.lame, TS feels like exactly the over-complicated life hacks he mocks.
I've found the perfect middleground is typescript checking with JSDoc syntax. The code is just JS, no emitting necessary, but you get all the type checking.
Together with testing of @example stanzas, you get everything for cheap-ish.
Alas, there is no good JSDoc @example test runner¹. This would be very valuable. If there were, I would let that handle my unit tests and focus only on integration testing.
Edit: runtime type checking at the boundary is also valuable! I've tried runtypes, but actually prefer compiling the ts definitions to JSON Schema with typescript-json-schema, and checking with plain JSON Schema validation.
¹I've used @supabase/doctest-js and jsdoctest, and found both lacking. If you know of a better one, please share!
TS !== crazy OOP.
For some reason, there are people who just want to use Java style OOP in TS. Nest.js is one library heavily promoting that. I can't digest such codebases, they are the definition of over-engineering to me.
Fortunately, out of dozens of medium to big TS projects I worked on, only one used that style. In all the other projects there were very few if any classes.
Fair, I should have been more clear when I said "interpreter" what I really meant is "the chrome debugger" which is one of JS/Node's absolute killer features. I believe support there is on it's way, though I very much doubt it'll convince me of TS' value.
I used to be much more bullish on TS, I like the idea of strong typing in general but the more I use TS the more I feel like it's just the worst of both worlds. I much prefer my types to be deeply embedded in the language design, types as varnish don't make sense to me anymore.
Oh, in the console? Probably won't work? I'm saying that you can run chrome's debugger on source mapped TS files, which is really really nice for bug-hunting and developing locally
But I mean if the biggest complaint you have is that it doesn't run in a browsers REPL console, that feels pretty minor to me. You can easily find TS REPLs all over the web
Right, but the actual benefit comes from having the REPL and the debugger in the same place. Plus the chrome REPL is fantastic, so suggesting I just use a different one is sorta like saying "you can just use your phone" when my default is a Hasselblad. When I'm writing JS/Node I can write code in the REPL in the context within which it will execute, it really cuts down on how much I have to hold in my head at one time because I can just ask the computer. It also makes exploring much much faster because my iteration times are as fast as the computer can run my code. I find it's a much more natural way of programming and about as close to SLIME as I can get while still writing in a language that has easy economic value.
Also for me, the benefits of a statically typed language on a large team heavily outweighs not having TS in a chrome REPL. It's not even close. Maybe your use case is different, but for me it seems like you're missing the forest for the trees.
> benefits of a statically typed language on a large team
I mean yeah, sure, if you have to work on a large team in the browser/node you're going to have to make tradeoffs for that, and using TS seems like it'll help everyone go home at 5. I don't think I'm missing the forest for the trees, we're talking past each-other.
To illustrate a bit further, while I like Rust a lot, (the problems it tackles are MUCH more real than the ones TS does) and I put in the effort to learn and use it on a few personal projects I still find myself reaching for C almost universally these days. Even in the case of Rust's very useful tradeoffs I feel like they cost too much of my freedom, and TS' guarantees are much more surface level for a similar cost.
No one using TS claims JS is broken. People want a good type system in javascript, and with that obviously comes a new layer of complexity
The tradeoff is clearly worth it for certain use cases, and clearly not worth it for others. It seems you are discounting and ignoring cases when it is worth it.
I don't think there are no use cases, but I think they are rarer than people think, and that for the most of development TS will be picked because it's someone preference not because of its actual benefits.
For example if you want prop types you use propTypes. In React TS replaces good error handling for horrible obscure errors and slows down development considerably etc. etc.
propTypes does runtime type checking, which is a different kettle of fish from static type checking.
The advantage to static type checking is that it removes the performance cost of runtime type checking where it's unnecessary; the language's rules make it impossible to build some constructs where the wrong types get mashed together. The tradeoff is that you have to code so the wrong types don't get mashed together (which is, arguably, your goal in the first place).
You can do everything a statically-typed language does in a non-statically-typed language via best practices, but that's a bit like saying you can do everything a compiled language does in assembly via emulating what the compiler would output. In theory, the compiler is saving you the headache of doing that (but depending on the size of what you're trying to write, sometimes it is simpler to write it in JavaScript and skip the type safety. That code is harder to grow, but not all code grows!).
This is a good response to drill down on, because the poster's assessment of the purpose is accurate.
Yes, much of both TypeScript and React are there to minimize performance costs and improve software reliability in tens-of-thousands-of-lines-of-code projects: TypeScript is using static type safety to replace the need for dynamic typechecking (decreasing the expected runtime error rate and the runtime cost of dynamic type analysis; static typing tells you both when you must runtime-coerce types and when such coercion is unnecessary and would waste performance). React is using delta-detection of lighter-weight objects to determine when heavier-weight objects in a declarative user interface API need to be changed, impacting performance (because a handful of equality compares against objects or plain data is a fraction of the cost of repainting every pixel in a table with pixels representing the exact same information as before to the end user).
These are problems people face, but if they are not the problems you're facing, they might not be the tools you need. Not everyone is writing the Facebook UI. There are lighter-weight tools out there that solve similar problems with less complexity (the tradeoff, perhaps, being that if you do find your software needing to scale to handle updates to represent complex, heterogeneous data or infinite streams of information, those tools might not scale easily... But how many people actually have that problem?).
"Use the right tool for the job" is one of the cornerstones of the art of software engineering.
Yes, the right tool for the job, but because TS covers a set of tools its rare that this is exactly the tool you need. I'm sure there are cases but mostly I think people just use it because of the hype/preference and I really hate to make prototypes with TS.
Yeah, prototypes are probably the wrong use case for React or TypeScript because they can crash without causing someone $X million in revenue (by definition; if it can cost someone $X million in revenue, it's no longer a prototype and the team maintaining it probably wants stronger guarantees than what native JavaScript provides for proper use of APIs and data handling if they ever want to sleep at night).
I'm really glad proptypes are not used anymore, ts is simply better. It's more flexible, gives stronger guarantees in some cases (PropTypes.func does zero checks for signature, for example), better support in editors, better integration with other libraries, allows typing hooks/context. If you need runtime checks, use io-ts or runtypes.
Which ones do you need to do everything TS does?
> without the horrible tradeoffs
Which tradeoffs are horrible?