1. 29
  1.  

  2. 11

    I feel like this article could be tightened up to present its argument more persuasively (tldr: tsx — React plus TypeScript — files are type-checked, whereas other common templating formats, even Angular 2’s, which professes a deep integration with TypeScript, are not), but I still thought it was great, particularly the animations.

    After experiencing some disappointment with Angular 2 on a previous project, I’ve been working with React plus TypeScript recently and it is worlds better having your “templates” participating in type-checking. It’s actually the thing you want, in my opinion.

    1. 7

      Thank you for the feedback. I added a tldr to the top.

      1. 4

        even Angular 2’s, which professes a deep integration with TypeScript, are not)

        I believe that this is outdated as of today (literally), thanks to TS 2.3’s language service plugin API which Angular now hooks into.

        1. 11

          No kidding! I didn’t realize. Well, that’s pretty interesting.

          In retrospect my original comment fell victim to the classic error: never assume that Angular 2 doesn’t contain a feature unless you have re-confirmed within the last 24 hours that it still does not contain that feature.

          1. 3

            Wow. I’d love to be able to update this article with some animations that show inline editor errors in Angular templates.

            edit: aaannd there’s the vscode plugin https://marketplace.visualstudio.com/items?itemName=Angular.ng-template

            1. 2

              And here’s a full talk from ng-conf going over the language service: https://www.youtube.com/watch?v=ez3R0Gi4z5A

        2. 7

          I’ll speculate that many developers think TypeScript adds rigidity to your code. I think it’s the opposite - JavaScript code is more rigid, and TypeScript more fluid, because it’s so easy, quick, and safe to refactor TypeScript.

          I thought that was an interesting insight. It matches up with my experience working on large JS and TS codebases. The JS is much more static over time because you’re less sure of the implicit dependencies between parts of the system.

          1. 3

            Typechecking the entire stack is a very powerful concept. Richard Feldman and the Elm community are at it too, e.g. elm-css is trying to capture the syntax of valid CSS in the type system so that you literally can’t compile invalid CSS in Elm. As we find ways to move more and more declarative components into the type system, the future looks bright for language which have great tooling support for easy autocompletion, jump to definition, and the other features you describe.