9 ms·

More and more projects are adding TypeScript definition files for us, and many are even being written (or rewritten) using TypeScript directly! I honestly think

by sbjs 8y ago

More and more projects are adding TypeScript definition files for us, and many are even being written (or rewritten) using TypeScript directly! I honestly think TypeScript is the future of JavaScript. In fact, I can't help but wonder what Microsoft's long term goal is with TS. They're making such blazingly fast progress with it, that I can't help but wonder if this is the "incubation" period of the language, and when it's finally "ready to hatch", they're going to do something big. Almost like this phase of TypeScript's life would traditionally be done inside MS privately, but they wanted to benefit from giving back to the community, from trust building within the community, and from being able to say "we provided the most advances to the JavaScript language out of any contributors by far" and somehow use that as leverage. Maybe they'll make an official TC39 proposal that TypeScript syntax be integrated into JavaScript, complete with a de facto free and open source implementation that browsers and Node.js are free to use to strip types live at compile-time. I just don't get it. They made VS Code, they bought Github, they made TypeScript... where are they going with this? I honestly wonder.

maxwell 8y ago
Their strategy seems focused on increasing Azure market share.
- sbjs 8y ago
  Oh! Duh! How could I have forgotten Azure! Yes, that's definitely where all this is headed. They could be trying to position TypeScript as a secret weapon that gives Azure an edge over AWS. Especially if they're planning on using the type information, once it's universally near-100%, to build a blazingly fast platform using a new compiler and runtime that make use of TypeScript's unique features suited toward compiler optimizations. Especially considering Hejlsberg is behind TypeScript (see my other comment in this thread).
- SpaceGorilla 8y ago
  This seems like the most logical. Growing azure meant MS had to pivot. They finally embraced Linux/open source because without them azure would be doomed. I really hope they continue doing so and it's not just an attempt to take over a market then lock it down how they want. What's the term? Embrace, take over, discontinue?
  - solarkraft 8y ago
    Embrace, extend, extinguish :-)
vorpalhex 8y ago
This feels exactly like coffeescript. At some point, it does seem like TS should simply outright fork javascript and go from there. That would at least remove most of my objections to the developer overhead.
- sbjs 8y ago
  What developer overhead? If you consider the compile-TypeScript phase to be literally no different than your jslint phase, then this build step doesn't really add any overhead. If you're talking about having to write out the types in your code, that's just a healthier alternative to everyone who ever reads or modifies your code having to keep that guess that type information and keep it all in their heads.
- SenHeng 8y ago
  This is nothing like coffeescript. Coffeescript was an entirely separate language that just happens to compile to Javascript. The whole fiasco with Coffeescript 1 -> 2 was that 1 only compiled to ES5 and couldn't support ES6+. Migrating to Coffeescript 2 is basically the same amount of work as migrating to modern day Javascript. You can't even write Javascript within a Coffeecript file without it breaking. Typescript IS Javascript. You can copy paste code both ways and they'll still work.
