19 ms·

Problems with TypeScript

• nikolasburk 7y ago
  While TypeScript isn't perfect, it surely is a major step forward compared to plain JS! Newer features like conditional types and mapped types open up new possibilities. My colleague actually recently gave a fantastic talk about these advanced features at the TS Berlin Meetup, highly recommended watch if you want to see what it's like pushing the boundaries of TypeScript: https://www.youtube.com/watch?v=PJjeHzvi_VQ https://www.youtube.com/watch?v=PJjeHzvi_VQ
  • vorticalbox 7y ago
    Still compiles Down to js where you lose all type checking. Have you ever looked at a compiled js file? Things like spreading objects I to each other {...a,...b} End up being a nest object assign which is actually slower than spreading.
    • skrebbel 7y ago
      Slower and more widely supported. Also iirc you can set the compile target to esnext and it will compile to the object spread expression.
    • mixedCase 7y ago
      Checks don't need to be in the JS, they just need to be there at compile time. No differently than a binary generated by Haskell; and you have source maps to replace debugging symbols too. And as mentioned by another user, you can choose your compile target to a specific version of JS which does support object spreading.
      • hopia 7y ago
        Actually, Haskell compilation produces more type information available at runtime than Typescript's compiler does. For example, algebraic data types turn into tagged unions at runtime on Haskell, allowing pattern matching to operate on them. Whereas on Typescript the compilation process erases all this information, making it impossible to evaluate many such expressions. There are multiple 3rd party solutions to this, such as: https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
        • mixedCase 7y ago
          > algebraic data types turn into tagged unions at runtime on Haskell How does that work? I know next to nothing about the GHC, but in Haskell I would assume some tag is associated with each constructor (probably an integer) for the ADT and that the actual pattern matching gets compiled down to simple comparisons to either that integer or the right function for the more complex cases (pattern matching strings and other values). TypeScript essentially does that, except that the tags are not going to be optimized by the compiler (they will remain strings if the dev uses them), and the "pattern matching" is just regular conditional checks (if, ternary or switch) with even the exhaustiveness check being done as a manual hack introduced by the dev and checked at compile-time (the else or default case assigning the value to the never type). As for runtime values, Haskell also needs to validate types when deserializing, although that will be done by the deserialization libraries such as Aeson instead of deserializing and then optionally validating like in TS.
          • hopia 7y ago
            Yes, you're right, it should be an integer comparison check ultimately. > TypeScript essentially does that, except that the tags are not going to be optimized by the compiler What do you mean by this? Typescript erases type information during compilation. So you would not be able to emulate pattern matching against types on TS. Or you could if you manually added some common tag to every single data type like interface. Or are you talking about just compile-time type checking on TS?
            • mixedCase 7y ago
              > Or you could if you manually added some common tag to every single data type like interface. This is how you emulate them, I took it for granted and neglected to explicitly mention this is a moderately popular convention in TypeScript (those are the tags I referred to). fp-ts for example uses it all over the place. With this the end result is essentially the same with compile-time type-safety for everything, and compiled down to an untyped binary or an untyped JS blob.
          • thelazydogsback 7y ago
    • valand 7y ago
      friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
      • krowokoliz 7y ago
        Why would you want runtime checks over static checks? The one thing I can think of is type asserting input from other js code, but surely you just want that on the entry function to your code, not in the internal bits.
        • valand 7y ago
          TS compiled can still be faulty if the app is injected with data of different type Runtime type checks is the lost link between static checks at compile time and arbitrary i/o data type in compiled js code. You define a type in a similar way you would define TS types. At compile time it would give you the typescript type checks. At runtime it will help you determine if data has the correct type exactly as your typescript app expected. There is extra work though, handling error if there is a faulty data type
        • Scooty 7y ago
          Runtime type checking is necessary to ensure data received from untrustworthy sources matches compiletime types.
    • michaelcampbell 7y ago
      > Still compiles Down to js where you lose all type checking. Haskell compiles down to machine code, so...
      • filleduchaos 7y ago
        This is an often expressed sentiment that I feel misses the point by a mile, which is that Haskell (as well as other languages in its class) _forces_ you to actually write programs that are soundly typed at compile time. TypeScript very explicitly does not, instead taking an approach to typing that's more in line with languages like Java or C# (which rely on both compile time and runtime type checking to enforce a program's types) but failing to provide the runtime type checking to back it up. And even that wouldn't be so much of a problem if it didn't compile to a language as dynamically and weakly typed as JavaScript.
        • michaelcampbell 7y ago
          > I feel misses the point by a mile I disagree. The point to which I refer was stating that because language A with type safety of some degree compiled to another form B without it obviates A's type safety altogether. The destination isn't the point; it's the compilation of the beginning.
    • deleted 7y ago
      [deleted]
    • bradstewart 7y ago
      > Still compiles Down to js where you lose all type checking. While true, what's the point of this argument? You cannot get language-level runtime typechecking in the browser. At all. With any toolchain.
      • filleduchaos 7y ago
        Several compile-to-JS projects do ship a type-checking (amongst other things) runtime to the browser.
        • leshow 7y ago
          It's better to do it statically and save yourself the overhead at runtime. I don't see why you'd even want it the other way.
    • reificator 7y ago
      > Still compiles Down to js where you lose all type checking. Yes and C still compiles to assembly with no type checking. What's your point?
      • filleduchaos 7y ago
        C is an infamously unsafe language, so the question might rather be what _your_ point is.
        • reificator 7y ago
          > C is an infamously unsafe language, so the question might rather be what _your_ point is. Feel free to insert Rust or Haskell or whatever your language of choice is in place of C and my point remains the same. Sure you can include type information inside the assembly output and some sort of runtime code to handle that, but that doesn't change the fact that your compile target has no type system. Typescript could do the same if they desired, and in fact I think they offer the option. Compiling a language with a type system to a language without is not a knock against that language's type system. Compiling typescript's decently comprehensive/expressive compile-time type system to javascript's basic runtime type system actually seems like a step up compared to a lot of other compilation targets.
          • filleduchaos 7y ago
            Like I have said elsewhere, Haskell and Rust and other such languages actually force you (to varying degrees) to write programs that are soundly typed at compile time. TypeScript explicitly doesn't, and instead treats program types in a way that's far more like Java or C# (which rely on both compile time and runtime type checking to enforce a program's types, and even at that are not entirely sound) without the runtime type checking to back it up. > Typescript could do the same if they desired, and in fact I think they offer the option. They very explicitly do not and have stated severally that it is not within the goals of the project to do so, which is something anyone actually familiar with the language should know. > Compiling a language with a type system to a language without is not a knock against that language's type system When you don't cherry-pick statements out of context, the point of what I said becomes rather obvious; if a language doesn't actually guarantee type safety at compile time, having a primary compilation target that takes a fascinatingly lax approach to data types is objectively worse (wrt type safety) than having one that's more strict.
    • dragonwriter 7y ago
      > Still compiles Down to js where you lose all type checking. And C, Rust, Haskell, etc., all compile down to native code where you lose all type checking, so what? Outside of compiler bugs, what is statically proven at compile time doesn't change at runtime. (Yes, C also has a notoriously loose and abusable compile time type system, but that's a different issue.) > Things like spreading objects I to each other > {...a,...b} > End up being a nest object assign which is actually slower than spreading. Yes, if you use the default target (ES3), typescript emits JS compatible with downright ancient browsers which is super portable at the cost of being less efficient than targeting modern JS features, like spread syntax which was introduced in ES6. You can also set the target to newer ECMAScript levels, including “ESNext”, at the cost of compatibility.
