Hacker News Reader

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/ [1] https://www.python.org/dev/peps/pep-3107/

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.

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.

How does HTTP2 make minimization less necessary?

There have been claims that http2 pipelining means it's more efficient to serve bundles as separate files, unminified so they can be downloaded in parallel. (I haven't yet seen numbers that show it's a benefit in practice though.)

Not just pipelining, but fewer more high-throughput connections, smaller HTTP header overhead, HTTP2 Push with the server being able to stream a "bundle equivalent" to the client in the background, and perhaps most importantly, Brotli compression which does pretty well with unminified JS.

Not necessarily, given that a binary representation is also being discussed (not to mix with WebAssembly).

https://github.com/binast/ecmascript-binary-ast

> there would still be a need to strip out the types simply from the perspective of minimizing JavaScript bundle sizes.

Are you really sure?

To me that attitude sounds awfully close to cargo-culting.

How is that cargo-culting? GP's comment doesn't even seem to come close to the meaning of cargo-culting. And yes, type definitions in my projects account for a good percentage, anywhere from 5-25% of each file, if you take into account all the interfaces, parameter definitions, class types... So that's removing 5-25% of your minified JS bundle, and if we're talking a 4mb bundle, that could be 1mb of type information, completely useless at runtime. If you needed to map that type information to your source code, this is what source maps are for!

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.

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.

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.

We primarily use Azure, and only 1 .NET legacy app lives there. Everything else is Python and JS! I'm enjoying Azure a lot!

battlegrounds uses azure

Enterprise doesn't care about this. Enterprise cares about prices.

In my experience, enterprises care less about price & more about support, perceived reliability & how they calculate value. I typically see them pay through the nose for inferior products, that are over priced but offer support packages & are billed as an enterprise company. Ironically, the support usually leaves them frustrated as good support is hard to find.

I suggest giving it a shot.

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 see TS as basically the one example that has nothing to do with the MS ecosystem.

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.

I looked at a few surveys and nearly 50% of the developers are using Windows. I doubt that this can change so much for JavaScript.

Yeah, my data is anecdata - I only know one country and mostly small shops. But unless something drastically changed the last years where I was in startup land - many web developers tended to prefer Linux or Macs, whether they're using Rails, Python, or PHP. In general the bigger or more agency-like the company, the higher the percentage of Windows for developers.

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.

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++.

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.

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.

The last soundness issue I'm aware of is the bivariant function issue which they resolved in 2.6

You can still do something like this:

    let x: number = "some string" as any;

I don't get it, I though the whole purpose of typescript is to prevent things like that?

That's sort of tautological. "Any" and type assertions are designed as the escape hatch of the type system. If you're trying to develop type safe typescript you obviously won't use those. The followup question is for typed code (excluding usage of any or type assertions) does typescript have an unsound type system? Afaik the answer is no.

In the real world you are forced to use "any" when the type definitions for a third-party library are not perfect.

This actually happens a lot with types from DefinitelyTyped that are not maintained by the original author of the library.

That would be the equivalent of static_cast in c++, or casting via (object) in C#. Both of those are considered type safe but can still be abused also.

There is WebAssembly for that now.

I'm not a fan of WebAssembly. I like js because you can instantly reload and test changes to your code without lengthy build or compile times and I'm hoping for typescript to become standard so that the same applies for typescript. I doubt the same will ever be possible with WebAssembly.

Anything more complicated than a little jQuery stuff is going to need build tooling anyway, at least Webpack and probably JSLint and Mocha. Since those are already there, adding either Babel or TyepScript isn't all that difficult.

what is lengthy to you? some languages can compile ~30k lines in 0.5 seconds

Anything > 1s

Curious, which languages compile that fast to WebAssembly?

Just took .284s to re-compile a Rust (stdweb) app targeting WASM.

And well over 2 seconds for Webpack to deal with (just) bundling 6 JS files and the .wasm file.

Putting Typescript into the browser would make it very hard to evolve Typescript since we would have to wait for browser compatibility. Better to keep it in the compile toolchain.

It would be nice to have some more targeted solution for working with typed arrays, though.

Right. We will soon need TS to TS compilation as TS progresses way too fast for browser adoptions to catch up.

Their strategy seems focused on increasing Azure market share.

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).

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?

Embrace, extend, extinguish :-)

”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.

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)

Probably arrow functions?

The fat arrow is the most obvious one that comes to mind.

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.

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

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.

I don't think it is an either/or. TC39 has shown that they love multiple implementations of things. CoffeeScript and Typescript (and Babel) implementing things together ahead of the spec, and how they agreed/where they differed/what obstacles they encountered, was likely as much of a factor as either language in isolation.

> the arrow functions, which are very comfortable and very directly inspired from CoffeeScript.

"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.

If CoffeeScript didn't have arrow functions, I don't think ES6 would have had arrow functions.

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.

I really haven't noticed any mark of its success on the German job market.

> "Arrow functions" (lambdas) existed long before CoffeeScript

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.

> 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.

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.

I supplied the right link. I suppose we're reading the page differently. If you don't think that page is evidence enough that CoffeeScript inspired much of ES6 then I suppose we experienced the times differently.

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-...

> I suppose we're reading the page differently. If you don't think that page is evidence enough...

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.

Arrow functions, splats, default params, string interpolation, lexical scopes, classes, destructuring assignments, chained comparisons, for loops.

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.

Maybe it gave the sense that compiling JS was worth it than sticking with plain JS.

Do you really believe CoffeeScript's arrow functions (or whatever else) had a bigger impact than adding static types to JavaScript? CoffeeScript is mostly about shorter-syntax improvements, while TypeScript (or Flow) just changes everything… coding, debugging, refactoring, pushing code in prod with the assurance that it won't break…

Typescript is not a part of Javascript yet. Maybe I underestimate the marketshare of Typescript, but CoffeeScript has improved Javascript everywhere by being the inspirator for ES6.

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.

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.

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.

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.