tinco 8y ago
”we provided the most advances to the JavaScript language out of any contributors by far” How do you figure that? As far as I am aware that honor goes to the CoffeeScript project, whether you hate it or love it, it's been the main inspirator for JavaScripts advances. And second to CoffeeScript would be all the little libraries that inspired JS's standard library expansions like JQuery and Underscore.
- lucideer 8y ago
  I wasn't aware of any advances to JS made by Coffescript, what advances has it made? Do you have examples? You're right about jQuery and underscore, though I think jQuery's are often overstated (it and Sizzle inspired the querySelector API in browsers' DOM implementations, and not much else, underscore has had wide-ranging implications for ES6 in general)
  - treve 8y ago
    Probably arrow functions?
  - jherdman 8y ago
    The fat arrow is the most obvious one that comes to mind.
    - lucideer 8y ago
      I wasn't actually aware that was a Coffeescript first, I had the impression they started with -> and adopted fat arrows later with the advent of ES6, as I know fat arrows was in ES4, but you're right, Coffescript seems to predate even ES4. Good to know.
  - tinco 8y ago
    As the other commenters said, the arrow functions, which are very comfortable and very directly inspired from CoffeeScript. But more importantly, the whole idea of ES6 was inspired by CoffeeScript. This might seem weird if you were outside the loop at the time and don't realize how succesful it was, but the fact that ES6 got so many cool features was directly due to CoffeeScript's success. If ES6 wouldn't have those features, people would not have switched from CoffeeScript back to pure Javascript. And the success of Typescript shows that they still have to move quickly to keep pure Javascript relevant. Here's a list of comparisons between CoffeeScript and ES6/7: https://github.com/hemanth/coffeescript-equivalents-in-es6 https://github.com/hemanth/coffeescript-equivalents-in-es6 Note that these are features that were not in ES5, then they were in CoffeeScript, and only then were they added to ES6. The similarities are in no way a coincidence, almost all of CoffeeScript was in one way or another integrated into ES6.
mschuetz 8y ago
It would be amazing if typescript could become the browser standard. I'm currently suffering from performance and readability issues from writing and filling typed structs in javascript with non-word alignment. e.g. I've got data like this: struct Point{ float x, y, z; unsigned char r, g, b; unsigned short intensity; double gps_time; } Point[] points = new Point[1234]; Reading, generating, and manipulating data like this is a bitch in javascript. Typed arrays have to be aligned to the byte size of it's type and because the offset of gps_time isn't at a multiple of 8, it's not possible to read it with Float64Arrays. DataView works but it's an order of magnitude (!!) slower than typed arrays so the best thing I can do for now is to read a double by treating everything as Uint8Array(), and then read the 8 bytes of the double into a temporary ArrayBuffer that can be used to convert between types. My hope is that Typescripts type system is good enough to be able to treat this kind of data similarely as you can in C++, and that it would then become standard.
- sbjs 8y ago
  If everything is typed in TypeScript, I see a lot of serious potential for optimization, like using only the memory needed per object exactly like a struct in C or C++.
  - pcwalton 8y ago
    TypeScript isn't sound, so you can't rely on the types for optimization. The shape/hidden class optimization that JS engines already have is probably about as good as you can do.
    - nwienert 8y ago
      You could still infer sound areas such as certain structs and patterns for using them. They could introduce sound mode or patterns for areas as well.
    - xiphias 8y ago
      Actually the compiler could use types as hints for the optimization, so it doesn't sound that bad idea.