• gandalfgeek 7y ago
  There has been some research done on how programmers interpret gradual typing systems, and it turns out that it breaks many expectations and ends up being confusing. Explainer video: https://www.youtube.com/watch?v=iRf9l3Bz7nA https://www.youtube.com/watch?v=iRf9l3Bz7nA Original paper: https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-beh-grad-types-user-study/paper.pdf https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-...
  • jamil7 7y ago
    Interesting paper thanks for sharing.
  • mcbits 7y ago
    Note that the paper is concerned with run-time type checking and glosses over the fact that most/all of those code samples in the survey would be rejected at compile time by a static type checker (or at least by TypeScript). Their conclusion that "erasure" is disliked and unexpected is effectively saying the underlying dynamic language's behavior is disliked and unexpected. Of course it's possible to deliberately or accidentally coerce TypeScript into violating its type constraints and behaving in JavaScript's disliked and unexpected ways, but the survey questions would have to be substantially different, and likely the responses as well.
• bigodines 7y ago
  yes
  • napolux 7y ago
    Can confirm.
  • josteink 7y ago
    Usually I’d downvote “non-contributing” replies like this, but for this one I’m making an exception. Why? The answer to the question is utterly obvious, and that one word is really all you need to answer it.
  • __s 7y ago
    Was working an application written in JS Converted it to TS. In the process of fixing up types, it found bugs for us. Value demonstrated
