Announcing TypeScript 1.8 Beta(blogs.msdn.com)

256 pointsby DanRosenwasser11 anni fa82 comments

blogs.msdn.com

http://blogs.msdn.com/b/typescript/archive/2016/01/28/announcing-typescript-1-8-beta.aspx

14 comments

This is brilliant! The first three features, i.e. --allowJs, --reactNamespace, and stateless functional componentshave been precisely the things that I have been missing recently.

This makes integrating 3rd party JS libs much easier and I can streamline my components a little since I'm almost exclusively using stateless components anyway.

That already made me quite happy. But as I'm reading on I almost can't believe all the other great additions, such as module augmentations, string literal types, AMD module concatenation, let/const in loops. It's like they've been reading my mind. These were all things on my wishlist. Great work!

DanRosenwasser11 anni fa

Also check out our "What's New in TypeScript" page[1] for a little more detail.

[1] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

cpeterso11 anni fa

Does Microsoft use TypeScript for any of its other products or web services? How strongly are Microsoft web teams encouraged to dogfood TypeScript? :)

altano10 anni fa

TypeScript is looked upon very highly by everyone at MS and I haven't seen any new projects started with vanilla JS in the last few years. No one needs to encourage anyone to use it. It's just the obvious choice for large projects (and every project at MS is large).

Some other products using it off the top of my head: Azure Machine Learning, Xbox Music, Visual Studio Team Services. EVERYTHING new.

lenkite10 anni fa

Sadly, Microsoft's main JS library for UI development - WinJS 4.x is _not_ TypeScript enabled.

judah10 anni fa

While WinJS is not built in TypeScript, there are TypeScript bindings for it[0] bundled in the WinJS repo, so it's easy to use from TypeScript.

[0]: https://github.com/winjs/winjs/tree/master/typings

AdamTReineke11 anni fa

VS Code, IE11/Edge's F12 developer tools, and Sway (Office) use it to name only a few.

VS Code's source: https://github.com/Microsoft/vscode

theatraine11 anni fa

The new Azure portal uses TypeScript heavily.

awa10 anni fa

https://www.onenote.com/clipper is written in typescript

rekoros11 anni fa

TypeScript is amazing. We decided on TS to build https://sameroom.io and never looked back!

meowface11 anni fa

Cool application. It's something I've wanted for a while, and I'd probably use it. But linking it here apropos of almost nothing seems a little like shilling.

rekoros11 anni fa

Hey - thanks!

Proper TypeScript usage is still pretty rare, so this felt OK.

As a startup founder, if you have a choice between telling people about your startup and not telling: tell. This is incredibly hard for engineers, but you just have do it.

Sometimes I wonder, how many amazing technologies have died because the founders simply couldn't ever figure out how to tell the world about what they built.

untog11 anni fa

Proper TypeScript usage is still pretty rare, so this felt OK.

And if you were pointing to a repo of the code that powers your startup, I'd agree with you.

rekoros10 anni fa

Bad word choice on my part.

Didn't mean "proper" as in "correct", but as in all-in, no-looking-back.

voltagex_11 anni fa

Can you elaborate on how you got started on TypeScript? What IDEs and editors are you using? What build process? How did you handle integration with non-TS libraries? Are there any problems you faced that you wouldn't have, had you stuck with JS? (I'd read a blog post about this, by the way)

rekoros10 anni fa

