10 ms·

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a ty

• winter_blue 2y ago
  Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.
  • mattnewton 2y ago
    Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code).
    • LoganDark 2y ago
      Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?
      • mdhb 2y ago
        The compiler itself lives on but it works with TypeScript now rather than the JSDoc comments style approach which is officially EOL AFAIK.
      • flohofwoe 2y ago
        Closure is still used in Emscripten to optimize the generated Javascript shim file.
      • rty32 2y ago
        This can give you some hints of the current status of closure compiler: https://github.com/google/closure-compiler/issues/2731 https://github.com/google/closure-compiler/issues/2731 I happen to know this because we have some old projects that depend on this and are working hard to get rid of the dependency. I wish Google either updates it or just mark the whole thing deprecated -- the world has already moved on anyway. Relating this to Google's recent cost cutting, and seeing some other Google's open source projects more or less getting abandoned, I have to say that today's Google is definitely not the same company from two decades ago.
    • miki123211 2y ago
      Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[function]()` is perfectly valid JS, where the value of `function` might come from the user. A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Because Closure was a type checker and a minifier at the same time, it could minify the properties declared as private, while leaving the public ones intact.
      • wiktor-k 2y ago
        > Something like `foo.bar[function]()` is perfectly valid JS, A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".
        • mkesper 2y ago
          Oh boy, just think functionName and it fits.
      • mananaysiempre 2y ago
        > A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.
        • afavour 2y ago
          Theoretically TS could… until it encounters an ‘any’ type in that code path, then it would have to give up. But there are TSconfig options to ensure no use of any so with the right level of strictness it could happen.
        • epolanski 2y ago
          What do you mean by unsound exactly. I'm asking because there's no accepted definition of what an unsound type system is. What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.
    • btown 2y ago
      Google’s Closure Library is fascinating too. It’s being retired, but if you want to build a rich text interface for email authoring that truly feels like Gmail, warts and all, you can just use a pre-compiled version of the library and follow https://github.com/google/closure-library/blob/master/closure/goog/demos/editor/editor.html https://github.com/google/closure-library/blob/master/closur... within a more modern codebase!
    • rty32 2y ago
      Closure is almost a forgotten child of Google now. Does not even fully support ES2022 as of today. We are working hard to get rid of it completely. Surprise, lots of important projects still rely on it today.
      • jazzypants 2y ago
        This is true. For instance, React still uses Closure compiler in their build process.
  • simplify 2y ago
    Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.
    • sesm 2y ago
      Because Flow is an actual developer tool, not a rent-seeking landgrab with a marketing budget.
      • 9dev 2y ago
        I don’t know what axe you have to grind, but TypeScript is firmly in the hands of the community now. There’s not much Microsoft could do to change that. In what way would it be rent-seeking?
      • recursive 2y ago
        If you're paying rent for typescript, you're doing it wrong.
  • hajile 2y ago
    Flow tries to be sound and that makes it infinitely better than TS where the creators openly threw the idea of soundness out the window from the very beginning.
    • machiaweliczny 2y ago
      But in practice is was crap
    • draw_down 2y ago
      Maybe FB should have tried putting more than like 4 people on the project then. (Yes I met them all once.)
    • ahuth 2y ago
      TS made the choice to be “just JS” + types, and lean into JS-isms. Both choices are reasonable ones to make. Flow has some really cool stuff, and works great for a lot of people. There’s no denying, though, that there’s TS has done something right (even if you personally dislike it)
    • idlephysicist 2y ago
      Can you explain what you mean when you say "to be sound"?
      • pansa2 2y ago
        Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695 https://news.ycombinator.com/item?id=41069695
        • recursive 2y ago
          You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.
  • sesm 2y ago
    There was no real competition, Flow was a practical internal tool with 0 marketing budget. Typescript is typical MS 3E strategy with a huge budget. Needless to say, Flow is much more practical and less intrusive, but marketing budget captured all the newbie devs.
    • ignoramous 2y ago
      > There was no real competition There was: Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM (2013). Summary: https://g.co/gemini/share/a60c3897bae1 https://g.co/gemini/share/a60c3897bae1 / https://archive.is/qJ1wA https://archive.is/qJ1wA
    • com2kid 2y ago
      TypeScript was really really easy to get started with back in the day. It allows for incremental correctness, has good docs, and good tooling. On top of that a lot of beginner React tutorials started out with TypeScript, which onboarded a lot of new engineers to the TS ecosystem, and got them used to the niceties of TS (e.g. import syntax).
    • treflop 2y ago
      Have to disagree. I tried Flow irrespective of marketing and didn’t think it was polished. Kept running into type situations that the language didn’t support well. Kept bugging out in my IDE. Had no elegance.
      • spoiler 2y ago
        When I last used it, as a type system it was much better than TypeScript. A lot of flow features now exist in TypeScript though too. One big annoyance with Flow I had is like you said: unpolished tooling. Another was frequent breaking changes (I don't hold it against them too much, it was 0.x software after all) Also because features diverged, you had to maintain type defs for multiple versions of flow for for multiple library versions. And then at one point, they also decided to convert internal errors to any types instead of displaying the error. That was the last straw for me, especially since I maintained a few flow type defs. I spent _so_ much of _my_ time just on type def maintenance for open source libraries already, with the any decay I like flying blind too. So I just switched to TS with its interior type system: it was good enough and others maintained library typedefs for me. But now the type systems are much more closely aligned (unless flow drifted), so switching to TS paid off in the end.
• pphysch 2y ago
  > In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.
  • josephg 2y ago
    You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.
    • jaggederest 2y ago
      Yeah I start projects by explicitly typing `any` all over the place and gradually refining things, so every type that's specified is explicit and checked, I'm really enjoying that style.
      • crabmusket 2y ago
        Combine this with an eslint config that nudges you about explicit any, and the typescript compiler option to disallow implicit any, and you're well taken care of.
    • pansa2 2y ago
      > Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type hints much of a problem in practice?
      • 2y ago
• phartenfeller 2y ago
  There is an EcmaScript proposal to go in that direction: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations I think this should be part of the language spec.
  • wiseowise 2y ago
    Beyond ugly. They should just make TS official and be done with it. E: I thought it was JSDoc proposal. Ignore the comment.
    • blovescoffee 2y ago
      I did only briefly look at the proposal. What did you find so ugly?
      • wiseowise 2y ago
        I misread the proposal. Thought it was for JSDoc.
        • meiraleal 2y ago
          Misread no, you didn't read.
          • wiseowise 2y ago
            Yeah. I saw JSDoc and closed it, lol.
            • Dylan16807 2y ago
              Specifically, you saw the section titled "Limits of JSDoc Type Annotations"?
              • wiseowise 2y ago
• Doxin 2y ago
  > In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments. Note that there's IDEs that'll use type hints to improve autocomplete and the like too, so even when not checking types it can make sense to add them in some places.
• dobladov 2y ago
  You can have this now adding types with JSDoc and validating them with typescript without compiling, you get faster builds and code that works everywhere without magic or need to strip anything else than comments. The biggest pain point of using JSDoc at least for me was the import syntax, this has changed since Typescript 5.5, and it's now not an issue anymore.
  • murmansk 2y ago
    [flagged]
    • adhamsalama 2y ago
      You can write TypeScript types in JSDoc.
      • sureIy 2y ago
        You can’t write complex TypeScript types in JSDoc, which is what GP said. The moment you need to declare or extend a type you’re done, you have to do so in a separate .ts file. It would be possible to do so and import it in JSDoc, but as mentioned before it’s a huge PITA on top of the PITA that writing types can already be (e.g. function/callbacks/generics)
    • dobladov 2y ago
      You should write complex types in interfaces files where they belong, and there's full typescript support. I use this approach professionally in teams with many developers, and it works better for us than native TS. Honestly give it a try, I was skeptical at first.
      • rty32 2y ago
        In general JSDoc is just much more verbose and has more friction, even outside complex types. I recently finished a small (20 files/3000 lines), strictly typed JS project using full JSDoc, and I really miss the experience of using the real TypeScript syntax. Pain points: annotating function parameter types (especially anonymous function), intermediate variable type and automatic type-only import, these are the ones that I can remember. Yes you can get 99% there with JSDoc and .d.ts files, but that's painful.
• black3r 2y ago
  > If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript Node.JS isn't the only JS runtime. You'll still have to compile TS to JS for browsers until all the browsers can run TS directly. Although some bundlers already do that by using a non-official compiler, like SWC (the one Node's trying out for this feature). > In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments. It's not just comments. It's also, like the name "type hint" suggests, a hint for your IDE to display better autocomplete options.
  • pansa2 2y ago
    > It's not just comments. It's also a hint for your IDE to display better autocomplete options. Ah yes, autocomplete is another benefit of machine-readable type hints. OTOH there's an argument that another IDE feature, informational pop-ups, would be better if they paid more attention to comments and less to type hints: https://discuss.python.org/t/a-more-useful-and-less-divisive-future-for-typing/34225/32 https://discuss.python.org/t/a-more-useful-and-less-divisive...
• schwartzworld 2y ago
  Incidentally, this is how the ecmascript proposal for introducing types to JS would work by default. The runtime would ignore the types when running code. If you want type checking, you’d have to reach for external tooling.