• crooked-v 7y ago
  Typescript from the ground up is absolutely worth it, starting with how it gives you full IDE inference for all those "big blob of options" objects that a lot of JS methods use.
  • tantalor 7y ago
    Any IDE could do that for JavaScript; it has nothing to do with TypeScript.
    • enobrev 7y ago
      I agree, and I've found that WebStorm (and other JetBrains software with JavaScript support) does a great job at it, although I do find TypeScript improves the experience.
    • Rychard 7y ago
      How could this be done for JavaScript without any mechanism for signifying the type of object that is expected?
      • mikewhy 7y ago
        JS files can use JSDoc, which typescript handles (when you edit a JS file in VS Code, you're already secretly using typescript).
      • jamil7 7y ago
        If you're using a third party dependency that has type definitions tsserver / VSCode will pick it up regardless of whether you're writing js or ts.
        • Rapzid 7y ago
          I don't believe many understand how much tsserver is doing behind the scenes in Vscode for JS code bases.. Of course any IDE can do that, because they can use tsserver via the language server protocol haha.
• why-oh-why 7y ago
  Instead of focusing on what TS does not, focus on what it does. TypeScript is not sound; JavaScript isn’t either. The first one will catch some type errors, the second will catch none. Syntax highlighting, linting, testing, and now type checking: every step can make you more confident about the code you ship, before it even hits the browser. You can forgo using any help and probably you’ll code faster, but, again, you lose confidence.
  • lucisferre 7y ago
    Tests are the only thing that give me confidence about any code I write, Javascript or otherwise.
    • jsight 7y ago
      And compilers are effectively a rudimentary form of test. They are not sufficient, nor necessary but they do validate some basic assumptions about the code.
      • mixedCase 7y ago
        They also remove redundant testing (you only need to prove something fulfills certain properties once as long as you have a type for it); and the more advanced the type system the fewer tests needed.
        • valand 7y ago
          friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
          • paulcowan1970 7y ago
            I mention io-ts https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts in the post
• alkonaut 7y ago
  Doesn't typescript enable things like renaming an identifier and all it's usages, without doing it as a global text replace, or worrying that you might have renamed something you shoudldn't? Or is the type checking so "leaky" in a typical project that that kind of luxury (That would be done every day by Java or C# developers etc) isn't really available anyway? Unless it's a massive overhead to use typescript, autocomplete, renaming etc seems like they would make it worth it on their own.
  • scrollaway 7y ago
    I use what you describe on a regular basis in typescript without issues indeed.
  • city41 7y ago
    This will depend on the project, as TS can go from very loose to very strict depending on the settings. For a project with all strict settings turned on and casts minimized, then I find refactoring is an absolute breeze. I have successfully done huge refactors that completely worked without any (known) regressions as soon as all the tsc errors are resolved. And your editor combined with the language server drives a lot of the refactoring (similar to Java/C# as you alluded to) To me this is the real killer feature of TS over JS.
• adrusi 7y ago
  Mentioned as an afterthought at the end: IDE support for typescript, the best part about using the language. Not mentioned: type annotations serve as a form of documentation that gets statically verified. The verification strategy has some cracks, and there's a (fairly small) chance that the documentation will end up misleading. But API documentation for javascript projects generally sucks, and typescript helps to fill a lot of the common gaps.
  • nocommentx 7y ago
    i'm tired of devs that claim that TS and GraphQL are "self-documenting" and don't need to write any documentation. it doesn't fill in the common gaps, it's just an excuse to not have to think about or talk to users.
    • notmyfuture 7y ago
      Do you think this claim is specific to TS/GraphQL? I've heard it from devs well before either existed.
    • krowokoliz 7y ago
      GraphQL libraries often have built in documentation abilities that make it trivial to document, extract, and make pretty api docs fairly trivially. It’s still like pulling teeth to get developers to use the functionality at all. That said, the appropriate reaction is to laugh louder the longer they make the claim.
    • cowmoo728 7y ago
      In my experience it helps devs move the documentation up one level. By that I mean they don't just document the mechanics and type signature of the function, but instead document what the function is used for and why it exists. You can already write decent docs in plain JS, but I've found that having the types already documented by the compiler helps devs move up that level of thinking automatically.
    • paulcowan1970 7y ago
      I'm the author and the claims that Graphql and typescript replace documentation is madness
• hanneswidrig 7y ago
  These kind of articles seem to be commonplace and I frankly do not think they provide any productive value. "any" is supposed to be the escape hatch as TypeScript is designed to be incremental. Anyone with a semblance of understanding knows that TypeScript transpiles into regular JavaScript, you don't run TypeScript code in the browser.
  • valand 7y ago
    Friendly tips: you can replace any with unknown. Other friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes
    • sadlion 7y ago
      Can you please provide more detail when it's best to use runtime type checks? For webapps with strict TS config, I'm failing to see the advantage. Runtime errors can occur when crossing boundaries from server API to UI but when you discover the exceptions, you go fix your contract.
      • valand 7y ago
        1st it's easier to identify which contract is inaccurate, or even whether the contract is inaccurate or not in the first place 2nd it's more convenient for both the end-user and the developers that errors are handled this way
• valand 7y ago
  Guaranteed almost 100% type soundness!!! Non TypeScript user will hate this. Config it to maximum strictness! Add in runtime type checks Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... Bring type to business logic, e.g. RegisteredUser { userId: number, email: string } AnonymousUser { userId: number, email: null } User = RegisteredUser | AnonymousUser Handle errors ala Rust, Return errors/errortype rather than throws Utilize structure to determine result, e.g. Failure { error: Error, value: null } Success<T> { error: null, value: T } It is worth it. My experience with TypeScript is a whole lot different. Conspiracy theory inducing facts: - LogRocket's main use is monitoring bugs in browser application - Airbnb is LogRocket's customer
  • dkdbejwi383 7y ago
    I'm interested in the way you describe handling errors here. Do you have any real world examples you can point me to? Thanks
    • nesarkvechnep 7y ago
      Check out the Either monad in Haskell. It has an implementation in the JS library funfix.
    • valand 7y ago
      I would have gladly shown it to you, but almost all my code is proprietary Here's a small example: ``` function fetchCurrentWeather(){ return fetch(...) .catch(() => ({ error: new NetworkError(), value: null}) .then(res => res.json()) .then(maybeWeather => Weather.is(maybeWeather) ? { value: maybeWeather, error: null} : { error: new DecodeError(), value: null}) .catch(() => ({ error: new DecodeError(), value: null})) } // And then you use it somewhere in you react app async initialFetch(){ try { if (this.state.isLoading) return; this.setState({ isLoading: true, weather: null, error: null }); this.setState({ weather: await fetchCurrentWeather().then(reault => { if (result.error) throw result.error; return result.value; }) }); } catch (error) { this.setState({ error }) } finally { this.setState({ isLoading: false }); } } render(){ return ( <div> {this.state.isLoading && ...} {this.state.weather && ...} {this.state.error && ...} </div> ) } ```
• swyx 7y ago
  the title completely doesnt match the content, this is pure clickbait and logrocket is so shameless about it. i grit my teeth and click but am completely unsurprised at yet another low quality list of arguments that have been rehashed over and over. here's a less well known, more rigorous study: http://earlbarr.com/publications/typestudy.pdf http://earlbarr.com/publications/typestudy.pdf - To Type or Not to Type: Quantifying Detectable Bugs in JavaScript
  • nocommentx 7y ago
    they mention a time tax of 262 seconds median for TS annotations for their set of 400 bugs. almost 4.5 minutes. so idk, there seems to be some math missing in this paper about the actual trade offs. so maybe you get a 15% improvement in "detectable" bugs found, at a 13.3% time cost (60 minutes /4.5 minutes) per hour of work. worth it...? are your devs expensive? more expensive than QA.
    • eyelidlessness 7y ago
      Types are easier to read, reason about and maintain than tests, particularly if it's QA writing the tests instead of engineers.
• brenden2 7y ago
  I've found TypeScript and React with VSCode to be incredibly productive for web development. If you're on the fence, give it a shot. TypeScript is a superset of JavaScript, so it brings a lot of baggage along with it, but if you're writing frontend code it's a real pleasure to work with compared to JS.
• chaostheory 7y ago
  Another Typescript fan here. The title didn’t match the post content but I agree with everything he wrote concerning type “soundness”. From my POV it’s a downside of typescript but it makes sense since it’s just a superset of JavaScript
  • heisenbit 7y ago
    Yep, it ain't perfect but it is so much better than not having it. Anyone being concerned about TS adding overhead please take a look at how generics in Java work - both struggle with erasure of type information at compile time. Java may be sound but doing anything non trivial with generic types gets complex quickly. Compared to Java generics doing TS advanced types is almost a joy.
• nocommentx 7y ago
  nope - the loss in velocity is not worth using it unless you're a massive team. TS is for Java programmers who are mad at Javascript for existing and don't know how it works well enough to grok overloading etc. plus you get a lot of the benefits of TS in an IDE like VSCode without actually having to use types at all. if you're a javascript native, typescript is constricting and eliminates one of the best parts of javascript - no types!!
  • jaywalk 7y ago
    I'm not quite sure why you consider "no types" to be one of the best parts of JavaScript, but TypeScript certainly doesn't require the use of types. It just makes the functionality available.
    • deleted 7y ago
      [deleted]
  • tmountain 7y ago
    I think this depends on where you are measuring costs in your codebase. If you're strictly looking at time to market on your first iteration, then you're right, types are going to require more of your team's time up front. If you look at the total lifespan of a "real project", then type safety is likely going to represent a cost savings regarding time your team spends on bug fixes, refactoring, and maintaining legacy portions of your app. For context, I base the above sentiment on our team's last two years of effort in migrating key parts of our app to TypeScript (25 devs, ~500k lines of code). We've found that it has substantially reduced the number of defects that make it into production, and it has also reduced the number of round trips through QA. Clearly, this is only one data point, but hopefully it offers some perspective on why TS can be valuable in a codebase.
    • nocommentx 7y ago
      sounds like its working for you, so i'm glad. you're about what i'd consider a big team / codebase. i can't recommend TS to people trying to create product from nothing. if your startup is doing well, you can hire someone to annotate your code w/ types later ;)
• acemarke 7y ago
  I'd say it's definitely worth it. I wrote a blog post recently about my experiences learning and using TypeScript as both an app dev and a library maintainer for Redux: https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-using-typescript/ https://blog.isquaredsoftware.com/2019/11/blogged-answers-le... As part of that, I listed some of the tradeoffs and takeaways. In particular, I strongly recommend a "pragmatic 80%" approach to tackling TS.
• snek 7y ago
  Whenever that thing about Airbnb comes up I feel compelled to remind that it was a study of eight bugs, three of which ts would've prevented.
  • swyx 7y ago
    8 bugs? are you sure? did you watch the talk? https://www.youtube.com/watch?v=P-J9Eg7hJwE https://www.youtube.com/watch?v=P-J9Eg7hJwE
• trixie_ 7y ago
  The author's example is a trivial corner case that can be easily avoided. It is nowhere close to important enough to fuel the question of 'Is TypeScript Worth It?'
• tabtab 7y ago
  In general it seems hard to be in-between dynamic typing and static typing (compiling). As the article implies, one typically has to do more testing if dynamicness can allow "bad data" in. The trade-off for dynamicness is more productivity and (potentially) easier-to-read code because less code is needed on average to express an idea since type-related code isn't needed as often. But if TypeScript is not type-safe enough to reduce the need for fine-grained testing, then you get the worse of both worlds: the verbosity of types and the busy-work of micro-testing. That being said, I wish JavaScript would add a feature to allow optional parameter checking such as: function foo(a:intReq, b:datetime, c:datetimeReq, d) {...} Here, the "Req" ("required") suffix means the field can't be null or white-space. Parameter "d" has no type indicator. It's still "soft" type checking, but would catch a lot of problems earlier.
• 0xff00ffee 7y ago
  Typescript users: LOVE IT! Non-typescript users: ANOTHER layer? /sigh/ Cynical, yes, but that's because I haven't had a smooth onramping experience the times I thought about switching. Would love a recommendation.
  • celim307 7y ago
    When I introduce it to a new team, leaving js/jsx as valid and making TS optional is usually good enough. Whether through peeking at your TS code or just being curious, usually they come around, and if not, they are still responsible for their code. The tradeoff is theirs to make
  • AgloeDreams 7y ago
    Using TS since ~2017. Moving an existing codebase to it is a giant pain, otherwise it's not bad. It fits you into better practices, but don't treat it as types are always true. When debugging issues I'll commonly assume Typescript's types do not exist or how it would act if they are wrong. This is notably true of consuming API responses with mixed data types. Generally, what I really like about typescript is that you normally blend it with linting, minifying, and strong IDE integrations. These things, when combined, really help code readability and adherence to TS conventions and eventually save you from massive bugs that might not have been caught prior. Obviously, at the end of the day, how you use it really defines how helpful it is. All that said, I haven't ever really had major issues with the tools around TS.
• aecorredor 7y ago
  If you’re writing JS, then adding TS will give you a lot more reassurance when writing new code or refactoring old one. Even if it’s not perfect, I don’t see a reason why you’d choose JS over TS today other than maybe you don’t want to go through the first month of getting used to. Once you’re out of that, you’ll end up with code that’s much easier to reason about and also debug, in my humble opinion.
• sli 7y ago
  TypeScript feels worth it until you use something like Elm, then you realize just how lacking and TypeScript's type system truly is. I have grown rather weary of type systems that don't require you to be exhaustive and, for my money, types like `Omit` and `Pick` are nasty hacks that just let you pretend like you aren't doing dynamic types, something TypeScript does a lot. The TypeScript pattern of `someFunc<typeof someInput>` is just dynamic types with extra steps. Using `any` wouldn't really lose you much of anything, the "type" is just "whatever this input is". That's not a real type, that's a dolled-up dynamic type. But hey, it typechecks! TypeScript's major weakness is that it doesn't want to break away from Javascript. That strict dedication to being a superset means the type system explodes into ten thousand builtin types the come, seemingly at times, from nowhere, simply to control for the wildness of Javascript. It feels like a joke sometimes, and like I need to have encyclopedic knowledge of all these highly-specialized types that are included in the language and are often being used in the background. This leads to nearly impenetrable error messages regarding types, especially if you have a stack trace involving more than one object/record type (whatever you want to call it), it will expand all of them and just, no. It's unreadable. It can be read, but it cannot simply be grokked. TypeScript just doesn't impress me. I get far better results from other languages for a whole lot less work. TypeScript claims to want a balance between correctness and productivity but the language gives me neither of those things. My typical experience is that I wrote almost the same amount of actual code, but now also with types. Elm lets me write far less total code. Less code means less bugs and more productivity, and better types and better correctness is what gives you those things.
  • jamil7 7y ago
    I'm not really sure why you were downvoted since you raised some pretty relevant points. > TypeScript's major weakness is that it doesn't want to break away from Javascript. This seems to also be the source of it's popularity, it's the path of least resistance, sprinkling types on top of your existing codebase is a way easier sell.
    • deleted 7y ago
      [deleted]
    • 7y ago
• erokar 7y ago
  Thing is you can now have many of the benefits of TS without using it in your own code. Most popular libraries come with type definitions now and an editor like VS Code will take advantage of this and give you the same autocompletions TS would. TS introduces some friction for setting things up, it slows you down in initial development, increases LoC, etc. I do like the type documentation in function signatures, the autocompletion and the refactor support, but I think the project needs to be of a certain size for the cost/benefit trade off favors TS, typically a project that goes on for 6+ months and with 2 team members or more. Anything smaller than that and I wouldn't choose it myself.
• donpark 7y ago
  Worth it at component level. Hassle at application level. I use TS to write components and JS to write the app using those components.
• solomonb 7y ago
  Why do these sorts of articles always give vague definitions of Soundness and act like it exists on a spectrum? Soundness = Progress & Preservation. From Pierce's Types And Programming Languages: "Progress: A well typed term is not stuck (either it is a value or it can take a step according to the evaluation rules). Preservation: If a well typed term takes a step of evaluation, then the resulting term is well typed." There are not degrees to Soundness and it is a well defined term.
  • gjm11 7y ago
    You've shown that one can give a black-and-white definition of soundness and have it be useful. That doesn't mean that there's no way to give useful meaning to "more sound" or "less sound". Consider the following family of languages: L has a sound type system. LD (D for "dynamic") is L plus the ability to escape from it, in specially marked "unsafe" sections of code, into a dynamically typed system. (So evaluation can produce runtime errors, but they can be handled safely.) LC (C for "crash") is L plus the ability to escape in "unsafe" sections into a system like Ld's except that now type errors aren't checked for and caught at runtime, they just produce memory-stomping and buffer overflows and the like. D is just LD's "unsafe" language. C is just LD's "unsafe" language. (Any resemblance to actual real-world languages named C, living or dead, is purely coincidental.) The only one of these languages that is sound is L, of course. But there is some quality closely related to soundness by which there's an obvious partial ordering where L > LD > D, L > LC > C, LD > LC, and D > C, and if someone describes this situation by saying that LD is "sounder" than C then I don't see any reason why we should stop them. Similarly: a federal state is either a "perfect union" or not, for any reasonable definition of "perfect", but it's reasonable for the US constitution to aim at a "more perfect union". A thing is either "unique" or not, but despite the cries of pedants it's reasonable to describe a limited-edition Ferrari of which only two were ever made as "almost unique" and as "more unique" than a standard-issue Ford Fiesta. A given region of space is either "vacuum" or not, but most of the things we describe as "vacuum" actually contain some very rarefied gas and it's common to use terms like "high vacuum" to quantify how vacuum-like a "vacuum" is.
• vanusa 7y ago
  The main problem with TypeScript is that at the end of the day -- you're still using JS. Which outside of its natural realm of application (i.e. the browser) is a highly questionable value proposition. "A bandaid over a machine-gun wound" is what we might call it.
• jefflombardjr 7y ago
  Eric Elliot does a great analysis on this: https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff...
  • preommr 7y ago
    side note: but what the hell is hashicorp configuration language (HCL)? It's apparently the second fastest growing language based on whatever metric the chart is using and I've never heard of it.
    • mmorris 7y ago
      It's used with Terraform, amongst other things. So you might not have heard of it if you're not doing devops/infrastructure work.
• sethc2 7y ago
  IMO, Yes (usually). Let me elaborate. If you are starting a new project, yes use typescript over JS. And configure it with all strict options. This doesn't magically give you well architected and well-tested code, it still takes a good engineer to do that. But what it does allow is for the engineer to refactor the code to support new functionality with more speed and confidence, rather than shoehorning it in in fear of breaking something or it taking too long. Furthermore, as people join your team, it will be a lot easier for them to figure out where some piece of data is coming from and how the code flows from one spot to the next. If you have a massive JS project and you want to convert it to typescript. The answer might be no. Oftentimes when people port a JS project to TS, they end up using non strict typescript, and you get the syntactic overhead of writing TS, without really any benefit because nearly everything is any typed. If your only concern is a better codebase, and it doesn't matter how long it takes, then sure it is worth it, but we all know that is never our only concern. It still might be worth it, but I can almost guarantee you from experience, you will still end up with TypeErrors in your console at some point, because people will have just any typed things. Also if you're writing a tiny node script in a single file, to do some simple operation, then no it is probably not worth setting up a command to compile it and a tsconfig to configure it. Unless it is doing multiple things, and/or someone else in the future will have to use it, then it is probably still worth it.
  • sethc2 7y ago
    Oh one other potential drawback. Typescripts inferred types, can do some crazy things, and can be very powerful. This to me is really fun, but has definitely caused me when I first started using it to get lost in having fun doing crazy things, to ensure my strings were exactly some set of values depending on what some other value was, when a simple unit test and a simple "string" type, would've been a lot quicker and less confusing.
    • samhh 7y ago
      If the strings are static you can define a type that's a union of string literals, create a tuple containing them all, and then a type guard function that simply checks the argument against the array. If the strings are dynamic then you're better off looking at a library like newtype-ts, but it's not very ergonomic compared to the likes of Haskell/PureScript so use sparingly.
• dynamite-ready 7y ago
  I won't lie. I read the title, and thought "At last, objectivity". It's like CoffeeScript all over again. Except this time, this particular assault on ECMAScript is much better funded. Don't get me wrong, I think there's a place for strong typing in web based UIs. But for one, WASM is a better idea for the choices and flexibility it offers, and more importantly to me, I think the bigger challenges in UI programming are not solved by strict typing.
• vemv 7y ago
  I don't think pointing out deliberate design decisions is a valid criticism. It's like criticising a chair for not being a beachball. Folks seeking a Haskell-like type system in javascript certainly have options.
• typescriptfan1 7y ago
  It's interesting that someone who is primarily using JavaScript in the backend is criticizing TypeScript's type system. There is a simple reason why TypeScript's type system is how it is... TypeScript is additive which works well in practice.
• _bxg1 7y ago
  > ...there is an argument that states that the adoption of TypeScript would not have been as high if a sound type system is 100% guaranteed. This is disproved as the dart language is finally gaining popularity as Flutter is now widely used. In my experience TypeScript's unsoundness is a feature, not a bug. You cannot compare it to languages that were designed from the ground up to be sound. JavaScript was fundamentally not designed to be used in a 100% sound way, and trying to do so introduces an enormous developer burden in terms of idioms and language features that you can't use, and syntactic hoops you have to jump through. You find yourself constantly fighting against the language. I know this because at my company we started with Flow, which is (very proudly) sound. It was impossible to be productive. For a small example, every reference to document.body had to have a null-check, even though we could guarantee by where we placed our <script> tags that the body would never ever be undefined. The experience was rife with situations like this, which created tons of cruft and made code harder to read. "any" is nearly always bad. But the other escape hatches, like casting, have proven essential to building a reasonable codebase that doesn't try to ignore the reality of JavaScript. > Runtime type checking would be beneficial when dealing with JSON payloads returned from API calls, for example. This I agree with, but I don't think it belongs in the core TypeScript project. We used Flow Runtime with Flow (https://gajus.github.io/flow-runtime/ https://gajus.github.io/flow-runtime/) which creates runtime assertions automatically based on your static types, on a file-by-file basis. It was wonderful, and is the only thing I miss about Flow, although it was a third-party project and there's no reason something similar couldn't be made for TypeScript. I would be giddy to hear that someone was building one.
• agumonkey 7y ago
  I had this question since I tried rewriting some big-todo app in TS. Do people try to write a core in simple (sound) types and then have an outer shell of IO/frail typechecks around ?
• tekkk 7y ago
  TypeScript is great as long your business logic and typings stay simple. When you start doing some weird generics where K extends T and some library interface you'll be wasting your time on things that are quite unnecessary in the end. It would definitely be nice to have types inferred magically but at times you just have to take a shortcut and leave the type masturbation for some other day. Yet if you follow this rule of keeping type complexity at minimum you have a great amount of space to do rapid and enjoyable development. I'm more of a pragmatist vs theorist so for me, TS has been amazing mix between the dynamicity of JS and type-safety of Java. Some day sure, if a better language comes along I'll hop on but at the moment there simply is too great benefits sticking with TS instead of some other, fancier languages. Sometimes the grass just isn't that much greener on the other side to justify spending considerable time on a new language and its toolings.
• city41 7y ago
  Most npm modules are written in JavaScript and when it comes to types they are handwritten (if they exist at all). The very nature of this makes TS unsound, as you have to count on the types being written correctly. I've encountered incorrect types many times. Even worse, when the types ship inside the module and are incorrect, it's difficult to correct them. I prefer JS modules to have a separate @types module.
• VyperCard 7y ago
  I stopped reading after the first sentence.
• dynamite-ready 7y ago
  I've got a tangential question, and I think it's worth asking here. With the precision ML requires, why aren't data scientists rushing from Python, to a language with a stronger type system?
  • mattnewton 7y ago
    Most machine learning doesn't work the first time and required rapid iteration outside of your production system in my experience. Then, when you finally get a model, you can put those weights into your stable production system that has all the automated testing and is written in a typed language.
• Androider 7y ago
  The type of problem that TypeScript solves is not the type of problem that I have. In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types. I could count the number of times types has been problem on one hand. Instead, almost all issues are due to logic errors and missing or poorly understood business requirements. For me, the time spent resolving TypeScript specific issues (missing type definitions, lack of support in third party libraries, general finickiness etc.) does not make it a worthwhile investment. I also did Scala for several years professionally, and while it instils rigor, I feel much the same that the price you pay isn't remotely worth the benefit you get. Conversely, I think one of the best investments you can possible make into tooling is to reduce the edit-compile-view cycle time, and you should aim for seconds at the most if not instantaneous updates. That speed of iteration will pay dividends.
  • Allower 7y ago
    You don't refactor your code? Fix bugs months after development? I suppose you aren't the target audience..
    • arvinsim 7y ago
      There are a lot of projects that are just deliver-and-forget.
  • ng12 7y ago
    I thought the same but the more I use TypeScript the less I care about it's typechecker. I use it mostly for the amazingly powerful IDE integration and so I don't have to remember if a `User` has an `id` or a `userId`.
    • superfamicom 7y ago
      I've noticed VSCode at least also learns types and structures from JSDoc in raw / vanilla JavaScript.
      • 7y ago
• Allower 7y ago
  >I still have to write just as many tests, and I find this frustrating. When I first started getting TypeScript, I wrongly concluded that I could stop the drudgery of writing so many unit tests. Well there's your problem... If you were a C# dev you would be laughed out of a job.
• lets-surf 7y ago
  This example from the article looks like an argument for immutability to me. interface A { x: number; } let a: A = {x: 3} let b: {x: number | string} = a; b.x = "unsound"; let x: number = a.x; // unsound a.x.toFixed(0); // WTF is it?
  • SpaceNugget 7y ago
    Kind of, you can't have your cake and eat it too. When it comes to typing systems you have to pick 2: Depth, Mutability, Soundness
• proc0 7y ago
  The soundness of the type system is not a valid criticism given that it's aiming at improving a language that had almost no type system at all. If you need more from your types then perhaps TS or JS is not the right choice here.
• stared 7y ago
  There is quite a lot missing in TypeScript types (e.g. integer or uint types would help a lot in typical tasks such as accessing an array or iterating a loop; even if they are stored as floats, I want to make sure someone won't take 2.5 element of a list to get undefined). Still, for me, TS is a day and night difference with JavaScript. While it does not solve everything, at least I know what is code about. E.g. when I see `volume` in plain JS the first question I ask myself is: is it a number, plain object, instance of a class, a simple boolean, or what? It is not only about tests. It is also about readability.
• Rapzid 7y ago
  Interesting.. The biggest drawback I've experienced with TypeScript has been the complaining.
• no_wizard 7y ago
  My take away from this: If you don't have the discipline on your team to enforce good structural standards for your code, TypeScript may not help as much as you think. In my very much opinionated opinion, all the issues highlighted in this article, are avoidable with: 1. Don't use the `any` type (I'm actually pretty shocked this article doesn't talk about using `unknown` instead of `any`. I have found `unknown` can be used where `any` tends to be used, most of the time, if not all the time, and it comes with the benefits of things like assertion control & tsc's type interference (it acts almost as a marker, in some ways, basically, for the type that gets fed through. It also forces you to think about validating the input) 2. Enforcement of strict options for the compiler A non-goal to me is using TypeScript to avoid writing tests. This should never be someone's idea in adopting any typed language. I think this is a smell of a bigger problem. Types or no types, it does not influence why or how many tests I write, as testing is about validating your programs ability to handle its inputs & the correctness of its outputs (your testing algorithms, at the end of the day), so I do not see how this factors testing at all. Types also do not negate the fact you need to do validation (beyond perhaps, trivial validation of arguments at the call site, if your codebase is actually following good structural patterns) Is TypeScript perfect? No. Should you use it? I think you should probably make that decision after a careful reading of the documentation & discussing it with your team. Do I personally think this article has a strong case against TypeScript? No, as its (to me) very trivial to avoid any of these problems. You know what would likely be more effective with most code bases I've seen though? Good documentation & comments, with explanations of what things do if it isn't obvious enough to pick up in a second or less glance. Preferably following the JSDoc standard.
  • frenchyatwork 7y ago
    > Don't use the `any` type The problem here is two-fold: 1. Culture and existing code. Popular libraries use any when they should be using unknown or just not de-serializing stuff and making you explicity parse it yourself. The reason why these are popular is because culture and because of #2. 2. Creating type guards is a pain, especially if you're trying to go from unknown to something with a complex structure. If types were something you could reflect on in run time, like most other interpreted languages, this would be a lot easier.
• deckard1 7y ago
  Ignoring the tech side for a minute, my major problem with TypeScript is that TS proponents assume that the static vs. dynamic debate has been settled. That the future is static typing, and that people have to be crazy for wanting to do dynamic typing in a dynamically typed language. A great many developers have found themselves having to write JavaScript because that's where they got pigeonholed. Then, because they'd rather be doing Haskell, Java, or whatever, they bring that crap to JS and enforce it on developers that possibly liked doing regular JS. Type inference is older than I am. Yet you would think this is some new technology. When in reality, we could have had it on Ruby. On Python. On Perl. And on Lisp. Decades ago. It's not new and it's not special. But it certainly has a lot of undeserved hype at the moment. There is no conclusive proof static typing reduces bugs. This is some weird myth that keeps circulating. The trend pendulum will continue swinging though. TS won't be immune.
  • thawaway1837 7y ago
    I don’t see how you can claim that TS believes the static vs dynamic debate is settled when TS already includes, and continues to add features that enable and make it easier to dynamically type stuff (for example, unknown is a fairly recent addition). In reality, the reason TS has been so successful, and likely will continue to be so successful (until they screw up the execution, or forget what made the language so successful) is thst TS is an entirely pragmatic language. It uses theory not to decide its roadmap, but rather, uses actual problems and needs faced by JS developers to decide the roadmap, and then uses type theory and other CS concepts to solve those problems. For example, the reason TS uses Types is not because a group in MS decided that static typing is better than dynamic typing, and what JS really needs is a layer of types above it (that was coffeescript...). Typescript was created because MS wanted to make better IDEs and tooling for JS (specifically, they wanted to bring Intellisense which is a huge VS selling and marketing point, to JS) and they realised they couldn’t do that without adding type information to JS. Hence, a practical need drove the decision to create TS.
    • jammygit 7y ago
      IDEs aren’t that necessary if you have strong command line skills. The only ide feature I really miss is autocomplete because it’s a pain to remember method names
• deleted 7y ago
  [deleted]
• luord 7y ago
  "Is Typescript worth it?" No, but not because the tired diatribe on typing, but because JavaScript nowadays is mostly good enough... As long as we remember what its goal is and we don't use it for anything more than its intended purpose. That aside, everything in that post re soundness vs unsoundness was what I used to know (and was taught in college) as "strong" and "weak" typing, is the redefinition recent? Was I taught incorrectly? That aside, C is weakly typed (and there are long, long discussions on it) but I'll say that, if it's good enough for C, then being for or against it becomes pretty much subjective (obligatory IMO, my saying that at all is also subjective). After all, it's a flamewar that's been going on for decades. Typescript certainly isn't going to solve it.
  • tel 7y ago
    Sound and unsound aren’t the same as strong and weak. Weak and strong systems aren’t honestly very well defined, but under many definitions can be both sound and unsound, though the theory of the weak system will need to have explicit inclusion of the implicit casts (e.g.). Type systems become unsound when they, as a total system, cannot uphold their own promises. The promises of a weak system are weaker, but not (always) non-existent. In an unsound system you can generally, through trickery, take any expression reducing to a value of some type and modify it so that it appears to reduce to any other type at whim.
    • luord 7y ago
      > Weak and strong systems aren’t honestly very well defined I see, but at least the literature I read on typing actually mentioned them. Nothing I read in college regarding type systems ever included the words "sound" or "unsound". > some type and modify it so that it appears to reduce to any other type at whim. I saw instances of this as examples of "weak" typing. Do you happen to have papers or books you could recommend so that I can learn more on type system soundness? This is a subject that I find really interesting.
      • TheDong 7y ago
        How were weak and strong defined in the literature you read? Anyway, more on soundness. I can recommend a couple papers: Wadler (inventor of the monad) wrote a paper called "Well-Typed Programs Can’t Be Blamed" [0] about soundness. There was a recent paper that made the rounds about how java's type-system is provably unsound as well that's worth reading [1]. I second the parent comment that weak and strong are ill-defined in my experience, while sound/unsound have well-accepted definitions and are commonly used in academia. Your experience obviously differs for whatever reason. You can find many other references to soundness in the citations of those papers, as well as scattered around the internet. [0]: https://link.springer.com/chapter/10.1007%2F978-3-642-00590-9_1 https://link.springer.com/chapter/10.1007%2F978-3-642-00590-... [1]: https://dl.acm.org/doi/10.1145/2983990.2984004 https://dl.acm.org/doi/10.1145/2983990.2984004
• mattwad 7y ago
  I might get downvoted, but I believe that using "strict" mode is not worth it precisely for the reasons this article talks about. You get at least 90% of the benefit of Typescript (IDE support, typos, refactoring, etc) without --noImplicitAny and other flags that induce a lot of boilerplate and wasted time. After all, how confident can anyone be that DefinitelyTyped types are correct? I use types when I find them useful. I also enjoy being able to not use types when I don't need them, which is why I choose to use Javascript.
• achou 7y ago
  In type systems there's a tension between expressiveness, soundness, and comprehensibility. A sound type system must exclude all programs that have runtime issues, and, holding that constant, try its best to maximize expressiveness and comprehensibility of the programs that can be written. But what about programs that can run fine but are excluded by the type system? They are censored. This is what's less visible until you actually try to build something substantial, pushing the boundaries of expression, performance, or scale. Then you'll find that a sound type system can become more and more of a straight-jacket. One that forces you to write code in ways that are limited by what its type designers could envision expressing (or could prove that was safe to express). The trouble is that it's hard to know when you might reach the point where the type system begins to limit you. It might never happen, as you frolick happily within the walled garden. Or it might happen when you write your first line of code. In a large system that must deal with external requirements, it's something that in my experience becomes inevitable. That's not even touching upon comprehensibility, which becomes an increasing challenge for purely sound type systems as they attempt to increase expressiveness. The biggest innovation of TypeScript is JavaScript. That is, TypeScript started with a huge established corpus of JavaScript that showed what developers wanted to express and how they wanted to express it. And, crucially, how popular various kinds of expression actually were in the developer community. This forced TypeScript to take practical expressiveness of millions of lines of JS seriously, that ordinarily would have been censored by type system design before the first line of code was written. That's why it's entirely unfair to harp on TypeScript's unsoundness, without also exploring the corresponding gain in expressiveness and comprehensibility relative to other type systems. BTW, this line of reasoning is the reason so many "sound" type systems also have their equivalent of "any": Rust has unsafe[1]. C# has unsafe[2]. Flow has any[3]. And all practical languages have strings, which are kind of a lowest common denominator when it comes to dealing with a type system that simply can't express what you need. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/unsafe https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... [3]: https://flow.org/en/docs/types/any/ https://flow.org/en/docs/types/any/
• unjte 7y ago
  I don't like TypeScript at all. I used to write c# and javascript all day. Every time I had to write javascript, it was much more enjoyable than writing the c#. I would often have to create classes purely because the language required them. All of these classes all over the place with no methods in them at all. A whole bunch of typing all over the place that I could tell I was never even mentally parsing, but still having to type and see on the screen. Then I started working on my own and decided to use Node a lot in the situations where I would have to use c# at my previous job. There were no more bugs, no problems with refactoring, and it was much more enjoyable than writing c#. Now this TypeScript is infecting javascript, and all the jobs and so on require "typescript" instead of javascript. It puts all the things I didn't like about c# back into javascript. People will make all kinds of ridiculous claims that it is irresponsible not to use TypeScript, and that it improves productivity and so on. None of these claims are true and don't get to the real reason that TypeScript exists. Most well-structured programs aren't one giant function that is hard to refactor. They are usually a series of isolated, small functions. There is even a trend towards "microservices" and function as a service and so on. These are things that reduce the claimed reasons for TypeScript, rather than increase it. Many times I see the reason for using TypeScript being "it is good for large teams". Yet still, I see it used in teams of 3 people all the time. The real reason TypeScript is used is because there are a very large number of programmers now, which means the quality of the average programmers is much lower than it has ever been. Many people who program often just copy and paste code from stack overflow. Many of these people were the same people who looked in fear at JavaScript, and couldn't even understand it because it wasn't the one language that they knew. TypeScript gives these people more safety, feedback, and familiarity to be able to do their job. That is fine, but lets not pretend it is anything else.
• leshow 7y ago
  > the adoption of TypeScript would not have been as high if a sound type system is 100% guaranteed. This is disproved as the dart language is finally gaining popularity as Flutter is now widely used. Soundness is a goal of the dart language which is discussed here. Look, I wish TS type system was sound too, but that's not a "proof", it's just a data point. TS doesn't have the same goals as Dart, there are lots of variables which aren't the same, so you can't just take Dart's approach and say "look I proved it". There are lots of popular languages with unsound type systems; Java for example. I don't know how you could have a criticism of TS without mentioning the lack of sum types. Yes, you can fake it by having an object with the same field name differentiated by a string constant, it's still not as nice as having first class support for sum types.
• ptcampbell 7y ago
  LogRocket deserve some praise for doing the company blog right. Good, self hosted content (no Medium) and well written pieces on technology from a practical everyday perspective. I am not a customer, by the way.
• akdor1154 7y ago
  A bunch of the issues here are due to the author actually casting instead of letting inference do its job. // unsound, val.toFixed(0) compiles let val: number = ("string" as string | number) vs. // sound, val.toFixed(0) does not compile let val = ("string" as string | number) // sound In general, it's unnecessary (and as demonstrated, potentially harmful) to annotate assignments like these.
  • TheDong 7y ago
    Their example without `: number` still exhibits the exact same behaviour. The `: number` isn't a cast either, it's declaring the type of the variable. You can't help but explicitly name the type of a variable in many cases. What if they were passing val to a function as an argument? You can't have 'function foo(x)', you have to have 'function foo(x: number)' and name the type. So yes, their example is contrived, but no, what you said is not sound. It has the same problem as the one the author mentions. The typescript compiler intentionally does not catch their issue. If I'm misunderstanding what you're trying to demonstrate, please make a typescript playground of it.
• jammygit 7y ago
  I think I’m alone in this, but JavaScript is a neat language that is incredibly powerful and expressive (minus a few warts). Most of the problems that arise from it seem to come from undisciplined work habits and a lack of code review. As long as your team is smart enough to not call all your function arguments “args” or “data” or “params”, the asynchronous flows are really nice. IMO at least
• jillesvangurp 7y ago
  I've done some programming with typescript. IMHO the reason for around 50% of the javascript world now using it is that it provides substantial improvements over javascript that are real. Personally, I insist on typescript on any node.js or frontend javascript codebase these days. Yes, it's not perfect. And, yes the inherent problems of javascript still leak through in many places. But with a little configuration, you can make the static code analyzer and compiler help you avoid most of that. IMHO the amount of verbosity it adds is negligible. I actually measured a slight decrease in LOC when I was converting code. You add some type annotations (which IMHO also help human code readers) but then you also get access to syntactic sugar to offset that. It's a fair compromise considering that most tools trying to help the developer have more to go on and basically work much better. Ballpark your number of LOC is not going to grow when switching to typescript. But IMHO it's just a gateway drug for developers to find their way to more capable languages. Personally, I'm interested in the direction that Jetbrains is taking with Kotlin-js, which with the next version will have some nice tooling around it to leverage typescript type definitions for integrating npms and hides most of the build tool madness behind gradle. The kotlin compiler has a much more sound/strict typesystem than typescript and also the language has quite a few language features that the typescript developers have not gotten around to supporting yet (they've been making progress catching up with recent releases though). They are also addressing size of the minified code. With the recent improvements, hello world is now a lot more reasonable than it used to be (<80kb instead of ~1MB). It eliminated unused code more effectively. If you feel brave, you can get started with this on a modern react project right away. Most of the dependencies you'd use for that should just work fine with kotlin-js. But realistically it's probably going to take another few years to stabilize. IMHO Kotlin is interesting because it is already widely used by frontend developers on Android and has a lively ecosystem of frameworks that might also make sense in a browser. Also co-routines are nicer than async await in typescript. And of course WASM is opening up this space further to just about any language. So for people finding themselves a taste for more/better typing, there will be plenty of alternatives for typescript.
• jiofih 7y ago
  I don’t know how these people are using TS, but I’ve been part of a major project for over a year and we’ve had zero runtime issues, using all kinds of libraries in both nodejs and the browser. But for our standards, that object assignment in the example is a big no-no, TS or no TS.
• craftoman 7y ago
  This article is wrong from many aspects. There are things that many developers can't get with Typescript and it's flexibility...just always keep in mind what makes Typescript so special compared to any other languages. You can't achieve both flexibility and typed solid programming in the same place, you must sacrifice the things you just mentioned and few others. Typescript was supposed to be flexible and developer friendly, it's not a hardcore language and never will be.
• nationsobviou 7y ago
  – Is TypeScript worth it? Yes.
• wildpeaks 7y ago
  It's worth it because it catches a lot of low-hanging bugs at a small cost, and it's well maintained and has great tools support. Plus you can even use it like a simple linter if you want to continue writing vanilla Javascript (it catches less, but still catches a lot).
• techsin101 7y ago
  Change my mind but if you are using VScode you're getting 90% of the benefits without having to take the cost of writing types.