4 ms·

Seems like a pretty small release in comparison to previous updates. Probably a good thing, though - it demonstrates that the language as reached a very mature

Seems like a pretty small release in comparison to previous updates. Probably a good thing, though - it demonstrates that the language as reached a very mature state with few remaining gaps.

pjmlp 8y ago
Now it just needs to become the official JavaScript's strong mode. :)
- daveidol 8y ago
  Seriously: this language is amazing. I have to admit I was a holdout for a while, but TS has been fantastic to work with compared to Flow
  - k__ 8y ago
    Good to know. I dad the impression Flow was the better approach, but using it wasn't nice.
    - WorldMaker 8y ago
      For a brief period Flow had more type algebra (type unions and intersections) and better inferencing, but Typescript has greatly shrunk the gap between type system capabilities where the differences are much fewer, and rarely anything that matters for most projects. Flow was popular for the ability to put all of its type annotations in JS comments and not need a transpilation pass. Typescript also added a mode that supports that. Flow was popular for the slipstream integration into Babel as the type-stripper was just an "ordinary" Babel plugin. Typescript now supports this as well. So for the most part a lot of the old impressions that Flow was the better approach are out-of-date, and par-for-par Typescript is an equal approach (if not a better approach, depending on your preferences/needs, and due to things like the fact that there are vastly more Typescript type definitions than Flow definitions in the npm wilds now).
      - k__ 8y ago
        Ah. Yes, I read about how TypeScript is a more classical approach, and Flow would use "flow based" typing or something, which was a more modern approach. Also, it came out of the box with non-nullable types. While I had the impression the TypeScript language designers didn't deem these features to be important, they added them anyway.
        WorldMaker 8y ago
        I don't think it was ever a matter of "not-important", Typescript and Flow started from two different perspectives and took different routes to get to what today is a somewhat more converged place. Overall, I also don't think it's "modern" versus "classical" that much. In terms of the different philosophies it's "language" versus "linter" / "compiler" versus "observer", and there is a huge spectrum of options there. Typescript starting from a place of prioritizing "green field" development at first, where teams had the option to start fresh or similar. Like CoffeeScript or Dart, it wanted to provide a good way to organize and develop new code. (Unlike CoffeeScript or Dart, the "pure superset" approach still provided easier migration; I worked on several projects where conversion was simply rename .js to .ts and then fix compiler warnings until it worked again.) Taking the compiler approach also provided an early focus on providing some transformations to the code. In Typescript projects I typically don't feel a need for Babel, because Typescript handles everything I want in terms of "downlevel" transforms to support the version of JS in browsers. Flow starting from a place where you've got a huge line of code investment into an existing codebase, can't "stop the world" to migrate and absolutely need to start "linter style" evaluating data types. Over time Flow has picked up more reasons to use a cleaner syntax for type annotations than what just comments alone can deliver, driving more Flow projects to adopt Babel transforms for that (in addition to whatever other Babel transforms a project wants). Over time Typescript has wanted to get better at migrating existing JS code. The team proved the language worked great for greenfield projects, and got a lot of interest from customers internally and externally to extend that make it a lot easier to do grayfield work. Also, Typescript found its "pure superset" proved better than expected at evaluating almost all JS. This pushed Typescript to power more and more IDE intelligence features for both JS and TS (in an increasing number of IDEs, beyond even the Visual Studio family). That in turn pushed more JS mode features and support in the language, and increasingly better type inferencing and flow control analysis especially when working in large forests of untyped JS. As for the typing systems themselves, "modern" versus "classical" almost is descriptive, from a certain point of view, modulo the fact that both typing systems are "ancient". Typescript started from a type system that started out seeming more in common with the C++/C#/Java family of "Object Oriented" typing systems, whereas Flow started from a place of being much more directly inspired by the "functional" ML family of type systems. (Though calling this more "modern" than the ALGOL-style "OO" type systems belies the fact that the ML family dates to the 70s and about all of our type systems have equally ancient roots; and that like Typescript versus Flow, in a larger sense they've done almost nothing but slowly converge over the intervening decades, learning and growing from each other in both directions.) Typescript didn't start with a lot of the more abstract or higher level type algebras, partly it seems because they wanted to work towards it from a "pragmatic" standpoint of build something that works, find out where the new pain points, build something that works to fix those, and iterate as so forth. Flow started very directly with a powerful abstract type system (with well known inferencing techniques) that was theoretically sound, but arguably not as easily pragmatic to what you might consider the average developer, which is exactly why you would expect Flow to have an early lead from the perspective of the type system. The convergence towards very similar type systems after all that work shouldn't be surprising either, as the drive for more robust type descriptions has indeed pushed Typescript to continually pragmatically iterate, and the realities of the dynamic JS language Typescript tries to type involves a need to describe with types a very wide and diverse range of behavior. Both approaches have their advantages. Arguably, Typescript's "pragmatic" focus I think has helped Typescript end up with the lead that it has in type definitions across the JS ecosystem. Both because the ramp to more advanced/abstract type features is easier for a wider spectrum of developers (in my experience even relatively junior developers can write a Typescript definition file relatively well; Flow that's not necessarily the case from what I've seen, which Flow tries to balance by making inferencing more powerful and definition writing less necessary) and also that the pragmatic/iterative approach in the language itself reflects in a more "perfect is the enemy of the good" attitude in type development in general. (It's fine for a type definition to only describe ~90% of the API/behavior/quirks of a library if that's good enough to get the job done. You can come back and tighten up that remaining 10% in the next pass, or when the next type system features gives you a knob you need to help get it more accurate to how it behaves.) That turned into maybe more of a ramble than I intended, but maybe there's some useful perspective there.

