Many people fail to see that the real benefit of using TypeScript is better tooling (code completion, intenseness, refactoring capabilities, self-documenting code) and not the mere ability to catch some stupid runtime errors at compile time.
This is one of the reasons I find it hard to like TypeScript. Despite proclamations about reducing errors and maintainability, I have seen many developers largely motivated to introduce TypeScript for no reason other than the ability to hit "." and see what comes next. While that is a good goal, transmogrifying a type system (and a rather weak one at that) into an IntelliSense annotation mechanism seems excessive.
It's comments like this that make me feel better about my own decisions.
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.
Do you have an alternative suggestion? Because the ability to type "." and see what comes next, go-to-definition, find all references, rename symbol, etc. are all enormous time savers.
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?
No they don't. They can make a decent guess occasionally but it's not remotely the same as in typed languages where it's accurate and works all the time.
It is absolutely a unique feature of typed languages.
Why do you think the type system is weak? I was using PureScript (Haskell derivative) prior to TypeScript, and I have found its typing capabilities to be very impressive.
If history is an indication, any part of the JavaScript ecosystem that is not part of a formal standard, no matter how widely used or deeply integrated into the industry, is prone to getting replaced or obsoleted. There was a time when front-end development without jQuery was unthinkable. We now seem to be slowly coming out of any era when front-end development without reactive component based SPAs (React, Angular etc.) was unthinkable. I suspect that in the long run, compile-to-JS type systems will go the same way. Perhaps the alternative is a set of optional run-time validation capabilities built into ECMAScript (syntactic sugar over `typeof`?), whatever that may be.
Disclaimer: I’m not a frontend dev so what I’m about to say might very well be nonsense, but I thought that jquery became popular not due to shortcomings in the JS language, but in the DOM API. So I think TypeScript is a very different case, as it fills a void in the language itself (lack of types). That doesn’t mean that in the future types won’t be added to the lang spec, but if that happens I think it would be very heavily influenced by TypeScript (e.g. like what happened with Hibernate and JPA).
Correct, at least from my experience. In my personal projects I was heavily Vanilla JS, but I also didn’t care if IE didn’t have full functionality (I did try to use graceful degradation when functionality was important, like navigation), but in any professional setting it would be maddening to rely on JS and not use something like jQuery. Coding around how each browser decided to give scroll position or the differences in accessing other DOM properties by hand could be tedious depending on what you wanted to do, and jQuery abstracted that effectively.
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.
Jquery became popular because at the time there were all these browsers and none of them did things the same. They weren’t standards compliant like most browsers are today. So you ended up writing a ton of code and css that basically said, “if browser x - do this - else if browser y - do this”. Then jQuery came along and took care of all of that for you. They made it so you could just write for jquery and it would take care of translating it into what browser the person viewing the site was using. It made things so much easier. jQuery was basically write once, run everywhere, for the browsers of those days.
If types were added to javascript it could also dramatically improve the performance of javascript virtual machines (V8 and friends). It seems so silly to me that I write typescript, then the types are erased from my code, sent to the browser, and then the browser tries to infer them as part of its own optimization process.
Adding types to javascript proper would be fantastic.
This proposal is not about adding types to JavaScript. This proposal is about new syntax for comments in JavaScript. Virtual machine will not use this information.
> If types were added to javascript it could also dramatically improve the performance of javascript virtual machines
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.
After having used WASM on the client side, I have my doubts.
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.
> WASM is good for things that need to be as fast as possible
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.
It doesn’t approach the convenience of JS dev tools.
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 actually think about this I’m entirely the opposite way. The moment all browser APIs especially the DOM become usable from WASM it’s over for JS and would no longer be the obvious choice as it’s suddenly not the only game in town and the hacks that were required before such as compile to JS for example stop mattering.
jQuery is a bit of a poor example in the context since most of the stuff jQuery provides HAS been integrated into the standard making the lib obsolete. If the ES standard introduces types in a good way that will of course make TS obsolete.
I find TypeScript's type system
fascinating, especially the intersection types. I wish there was an article contrasting TS's type system with that of other languages and just pointing out the unique to TS parts.
Flow supports both nominal types for classes with correct variance and structural types for everything else. This is correct model for js, flow is ahead of typescript in this case.
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.
Those are exact object types which have first class support in flow and no support with exception of literals like you mention in typescript. Flow is ahead in this case.
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.
It feels like the same information is repeated often 2, sometimes even 3 times. And overall, I don't think this book has anything more than what's already in official docs.
Perhaps it is LLM generated, as git says it is ~3 months old - but it links to a page on the TypeScript website which was removed a long time before that, https://www.typescriptlang.org/dt/search
I would actually love a “Typescript: The good parts” as a spiritual sequel to Javascript: The good parts. [0] Something that starts at the basics and builds upon that knowledge layer by layer like this handbook, but doesn’t dedicate more than a page to any one topic, and doesn’t repeat itself. Not a tutorial, but more like a glossary ordered by abstraction.
Plus, there’s a lot of Typescript I would consider not part of the “good stuff”, we can leave out enums.
Try Dan Vanderkam's "Effective Typescript: 62 Specific Ways to Improve YourTypeScript" (O'Reilly). I'm no TS guru, but IMHO it's pretty well-grounded in first principles.
If you mean traditional enums, called unions in Typescript and represented by the pipe symbol, then nothing. But if you mean the named Enum keyword in Typescript, then the problem is that they emit runtime code and aren't type safe.
Amongst their issues is the issue of enum vs const enum. These compile to different outputs and support different behaviors. It’s not possible to compile a TS file that uses them without looking at the enum declaration to see if it’s const. It’s no longer possible to strip the types and have something that any JS bundler can understand.
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).
I guess I don't value the "TS transpiles to JS 1-to-1" property very much.
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.
yeah I took a look and couldnt help but feeling like it was a laundry list with minimal examples and not always telling you why or when you would use a certain feature of TypeScript. Example: TypeScript _does_ enable you to overload functions, but overloading functions is nearly never the best way to do something, often cited as a spaghetti code pattern
recently there are a few stories about "using jsdoc for static typing instead of typescript as a JS programmer", I wonder when JS can add support of static typing directly as Python did, that will be nicer without learning a new language like TS.
TS is great, I just never could find time to learn one more language.
The projects that are using JSDoc for typings are doing so because they are way, way out on the edge in ways that stress Typescript compilers. They're doing weird stuff. It isn't a recommended path unless you absolutely need it; it's sacrificing a lot in order to yield faster round-trip time on codebases that have no other option.
Typescript isn't really "a new language", either. It's a pretty mild superset.
> because they are way, way out on the edge in ways that stress Typescript compilers
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.
> Probably the main reason people typecheck js with jsdoc annotations is because they don't want a TS compile step.
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?
The best thing with TS is you can apply as much or as little as you want. Start by adding the compiler to your workflow and get it to work without making any changes to your code. Then add a couple types and see how it goes.
You can achieve the same thing TS does with JSDoc, it's just a lot harder to control it across teams. TS wouldn't be very useful on its own for our usage, but once you couple ESlint with TSconfig and setup your ourganisationwide vsc .settings for TS usesage you can really control the flow of how every developer on your team works with TS. I'm not sure JSDoc has the equivalent to @typescript-plugin rulesets for linting purposes, or if you can build the rules directly into your CI pipeline in a way that prevents rulebreakers from comitting their code.
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.
Yes, no language has static typing until you run a static typechecker; for some languages you don’t notice because it is integrated into the normal compiler, etc.
Every time I say "I'm not gonna beed typescript for something this small", something happens that makes me think typescript may have been better anyway.
I agree, but I do wonder why the knee jerk reaction is "I'm not going to need it". The setup cost is basically zero! If TypeScript offers any benefit at all, why _not_ use it, since the benefits will come at near zero cost?
IMO the benefits of TS are huge, but probably the biggest benefit is that refactoring becomes almost trivial in most cases - just change the type of a variable/function/etc and the compiler will tell you every line in your codebase that needs to change in real time.
> refactoring becomes almost trivial in most cases
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.
Very timely. I've been using some inherited Typescript on a project for a while and was looking for exactly this kind of concise laying out of the language that you can read in an hour or two.
I think GP wants something akin to Beej’s guides, where he presents you with like 10 formats on the homepage and you pick the one that works best for your device and use case: https://beej.us/guide/bgnet/