WorldMaker 8y ago
The tale of Typescript was that several of Microsoft's own JS codebases had gotten too huge to manage in just JS and Typescript was built to scratch their own itch first. Microsoft happened to have a smart developer-focused division that also realized that Microsoft's own customers could benefit from the tool, too. Microsoft has invested quite heavily into some very large TS codebases: VS Code/Monaco, VSTS, the Azure portal, large components of Office, large components of Bing, and so forth. Given the scale of some of those projects (in terms of users at the very least, even before you get into metrics like lines of code or dollars generated), that is a lot of benefit to having a strong tool like Typescript to do that work in. Many of the same developers working in Typescript use C++ and/or C# daily, so they already understood the usefulness of things like static type checking. Releasing it to the public when they did seemed a very cogent realization that that "enterprise JS application problem" was far bigger than just Microsoft and they were in a good place to help with that, given it's long been a goal of the company to help developers. As for a Typescript proposal for TC39, I'm willing to bet everyone is still worried about accidentally creating a second "ES4" debacle, including Microsoft. I'd love to see, and would much more expect at this point, a pragmatic compromise like Python's PEP 526 [0] / PEP 3107 [1] project, encouraging JS engines to syntactically accept things like Typescript's type annotations, but remaining agnostic to what the annotations represent semantically (giving other JS users the option of doing things with the annotations other than types, too, if they wished). [0] https://www.python.org/dev/peps/pep-0526/ https://www.python.org/dev/peps/pep-0526/ [1] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/
- theodorejb 8y ago
  Even if JS engines were to accept the type annotation syntax, there would still be a need to strip out the types simply from the perspective of minimizing JavaScript bundle sizes.
  - WorldMaker 8y ago
    Most Node code runs unminimized, and HTTP2 makes minimization less of a concern for the web. (It's still useful, of course, but less necessary.) So sure it is likely that in many cases browsers will still mostly see JS with stripped annotations, but the reason to do it is the same as the debate over whether or not to strip comments and/or support sourcemaps. There's clear wins at the very least in debugging situations to allow unstripped type annotations all the way through to the dev tools. There are even cases where that may make sense even in a production environment, including things like metaprogramming if those annotations are reflectable. This nice thing would be to have the option, whether or not most projects might still prefer to strip them out to optimize bundle sizes. As with almost all things, it's an interesting spectrum of tradeoffs.
mattferderer 8y ago
Microsoft wants "Developers, Developers, Developers!" TypeScript makes JavaScript easier & less buggy IMO. The more people developing with TypeScript, the better chance they use Microsoft's other tools. Some of those tools cost money. Some also make deploying with Azure really easy & enjoyable. Azure is their big cash cow. The more MS tools you use & the better perception of the company you have, the easier it is to find yourself just wanting to stay in their ecosystem.
- sbjs 8y ago
  That doesn't seem right. I don't know anyone who uses Azure outside of a .NET-centric programming job. Azure always seemed to be like "hey if you heard good things about AWS and need a place to deploy your code but you've never touched anything outside the Microsoft ecosystem, come try Azure!" I've seen it advertised on Stack Overflow a lot, but I have never even thought of looking into it, for the same reason I have no reason to install Visual Studio.
  - korijn 8y ago
    We primarily use Azure, and only 1 .NET legacy app lives there. Everything else is Python and JS! I'm enjoying Azure a lot!
  - bigtones 8y ago
    Azure is aimed at Enterprises and developers inside those companies who already run a lot of Microsoft tech and are familiar with Visual Studio. They do really well in that space because they already have a lot of mind share there, and that is a very big opportunity for them monetarily in the next few years as a lot of Enterprises move to the cloud.
  - gameswithgo 8y ago
    battlegrounds uses azure
  - TomMarius 8y ago
    Enterprise doesn't care about this. Enterprise cares about prices.

by sbjs 8y ago

maxwell 8y ago

Their strategy seems focused on increasing Azure market share.

sbjs 8y ago
Oh! Duh! How could I have forgotten Azure! Yes, that's definitely where all this is headed. They could be trying to position TypeScript as a secret weapon that gives Azure an edge over AWS. Especially if they're planning on using the type information, once it's universally near-100%, to build a blazingly fast platform using a new compiler and runtime that make use of TypeScript's unique features suited toward compiler optimizations. Especially considering Hejlsberg is behind TypeScript (see my other comment in this thread).
SpaceGorilla 8y ago
This seems like the most logical. Growing azure meant MS had to pivot. They finally embraced Linux/open source because without them azure would be doomed. I really hope they continue doing so and it's not just an attempt to take over a market then lock it down how they want. What's the term? Embrace, take over, discontinue?
- solarkraft 8y ago
  Embrace, extend, extinguish :-)

vorpalhex 8y ago

This feels exactly like coffeescript. At some point, it does seem like TS should simply outright fork javascript and go from there. That would at least remove most of my objections to the developer overhead.