Before Sameroom [1], we spent two years building Kato (https://kato.im), which became a Slack competitor once Slack launched. We did enjoy a brief pre-Slack honeymoon (at Techstars, no less).

For a few reasons, we chose Xamarin to build the Kato mobile apps. The end result was pretty good—great, even, considering the ridiculously tight timeline. We had a pretty elaborate common core with all the hard stuff (networking, caching, protocol, presence, etc), and custom UI code for Android and iOS.

In the end, since Kato was to be no more, the real benefit was seeing how much sense it makes to use a strongly-typed, object-oriented language for building complex user interfaces.

Many years ago, and for many years, we were C#/C++ programmers, so it wasn't exactly a revelation. But, we'd been working for quite some time with dynamically-typed Erlang and dynamically-typed Javascript (the Kato UI was built with Knockout.js).

Our server code was fairly straightforward and didn't change very much, so Erlang was an excellent choice there. With JavaScript, we'd programmed our way into some serious debt.

When deciding on a stack for Sameroom, we embarked on a quest to replicate the Xamarin experience for the web. We eventually narrowed in on Flux, React, and TypeScript.

After some experimentation, we got a development workflow working with gulp, shrinkwrap, make, and no particular IDE (we use Atom, Sublime, and Vim).

The biggest crutch was lack of JSX support in TypeScript, so splicing together HTML elements was pretty cumbersome. We viewed this as a temporarly incovenience, which was a good decision—TypeScript 1.6 got React/JSX in September 2015 [2].

We're pretty conservative about adding dependencies, but the overwhelming majority of libraries we do use have TS support available from the DefinitelyTyped project [3]. The few libraries that weren't supported (Stripe checkout and Intercom, if memory serves), we TypeScriptified ourselves.

As a result, working on the Sameroom UI is absolute joy.

It's a little ironic that, unlike Kato, Sameroom basically doesn't need a UI, since it's just marketing copy and an administrative dashboard.

[1] https://sameroom.io/blog/from-pivot-to-140-paying-customers-...

[2] http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...

[3] https://github.com/DefinitelyTyped/DefinitelyTyped

bribri10 anni fa

+1 for Atom Typescript

TheWiseOne10 anni fa

Visual Studio Code, WebStorm have excellent support for TS built-in. There is also CATS (https://github.com/jbaron/cats) that's targeted towards TypeScript.

For Sublime, Atom, etc. there are a bunch of plugins that you can download:

https://github.com/Microsoft/TypeScript-Sublime-Plugin

https://atom.io/packages/atom-typescript

Check out the DefinitelyTyped (http://definitelytyped.org) and Typings (https://github.com/typings) for type definitions to most of the popular JS libraries. There is also a list of some useful tools and utilities on the DefinitelyTyped website but here are a few that might be useful:

https://github.com/palantir/tslint

https://github.com/TypeStrong

https://github.com/sebastian-lenz/typedoc

https://github.com/ivogabe/gulp-typescript

https://github.com/Asana/typed-react

acidity10 anni fa

Seems like you used React for the project above. Did you build a view/controller framework in house or something more common?

meowface11 anni fa

>As a startup founder, if you have a choice between telling people about your startup and not telling: tell.

I really can't agree. It might help your startup, but at the cost of reputation and goodwill. I could choose to start a company and tell people about it by mentioning it in hundreds of posts on message boards and news aggregators, but even if I contributed intelligent discussion and content along with it, I'd still likely be downvoted, "thumbs-downed", and lambasted the vast majority of the time.

Mentioning it is fine in some cases, where it's actually very pertinent to the discussion ("actually, my startup happens to be solving exactly this problem!" or "for a great example of X, check out https://startup.com [Full disclosure: I'm a co-founder]"). These are sensible cases of promotion. But blasting the link when it's barely relevant seems sleazy and disingenuous.

>if you have a choice between telling people about your startup and not telling: tell. This is incredibly hard for engineers, but you just have do it. Getting publicity is easy, especially if you have no ethics and/or a lot of money to spend. Getting well-deserved and organic publicity is much harder.

Your post was in response to a minor-ish announcement about a programming language that's been around for 4 years, one very similar to the most popular one (JavaScript), and which definitely isn't some kind of unicorn or barely-known gem.

If you just wanted to show that real people are using TypeScript in production, why couldn't you have said "my startup has been successfully using TS for X amount of time and we've been loving it" and nothing more? Anyone who was genuinely interested in what startup it was could look at your other posts, or message you, or click the link from your profile if you had it listed it there. You didn't even link to any source code to show people examples of practical TypeScript.

The exact startup that's using TS doesn't matter in respect to the nature of the comment you made. Perhaps if it were something really notable and unexpected, like Twitter or Google suddenly using TS for their frontend, then mentioning the company makes sense. Here, it just seems like shameless self-promotion.

As a result of your post, I think a little more highly of TypeScript, but in turn, I also think less of your startup. Which is a shame, since it seems like a good idea.

smokeyj11 anni fa

This wall of text was unnecessary. A community member self promoted. If you don't like it down vote

meowface10 anni fa

I only replied in more detail because they disagreed with my initial comment at https://news.ycombinator.com/item?id=10992673.

I'd rather explain my reasoning in detail than simply continue to throw sentence-long accusations wildly.

jonesb611 anni fa

My dream is to have enough free time to rewrite a large open source project from es5/6 to typescript. One day..

Edit: I meant refactoring as a way to improve the project, learn typescript, and learn the project itself inside and out.

nothrabannosir11 anni fa

I don't know if you're setting me up for a joke here, but you're putting the ball an inch away from an open goal:

Javascript is Typescript. Typescript ⊇ Javascript.

Especially if you already use Babel (or any other JS preprocessor, like uglify or concat) and have a build pipeline ready, you can start using Typescript today.

Don't miss out!

PS: It will throw a lot of errors on a conventional codebase, but compile despite them. That's the point; install the compiler today, slowly start fixing the errors as you go. It's all about gradual improvement and optional typing.

seivan11 anni fa

There are still issues with type definitions for third party libraries. I love TypeScript and would love to work on it full time, but it's painful when you need to use a dozen third party code. Unless this has been solved recently, I remembered tds files weren't updated regularly.

nothrabannosir11 anni fa

This myth really needs to die. Sorry for the harsh language, it's the TS team's fault for not taking this ongoing PR blunder seriously.

You can (and always could) use almost any 3rd party lib with literally one line of code:

    var somelib: any;

Done. No need to ever touch a .d.ts file.

Sure, no type safety on the lib. But isn't that where we started, anyway?

This should be put on a giant banner on the TS homepage.

Arnavion11 anni fa

I would put `declare` in front of that to avoid generating an unused variable.

And for required modules, you'd need to shim require in similar fashion and use var instead of import.

    declare function require(module: string): any;
    var somelib = require("somelib");

WorldMaker10 anni fa

Or you can use import and the simple pattern of:

    declare module "somelib" {
        var somelib: any
        export = somelib
    }

seivan11 anni fa

I'm not bothered by silly things like tone or harsh language, especially for such amazing news. I've actually written my fair share during the summer and I never knew about this.

Thank you! How well would this work with an editor and typescript plugins? Say the amazing typescript-atom, I would guess the editor would crap its pants, no?

DCoder10 anni fa

A better way would be to do like Arnavion said, for really global libraries you should create a .d.ts file and put this line in it:

    declare var somelib: any;

Done. Now the compiler and everything else will know that there's a global variable called `somelib` that does not have a specific type, and no matter how you use that variable, it's ok, you know what you're doing.

nothrabannosir10 anni fa

No problem. As others mentioned; declare var is the way to go (my TS is getting rusty, apparently :) ).

Editors have no problem with it. They will simply see it as an "any" var. Completely compatible.

I wrote quite a bit of TS and this was how I used most obscure libraries. I can't be arsed to keep those stupid .d.ts files up to date and I trust the API docs. It's my own code I wanted to vet. Works like a charm.

Judicious use of declare var any, and ignoring compiler errors, is what really makes TS reality-compatible.

carussell10 anni fa

Why not use VSCode instead of Atom? It's (relatively) performant, it has first class support for TypeScript, and if you ever want to hack on it, it's free/open source software (MIT) and written in TypeScript itself.

spion10 anni fa

Good point. Another option for libraries you use less heavily is to only write definitions for the parts of the library you actually use.

You're not using the entire options parameter or https://github.com/flot/flot/blob/master/API.md ? Don't declare it - only add the properties you do use.

You're only using 3 methods from 1 class in aws-sdk ? Only declare that 1 class and 3 methods in your aws-sdk.d.ts

girvo11 anni fa

I had the same dream... so I started using Flow[0]! Put all of my codebase in /* @flow weak */ to start, then slowly tightened it up with more type hints, declarations, etc.

[0] http://flowtype.org/

igl11 anni fa

I recently learned that the TS type-checker is unsound on purpose and i am a bit disappointed.

http://tryflow.org/#2944d91c10fc5d76faeebbb20cac466a Try this snippet in TS.

recursive11 anni fa

Undeclared parameters are implicitly "any". You don't need nearly this much code to break. This is equivalently broken:

var x: any = {}; x.foo();

Here's the typesafe way: http://tryflow.org/#b5f826e03045f64084cfc74398270e85

altano10 anni fa

Regarding the unsoundness-by-default, I wish "--no-implicit-any" was the default but it's really no big thing to just add this flag to any project.

igl10 anni fa

Still... why have type inference in the first place if you can not safely utilize it. The argument for having things unsound is "to strike a balance between correctness and productivity". Having to declare types on everything even if it's just generics beats the productivity argument.

spion10 anni fa

Because turning the inference dial up often results with what Flow does: it shows the error at all the wrong places and doesn't show it at the right one.

Try adding the types to the function in your Flow example. The error will finally move to the last line i.e. Flow will actually become useful in tracing down the error.

http://tryflow.org/#e6512d9c847d504bba8be8b90427ffc3

I think Microsoft made the right call to demand function argument types. It doesn't cost very much at all, but it improves error messages tremendously. It might not matter in a tiny example, but I'd bet that Flow's behaviour can be frustrating in a large project.

igl10 anni fa

Showing a less accurate error is worse than showing no error? How is that "less" frustrating if you have to find a bug? It does not DEMAND the argument type? Adding it to flow also improves the error message? How is that the right call?

spion10 anni fa

Showing a missing type annotation error is better than showing errors at all the wrong places.

Showing no errors is a separate argument entirely, and was addressed by the parent poster (noImplicitAny). I will add that I always use TypeScript with --noImplicitAny which indeed does result with TypeScript DEMANDING type annotations for arguments. Of which you complained:

> Having to declare types on everything even if it's just generics beats the productivity argument.

and to which I respond that

1. its not everything, just function arguments

2. its better to demand function argument types than to show unhelpful error locations.

Implicit any is (was) useful for the early migration phase of the project. At that point you (had to) rename everything from JS to TS to use the compiler, and would get a type error for every unannotated function (which might not be a type error at all). The TS team had to choose between:

1. spending a lot of time and effort to get proper deep unification like Flow's working at acceptable performance in a single-threaded process, even without incremental recompilation, or

2. default to a loose "type checker" and provide a gradual tightening valve for users - at the cost of demanding a bit more annotations: for function arguments (and only if the function is not a part of a single expression or statement where the type can be inferred - e.g. types will be inferred for lambdas passed as function arguments)

(1) may have been worth it if it actually resulted with useful error messages, however as demonstrated above, it often doesn't. So they went with (2), and I'm glad they did - otherwise I'd have to deal with mostly-unannotated TypeScript codebases that produce useless error messages every time you do some sort of refactoring, or enforce type annotations via conventions / code reviews / linters.

Flow's inference is a beautiful marvel of engineering, really, and the type system avoided some legacy TS pitfalls (has safer treatment of nulls, proper union and intersection types from the start) but I'm afraid its not that big of a marvel of practicality.

[deleted]10 anni fa

altano10 anni fa

Why is this line an error?:

> var cats : Cat[] = [ new Cat() ]

[deleted]10 anni fa

DCoder10 anni fa

It would not be an error if not for `addToList(cats, new Dog())`. Based on that call, Flow infers that `cats` has to be a `Dog[]`, not `Cat[]`.

breck11 anni fa

"For example, for a quick ES6 to ES5 downlevel conversion using the TypeScript compiler, you just need the following command: > tsc --allowJs --outDir out target_file.js"

Is the intent here to allow tsc to be used as a replacement for babel?

scott_o11 anni fa

I don't think so. Last time I checked they don't do any polyfills, instead relying on commonJS for that.

nikolay11 anni fa

I am really puzzling what is Microsoft trying to accomplish here? Eventually a C# that compiles to JavaScript? TypeScript is a great language, and surprisingly (or not) it's more successful than Dart. Now, of course, I want TypeScript to compile to CLR as well. :)

Analemma_11 anni fa

I think people read into TypeScript too much. It's just a "right-now minimal-hassle" way to make front-end dev's lives easier, nothing more.

Maybe Microsoft disagrees, but I see TypeScript as something intended to make itself obsolete: eventually, when all browsers are running ES9 (or whichever version we decid has fixed "all" of JavaScript's problems) or WebAssembly (and we're all writing front-end code in C#/C++/Ruby/whatever), then TypeScript will just fade away, by design. For now, it's kinda like JQuery in motivation if not literally architecture: it shields you from browser inconsistencies (in this case, where you don't know what ES version the target is running) and helps you avoid JavaScript's headaches. Just as JQuery became less necessary as time went on-- not because it got worse but because browsers got better-- so too will TypeScript.

qaq11 anni fa

by the time all the browsers will run ES(x) ES(y) will be out and everyone will be transpiling ES(y) to ES(x). Given the developer base it's very unlikely to go away.

wx19611 anni fa

In what way it is more successful? Both TIOBE and Redmonk don't confirm your thoughts. http://sogrady-media.redmonk.com/sogrady/files/2015/07/lang-... http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

nikolay11 anni fa

I meant as a mindshare. Given Dart is older, it's just a matter of months for TypeScript to catch up and beat it in these indirect charts as well.

stupidcar11 anni fa

TypeScript is older. It was first released in 2012, whereas Dart was released in 2013.

Dart arrived with much fanfare though, whereas TypeScript was more low-key, and it's taken a while to become mainstream. Google's announcement that Angular 2 would use it has brought it a lot more attention from outside of the traditional MS/.NET dev crowd.

Microsoft have also been shifting the project's focus towards a more Babel-esque one, emphasising greater interoperability with existing (untyped) JS libraries, and support for new ES6/2015 features (and beyond).

carussell11 anni fa

Don't know what you're referring to. Dart's release was well past by the time TypeScript debuted.[1] Dart was announced in 2011.[2][3] The only significance that 2013 has to Dart that I know of is that's when Dart 1.0 was released. If that's what we're measuring, TypeScript's 1.0 coincided with Build 2014—still later than Dart's corresponding date, and among other things, that would mean we could say Rust is less than a year old, even though it predates both.

1. https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-...

2. https://news.ycombinator.com/item?id=3092558

3. https://www.youtube.com/watch?v=M0lfNw8Tyhc

stupidcar10 anni fa

Fair enough, I was going by the "first appeared" date for both languages on Wikipedia.

tkubacki10 anni fa

I think Dart and TS will have more or less same audience - and both have their advantages. For me TS is just worse than Dart - not as elegant IMO (all in all - JS superset) and Dart has own VM on server, own consistent packaging system and good non-windows IDE support (Webstorm, IntelliJ).

altano10 anni fa

> Eventually a C# that compiles to JavaScript?

That actually existed internally at MS, along with many other projects to improve developing large JS codebases, most of which have fallen by the wayside. There was even a Flow-like compiler that worked with type annotations in comments. TypeScript has won out, although there is a LOT of code written in these other projects.

itslennysfault10 anni fa

TypeScript is a proper superset of JavaScript so it's an easy choice over dart IMO (even google's angular2 team chose it).

tkubacki10 anni fa

typescript is MS incompatible JS fork - Dart is clean new lang - that makes Dart easy choice over typescript IMO

pippy11 anni fa

I love TypeScript - it's my favorite precompiled language and I use it for a few personal projects of mine. But I can't help but feel it's an evolutionary dead end. asm.js / web assembly is what you want transcompiled languages to target

moonchrome11 anni fa

Asmjs/webasm are orhogonal to TS - they even have to manually manage memory

peteretep10 anni fa

I don't really understand your comment. What about Typescript precludes it from targetting web assembly or asm.js in the future?

ybx11 anni fa

Someone in Mozilla came up with a language called LLJS, that took full advantage of and compiled down to asm.js.

It looked like it had some promise, since it wasn't nearly as heavy as emscripten, but I don't think much has happened with it since it was created.

pippy11 anni fa

Interesting, I've only ever known about Emscripten based asm.js compilers. TypeScript + LLVM have the benefit of being actively developed with a strong community backing.

_pmf_10 anni fa

It would be refreshing if the ES evolution would take some hints from TypeScript instead of satisfying the perceived need for syntactic sugar and cutesey poor man's FP.

VeilEm11 anni fa

> While React has paved the way, JSX syntax is not only tied to React.

Does TypeScript manage the lifecycles of elements you create through their version of JSX? React creates an in memory version of the DOM and reconciles changes to the DOM against this. Is TypeScript doing this too or is this simply template syntax inside JavaScript? What React does is not simply template syntax. HTML and JSX are totally different things! JSX renders to HTML eventually, but there's way more going on.

saidajigumi11 anni fa

According to https://github.com/Microsoft/TypeScript/wiki/JSX, there are two JSX processing options. The first is a JSX passthru ("preserve" mode) and the second ("react" mode) will generate React.createElement, etc. See that page for the technical details.

As such, preserve mode is intended for use with other backends, e.g. those listed under Transpilers at https://facebook.github.io/jsx/. Whichever non-React backend you choose therefore defines the JSX runtime handling rather than having that baked into TypeScript.

orf11 anni fa

I think you're misunderstanding the feature, see here for more info: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

Guillaume8611 anni fa

You're mixing up React and JSX. Typescript do not replace React, it just allows JSX syntax and transforms it to javascript for you if you want.

WorldMaker10 anni fa

Also, Typescript type checks the JSX. This was the big thing that convinced me to start using TSX was typed views. (I've not been using React, so I've been using preserve behavior and Babel to feed the Virtual DOM library I am using.)

[deleted]11 anni fa

crudbug11 anni fa

When can we see CoreCLR backend for TypeScript ?

chinhodado11 anni fa

What do you mean by that?

crudbug11 anni fa

Current TS is targeting JS backend. CoreCLR backend would mean you will have a unified codebase both on browser and server (CLR VM).

dham10 anni fa

Not sure I follow. You can use Typescript on the server already with Node.js. The CLR isn't available in the browser.

girvo10 anni fa

I'm guessing parent means compiling TypeScript down to CoreCLR bytecode instead of to Javascript and running through Node for execution. Pretty big job, that one.

crudbug10 anni fa

Not running through Node, Just run CoreCLR TS code as a backend server similar to ASP.NET

girvo10 anni fa

Sorry, I wasn't clear, that's what I meant. I was using running the code through Node as the current situation, and trying to communicate you meant the opposite of that :)

scotty7911 anni fa

Still no love for typing of `this` or `call()` and such

Ycros10 anni fa

Can you elaborate on what you mean by that? 1.7 added 'this' typing improvements, and it looks like 1.8 is adding 'this'-based type guards.

scotty7910 anni fa

I mean, when specifying function type, you can't specify type of `this` that the function expects to be run with. And `call()` expects thisArg:any, ...args:any[] for all functions regardless of their declared parameter types and expected type of `this`.

I'm talking about the usual js `this`, the covertly passed parameter, not typescript `this`, type of own class.

Funny they focused so much on classes that they reached 1.8 without so much as touching js most unique feature, flexible `this`.

z3t410 anni fa

I think type-script is great. But what's true for every bug that ever existed!? It passed the type checker!

slantview11 anni fa

https://xkcd.com/927/

jbrantly10 anni fa

I don't think this applies. I don't believe anybody else was doing what TypeScript does when it was released, that is JavaScript + Type Safety. Even today the only other real contender is Flow.

[deleted]10 anni fa

johnny_reilly10 anni fa

What jbrantly said. I love JavaScript and I love optional static typing. That's exactly what TypeScript provides.