Seems like a pretty small release in comparison to previous updates. Probably a good thing, though - it demonstrates that the language as reached a very mature state with few remaining gaps.

pjmlp 8y ago

Now it just needs to become the official JavaScript's strong mode. :)

daveidol 8y ago
Seriously: this language is amazing. I have to admit I was a holdout for a while, but TS has been fantastic to work with compared to Flow
- k__ 8y ago
  Good to know. I dad the impression Flow was the better approach, but using it wasn't nice.
  - WorldMaker 8y ago
    For a brief period Flow had more type algebra (type unions and intersections) and better inferencing, but Typescript has greatly shrunk the gap between type system capabilities where the differences are much fewer, and rarely anything that matters for most projects. Flow was popular for the ability to put all of its type annotations in JS comments and not need a transpilation pass. Typescript also added a mode that supports that. Flow was popular for the slipstream integration into Babel as the type-stripper was just an "ordinary" Babel plugin. Typescript now supports this as well. So for the most part a lot of the old impressions that Flow was the better approach are out-of-date, and par-for-par Typescript is an equal approach (if not a better approach, depending on your preferences/needs, and due to things like the fact that there are vastly more Typescript type definitions than Flow definitions in the npm wilds now).
    - k__ 8y ago
      Ah. Yes, I read about how TypeScript is a more classical approach, and Flow would use "flow based" typing or something, which was a more modern approach. Also, it came out of the box with non-nullable types. While I had the impression the TypeScript language designers didn't deem these features to be important, they added them anyway.
      - WorldMaker 8y ago
        I don't think it was ever a matter of "not-important", Typescript and Flow started from two different perspectives and took different routes to get to what today is a somewhat more converged place. Overall, I also don't think it's "modern" versus "classical" that much. In terms of the different philosophies it's "language" versus "linter" / "compiler" versus "observer", and there is a huge spectrum of options there. Typescript starting from a place of prioritizing "green field" development at first, where teams had the option to start fresh or similar. Like CoffeeScript or Dart, it wanted to provide a good way to organize and develop new code. (Unlike CoffeeScript or Dart, the "pure superset" approach still provided easier migration; I worked on several projects where conversion was simply rename .js to .ts and then fix compiler warnings until it worked again.) Taking the compiler approach also provided an early focus on providing some transformations to the code. In Typescript projects I typically don't feel a need for Babel, because Typescript handles everything I want in terms of "downlevel" transforms to support the version of JS in browsers. Flow starting from a place where you've got a huge line of code investment into an existing codebase, can't "stop the world" to migrate and absolutely need to start "linter style" evaluating data types. Over time Flow has picked up more reasons to use a cleaner syntax for type annotations than what just comments alone can deliver, driving more Flow projects to adopt Babel transforms for that (in addition to whatever other Babel transforms a project wants). Over time Typescript has wanted to get better at migrating existing JS code. The team proved the language worked great for greenfield projects, and got a lot of interest from customers internally and externally to extend that make it a lot easier to do grayfield work. Also, Typescript found its "pure superset" proved better than expected at evaluating almost all JS. This pushed Typescript to power more and more IDE intelligence features for both JS and TS (in an increasing number of IDEs, beyond even the Visual Studio family). That in turn pushed more JS mode features and support in the language, and increasingly better type inferencing and flow control analysis especially when working in large forests of untyped JS. As for the typing systems themselves, "modern" versus "classical" almost is descriptive, from a certain point of view, modulo the fact that both typing systems are "ancient". Typescript started from a type system that started out seeming more in common with the C++/C#/Java family of "Object Oriented" typing systems, whereas Flow started from a place of being much more directly inspired by the "functional" ML family of type systems. (Though calling this more "modern" than the ALGOL-style "OO" type systems belies the fact that the ML family dates to the 70s and about all of our type systems have equally ancient roots; and that like Typescript versus Flow, in a larger sense they've done almost nothing but slowly converge over the intervening decades, learning and growing from each other in both directions.) Typescript didn't start with a lot of the more abstract or higher level type algebras, partly it seems because they wanted to work towards it from a "pragmatic" standpoint of build something that works, find out where the new pain points, build something that works to fix those, and iterate as so forth. Flow started very directly with a powerful abstract type system (with well known inferencing techniques) that was theoretically sound, but arguably not as easily pragmatic to what you might consider the average developer, which is exactly why you would expect Flow to have an early lead from the perspective of the type system. The convergence towards very similar type systems after all that work shouldn't be surprising either, as the drive for more robust type descriptions has indeed pushed Typescript to continually pragmatically iterate, and the realities of the dynamic JS language Typescript tries to type involves a need to describe with types a very wide and diverse range of behavior. Both approaches have their advantages. Arguably, Typescript's "pragmatic" focus I think has helped Typescript end up with the lead that it has in type definitions across the JS ecosystem. Both because the ramp to more advanced/abstract type features is easier for a wider spectrum of developers (in my experience even relatively junior developers can write a Typescript definition file relatively well; Flow that's not necessarily the case from what I've seen, which Flow tries to balance by making inferencing more powerful and definition writing less necessary) and also that the pragmatic/iterative approach in the language itself reflects in a more "perfect is the enemy of the good" attitude in type development in general. (It's fine for a type definition to only describe ~90% of the API/behavior/quirks of a library if that's good enough to get the job done. You can come back and tighten up that remaining 10% in the next pass, or when the next type system features gives you a knob you need to help get it more accurate to how it behaves.) That turned into maybe more of a ramble than I intended, but maybe there's some useful perspective there.