sbjs 8y ago
What developer overhead? If you consider the compile-TypeScript phase to be literally no different than your jslint phase, then this build step doesn't really add any overhead. If you're talking about having to write out the types in your code, that's just a healthier alternative to everyone who ever reads or modifies your code having to keep that guess that type information and keep it all in their heads.
SenHeng 8y ago
This is nothing like coffeescript. Coffeescript was an entirely separate language that just happens to compile to Javascript. The whole fiasco with Coffeescript 1 -> 2 was that 1 only compiled to ES5 and couldn't support ES6+. Migrating to Coffeescript 2 is basically the same amount of work as migrating to modern day Javascript. You can't even write Javascript within a Coffeecript file without it breaking. Typescript IS Javascript. You can copy paste code both ways and they'll still work.

tinco 8y ago

”we provided the most advances to the JavaScript language out of any contributors by far” How do you figure that? As far as I am aware that honor goes to the CoffeeScript project, whether you hate it or love it, it's been the main inspirator for JavaScripts advances. And second to CoffeeScript would be all the little libraries that inspired JS's standard library expansions like JQuery and Underscore.

lucideer 8y ago
I wasn't aware of any advances to JS made by Coffescript, what advances has it made? Do you have examples? You're right about jQuery and underscore, though I think jQuery's are often overstated (it and Sizzle inspired the querySelector API in browsers' DOM implementations, and not much else, underscore has had wide-ranging implications for ES6 in general)
- treve 8y ago
  Probably arrow functions?
- jherdman 8y ago
  The fat arrow is the most obvious one that comes to mind.
  - lucideer 8y ago
    I wasn't actually aware that was a Coffeescript first, I had the impression they started with -> and adopted fat arrows later with the advent of ES6, as I know fat arrows was in ES4, but you're right, Coffescript seems to predate even ES4. Good to know.
- tinco 8y ago
  As the other commenters said, the arrow functions, which are very comfortable and very directly inspired from CoffeeScript. But more importantly, the whole idea of ES6 was inspired by CoffeeScript. This might seem weird if you were outside the loop at the time and don't realize how succesful it was, but the fact that ES6 got so many cool features was directly due to CoffeeScript's success. If ES6 wouldn't have those features, people would not have switched from CoffeeScript back to pure Javascript. And the success of Typescript shows that they still have to move quickly to keep pure Javascript relevant. Here's a list of comparisons between CoffeeScript and ES6/7: https://github.com/hemanth/coffeescript-equivalents-in-es6 https://github.com/hemanth/coffeescript-equivalents-in-es6 Note that these are features that were not in ES5, then they were in CoffeeScript, and only then were they added to ES6. The similarities are in no way a coincidence, almost all of CoffeeScript was in one way or another integrated into ES6.

mschuetz 8y ago

It would be amazing if typescript could become the browser standard. I'm currently suffering from performance and readability issues from writing and filling typed structs in javascript with non-word alignment. e.g. I've got data like this: struct Point{ float x, y, z; unsigned char r, g, b; unsigned short intensity; double gps_time; } Point[] points = new Point[1234]; Reading, generating, and manipulating data like this is a bitch in javascript. Typed arrays have to be aligned to the byte size of it's type and because the offset of gps_time isn't at a multiple of 8, it's not possible to read it with Float64Arrays. DataView works but it's an order of magnitude (!!) slower than typed arrays so the best thing I can do for now is to read a double by treating everything as Uint8Array(), and then read the 8 bytes of the double into a temporary ArrayBuffer that can be used to convert between types. My hope is that Typescripts type system is good enough to be able to treat this kind of data similarely as you can in C++, and that it would then become standard.

sbjs 8y ago
If everything is typed in TypeScript, I see a lot of serious potential for optimization, like using only the memory needed per object exactly like a struct in C or C++.
- pcwalton 8y ago
  TypeScript isn't sound, so you can't rely on the types for optimization. The shape/hidden class optimization that JS engines already have is probably about as good as you can do.
  - nwienert 8y ago
    You could still infer sound areas such as certain structs and patterns for using them. They could introduce sound mode or patterns for areas as well.
  - xiphias 8y ago
    Actually the compiler could use types as hints for the optimization, so it doesn't sound that bad idea.

