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/ [1] https://www.python.org/dev/peps/pep-3107/
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.
Are you really sure?
To me that attitude sounds awfully close to cargo-culting.
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.
If you do Kubernetes type deployments they have some nice offerings for all levels of knowledge. They just released Service Fabric Mesh for those who know less about it.
If you just want a simple deployment, their App Services is really slick & easy with Github integration for JS, PHP, .NET & other stacks.
They also have some really good integrations with their serverless stuff that decreases the amount of code you have to write significantly.
I actually only know web developers using Macs to edit their TS, maybe a rare case of Linux, zero other MS things used, except maybe VS Code. And maybe it's debatable if VS Code is the best TS editor, I also have no numbers about widespread use, but I doubt it's a majority.
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];
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.
It would be nice to have some more targeted solution for working with typed arrays, though.
let x: number = "some string" as any;This actually happens a lot with types from DefinitelyTyped that are not maintained by the original author of the library.
And well over 2 seconds for Webpack to deal with (just) bundling 6 JS files and the .wasm file.
Curious, which languages compile that fast to WebAssembly?
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?
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.
And while I'd like to agree with you that having types in Javascript is more important than the coding comfort CoffeeScript brings, I still think ES6 was more important than Typescript is or will be. Before CoffeeScript coding in Javascript was at best annoying, and at worst absolutely terrible.
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)
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
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.
"Arrow functions" (lambdas) existed long before CoffeeScript. Arrows of varying types (usually => or ->) have been standard syntax for lambdas for easily decades. One of the language designers on the TS team was involved in a language that had lambdas a year before CoffeeScript came into existence. To call lambdas a CoffeeScript innovation is like calling actors an Elixir innovation.
On the subject of CoffeeScript inspiring ES, that is likely very true - at the very least it lit a fire under an extremely stale language. They carefully selected some very good ideas that worked well together and made a beautiful language with them. However impressive, beautiful language design is not innovation. Something like optional any is.
I think the question was about whether they existed in the JavaScript community.
I'm sure much of Typescripts great features are not completely novel nor unique—e.g. generics come from c# and Java—but it is responsible for bringing them to JavaScript.
CoffeeScript had this mix of language features I think any language aficionado could have picked up at the time. It was just crazily succesful, no doubt due to its flawless execution by Jeremy Ashkenas.
Not sure what "outside the loop" means here but do you have a source for this statement? I followed ES proposals quite closely throughout and wasn't aware of any such thing.
> Here's a list of comparisons between CoffeeScript and ES6/7:
> Note that these are features that were not in ES5, then they were in CoffeeScript, and only then were they added to ES6
Unless you supplied the wrong link, I think you're mistaken here. Of the many examples in the link, the majority are code that was in ES3, or—in the case of array methods—bare little resemblance to Coffescript (I think a lot of those were inspired by Underscore).
The exceptions are fat arrows and spread, and I think the latter has a more complex history.
Two other notables in that link: lexical scope was in JavaScript 1.7, introduced in Firefox 3.6, predating Coffescript's introduction. Generators had an early form in JavaScript 1.8 but the syntax changed for es6, and Coffescript adopted it after es6.
Here's a nice article showing that CoffeeScript was on Brendan's mind when he was working on Harmony (ES6): https://brendaneich.com/2010/11/paren-free/
He calls Ruby/Python/CoffeeScript "unsyntax" and he doesn't like it I think :P
edit: apparently he does like it, he just doesn't think it would work on the web, he elaborates here: http://intertwingly.net/blog/2010/11/25/Hobgoblin-of-Little-...
The page is a list of examples of Coffescript done in Javascript. Whether they show evidence of Javascript taking features from Coffescript isn't really a subjective question; they do or they don't. I explicitly enumerated which do and which don't.
In terms of "experiencing the times differently", that is subjective, so I guess we did. One blog post from Eich on why he doesn't want to remove braces isn't really holistic, but you might be right in general.
I'm not sure how you figure you enumerated which do and which don't. Apparently I'm preaching something unpopular, all my comments have been downvoted a bunch.
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.