The Concise TypeScript Book
github.com
github.com
Just as yanis_t said, they're easily worth it even if you ignore the significant bug reduction (approximately 15%).
I don't know of any other way to get that kind of productivity boost. What would you suggest instead?
It is absolutely a unique feature of typed languages.
Because if that was the only benefit typescript had, it would be a win. I mean that was the whole point with JSDOC.
Anything that shortens the feedback loop from writing the code to seeing if it works is a win.
This is the equivalent of saying, "I see many people switching jobs for no reason other than to make more money". Like... That's the not the only reason but it's a big one.
Then you get into algebraic data types, and encoding logic constraints into the type system, and you can make entire classes of bugs impossible to write.
Type systems are about safety and productivity.
Forget runtime type validation, TS is really for preventing bugs at development time as well as IDE integration.
Adding types to javascript proper would be fantastic.
Are you sure? In my understanding modern JS engines basically makes type inference on the code anyway, and in the rare case when types are observed to change at runtime, it is special-cased. So static types might simplify this but I dont see how it would dramatically improve performance.
That said I really doubt JS will actually get sound static types ever. Typescript is not sound.
At least typescript discourage writing functions where the parameters can have wildly different types since this is un-ergonomic and/or hard to type.
I think you’re correct that, if the language formally adopted types, it would look similar to TypeScript. How _much_ of TS would be mirrored may be a different story - it’s incredibly extensive in some areas, I’m still learning new things about it as I’ve only recently started getting into it for work, and there’s a lot to it beyond basic type support.
It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits.
The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
The JIT in V8 and others is pretty solid.
For example, you can’t have a REPL and high-level debugger combo, you just get a very basic low-level debugger. It’s a 90s debugging experience.
You can’t even have a modern low-level debugger because you can’t control how the browser executes your WASM, unlike in a native executable where you can run a debugger and then run your code inside it.
I guess you could have a WASM based debugger that has a WASM interpreter inside, and then you run your code inside that, but my God if that’s the future then I want no part of it.
i would've thought that WASM was really only "good" for reusing existing software written in other languages not intended for the web, by recompiling it into WASM.
For example, you want to create a web version of an app written with QT or some other widgeting framework which could get a WASM target.
I think the plan was to compile to WASM. The hype phase seems to be over, but afaict it’s been delivering on at least some of it’s promises no?
https://www.typescriptlang.org/play#example/structural-typin...
It seems particularly suited to dealing with random JSON payloads.
Objects passed to a function that accepts an object type can generally have more properties that needed given Typescript’s structural typing. That is unless you pass a literal directly to the function (I.e. inline the obj variable in the linked example). In which case Typescript will complain about the excess properties. Ergonomic but confusing the first time you come across it.
type Exactly<Candidate, Shape> = Shape & {
[key in keyof Candidate]: key extends keyof Shape ? Shape[key] : never;
};
It can't be represented in TypeScript type system.
You can't create utility type to have it.
Have a look at Flow docs [0] if you want to learn more.
His utility type works on diff between two provided types, this is something else.
Exact object type is a kind of type which doesn't allow extra, undeclared properties to be used for it to be satisfied.
You can't emulate it if it's not supported by type system.
The whole thing is implemented way better in Flow than TypeScript, ie. spreads map to how runtime treats them, this is also not something TypeScript can represent and Flow supports.
Also opaque types have first class support and many other things.
[0] https://flow.org/en/docs/types/objects/#exact-and-inexact-ob...
Plus, there’s a lot of Typescript I would consider not part of the “good stuff”, we can leave out enums.
shrugs
I like em too
They don't compile down to just the same code with the type annotations and definitions removed, which is often considered to be the ideal that typescript should follow. Instead, they compile down to some more complicated blob of javascript. People critique and avoid typescript's namespaces for the same reason.
> Enum types in general are very useful.
You can use unions for the same purpose without the aforementioned drawback, and unions have other benefits which typescript's enums don't offer, like support for more complex data types, which makes unions closer to set of features more modern languages tend to offer via enums, while making enums closer to the barebones enums found in languages like C and C++ (effectively just a set of named constants enclosed into a type).
Unions are useful for quite a few things. But I literally was talking about the barebones (and thus simple to write) C/C++ style enums. Where I know it can be one of several primitive values and not have to spend the time creating a class for each possible value.
TS is great, I just never could find time to learn one more language.
Typescript isn't really "a new language", either. It's a pretty mild superset.
I don't think this is true at all. Probably the main reason people typecheck js with jsdoc annotations is because they don't want a TS compile step.
Nodejs ES modules, and typescript, make it more complicated that it needs to be to write JS specifically for nodejs/cli scripts (not bundling to run in the browser). I now just prefer to // @ts-check my js files when writing node scripts.
Right, I agree--because it's slow. Like AFAIK the tooling roundtrip is why Svelte/SvelteKit made the change. For normal projects, you don't have that same problem.
> for nodejs/cli scripts
I just use ts-node with the ESM loader. It's drop-in, for my purposes at least. What problems are you seeing?
Aside from that, it's a little different to work with JSDoc. It doesn't have quite the same intellisense integration in VSC. It's also a little different for many developers who aren't necessarily used to writing their documentation first or along with their code, but are used to working with things like C#, Java or similar.
If you want to put in the effort, you can likely setup a JSDoc dev environment for JS where you're getting the benefits of TS without the compiling. I don't see us doing it any time soon, but as someone who's very fond of TS I also wouldn't be surprised if we won't be using it for JavaScript in 5 years.
def take_a_string_and_return_a_boolean(x: str) -> bool:
return x
take_a_string_and_return_a_boolean("hello world") # => "hello world"
take_a_string_and_return_a_boolean(1234) # => 1234
take_a_string_and_return_a_boolean(None) # => NoneI find it mildly useful as a form of documentation - and the intellisense is nice, but otherwise find it cumbersome to use.
In general - while I’ve experienced some issues with types in JS, it usually isn’t the root cause of most bugs I encounter.
Maybe if you already have learned TS, otherwise there is a huge cost to learning it.
And when it does not become trivial, it is an indicator it would be borderline impossible without it.
After a rather extensive refactor I once did the compiler gave me over 4.000 typescript errors. It would be a tremendous effort for all of these to be identified and ironed out, probably taking years because many issues were very circumstantial.
There's also a beta copilot for docs which includes typescript