WorldMaker 8y ago

The tale of Typescript was that several of Microsoft's own JS codebases had gotten too huge to manage in just JS and Typescript was built to scratch their own itch first. Microsoft happened to have a smart developer-focused division that also realized that Microsoft's own customers could benefit from the tool, too. Microsoft has invested quite heavily into some very large TS codebases: VS Code/Monaco, VSTS, the Azure portal, large components of Office, large components of Bing, and so forth. Given the scale of some of those projects (in terms of users at the very least, even before you get into metrics like lines of code or dollars generated), that is a lot of benefit to having a strong tool like Typescript to do that work in. Many of the same developers working in Typescript use C++ and/or C# daily, so they already understood the usefulness of things like static type checking. Releasing it to the public when they did seemed a very cogent realization that that "enterprise JS application problem" was far bigger than just Microsoft and they were in a good place to help with that, given it's long been a goal of the company to help developers. As for a Typescript proposal for TC39, I'm willing to bet everyone is still worried about accidentally creating a second "ES4" debacle, including Microsoft. I'd love to see, and would much more expect at this point, a pragmatic compromise like Python's PEP 526 [0] / PEP 3107 [1] project, encouraging JS engines to syntactically accept things like Typescript's type annotations, but remaining agnostic to what the annotations represent semantically (giving other JS users the option of doing things with the annotations other than types, too, if they wished). [0] https://www.python.org/dev/peps/pep-0526/ https://www.python.org/dev/peps/pep-0526/ [1] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/

theodorejb 8y ago
Even if JS engines were to accept the type annotation syntax, there would still be a need to strip out the types simply from the perspective of minimizing JavaScript bundle sizes.
- WorldMaker 8y ago
  Most Node code runs unminimized, and HTTP2 makes minimization less of a concern for the web. (It's still useful, of course, but less necessary.) So sure it is likely that in many cases browsers will still mostly see JS with stripped annotations, but the reason to do it is the same as the debate over whether or not to strip comments and/or support sourcemaps. There's clear wins at the very least in debugging situations to allow unstripped type annotations all the way through to the dev tools. There are even cases where that may make sense even in a production environment, including things like metaprogramming if those annotations are reflectable. This nice thing would be to have the option, whether or not most projects might still prefer to strip them out to optimize bundle sizes. As with almost all things, it's an interesting spectrum of tradeoffs.

mattferderer 8y ago

Microsoft wants "Developers, Developers, Developers!" TypeScript makes JavaScript easier & less buggy IMO. The more people developing with TypeScript, the better chance they use Microsoft's other tools. Some of those tools cost money. Some also make deploying with Azure really easy & enjoyable. Azure is their big cash cow. The more MS tools you use & the better perception of the company you have, the easier it is to find yourself just wanting to stay in their ecosystem.

sbjs 8y ago
That doesn't seem right. I don't know anyone who uses Azure outside of a .NET-centric programming job. Azure always seemed to be like "hey if you heard good things about AWS and need a place to deploy your code but you've never touched anything outside the Microsoft ecosystem, come try Azure!" I've seen it advertised on Stack Overflow a lot, but I have never even thought of looking into it, for the same reason I have no reason to install Visual Studio.
- korijn 8y ago
  We primarily use Azure, and only 1 .NET legacy app lives there. Everything else is Python and JS! I'm enjoying Azure a lot!
- bigtones 8y ago
  Azure is aimed at Enterprises and developers inside those companies who already run a lot of Microsoft tech and are familiar with Visual Studio. They do really well in that space because they already have a lot of mind share there, and that is a very big opportunity for them monetarily in the next few years as a lot of Enterprises move to the cloud.
- gameswithgo 8y ago
  battlegrounds uses azure
- TomMarius 8y ago
  Enterprise doesn't care about this. Enterprise cares about prices.