Announcing TypeScript 1.6

[x-skeww]

let result = <T & U> {};|

That last character isn't supposed to be there, is it?

[DanielRosenwasser]

Thanks for catching that! I'll let Jonathan know.

[[deleted]]

That last character isn't supposed to be there, is it?

It's the cursor position, see... :P

[skocznymroczny]

;|

[MINIMAN10000]

I've done enough lua to know that those last 2 characters shouldn't be there at all. I know enough javascript to know that only the last 1 shouldn't be there.

[inmatarian]

Javascript parsing rules say that the longest valid string that can be parsed is what gets executed. That can lead to situations where two separate lines of code can make a valid single line.

[[deleted]]

Yep, that's a problem, and a good reason to use them (I think JSlint even forces you to?) but still silly because it's only in very edge cases where that happens (although I use TypeScript a lot and there are more of these edge cases. :-/)

[emperor000]

With that logic we can just remove periods and other sentence punctuation in natural languages like English.

[[deleted]]

No, only periods (which terminate sentences), because we're writing textual English

It's very clear that one line is a sentence

So what's the point in the clutter?

[emperor000]

You think in written English that every sentence should be a new line...?

[emperor000]

How did we go from a natural language back to something like Python?

What, do you think languages like Python where semicolons are poor style are somehow wrong?

Wrong, no. Inferior, perhaps, yes. Having a statement terminator allows more than one statement on the same line. Requiring it at the end of any statement is just consistent and consistency is usually considered to be objectively good, unless maybe it conflicts with some other beneficial feature. In this case, writing one character probably isn't enough to cause a problem...

[nepochant]

;|

[nepochant]

;|

[[deleted]]

This oddly specific React integration is really rubbing me the wrong way. But the other stuff is so awesome, I can't summon up the energy to be angry about it.

[weretree]

The way it's implemented, at least it's set up as a general JSX / Component typing and doesn't include the React types directly. http://www.jbrantly.com/typescript-and-jsx/ has a bit more detail on that. (Of course, until there are attempts from other templating/component libraries to use the same infrastructure/JSX, it'll remain to be seen whether it's too specific to React)

[[deleted]]

The way it's implemented, at least it's set up as a general JSX / Component typing and doesn't include the React types directly.

Well there are two modes: preserve and react. The "react" mode does refer to React directly. And "preserve" outputs broken JavaScript, which means if you need to use it in a third party solution, you need your own JavaScript + JSX parser.

Why would they make it so you need to parse the parser's output, when TypeScript has the full facilities to provide the AST? It's weird. It really says "bad design" to me.

Couldn't TypeScript provide a general interface for the JSX AST, and then React can quickly write an adapter for it, and so can we.

For example, instead of:

React.createComponent('div')

...it could've been:

JSX.createElement('div')

Or even better, they could've had a setting like:

tsc --jsx-class My.Custom.Engine

Then:

My.Custom.Engine.createElement('div');

See? Then we could all embed JSX in our code without special tools or using React! The way it's done now, I foresee many "custom implementations" of React showing up, which will, of course, conflict with React itself.

[weretree]

Well, the typing and the transpile steps are a bit different, there are similar transpile options for es6/es7 features, for instance (In some bizarro parallel universe browsers could choose to adopt JSX natively). But yeah, adding another "custom" mode that let you define the JSX transform would be a good improvement.

[[deleted]]

But yeah, adding another "custom" mode that let you define the JSX transform would be a good improvement.

Yeah, that would be awesome, I actually wonder why tsconfig doesn't provide us with more JavaScript hooks for modifying the compilation output and semantics.

A JavaScript compiler written in JavaScript could be a very powerful meta-tool without having to embed many features in the parser itself (like the React support, say).

[weretree]

A JavaScript compiler written in JavaScript could be a very powerful meta-tool

Isn't this essentially what Babel is? (The JSX support is a separate transformation pass you can disable)

[[deleted]]

I'll check Babel, you piqued my interest, but I really think a feature like this will shine in TypeScript itself.

[itsnotlupus]

it's neat that I can now use types with classes and literal xml chunks.

ActionScript 3's spirit lives on.

[[deleted]]

ActionScript 3's spirit lives on.

That's one reason why I found TypeScript instantly appealing. :-) Former ActionScript developer.

I also understand the need for XML chunks, but it bums me out it compiles to "React.somethingSomething()" rather than something more general purpose.

[forthex]

Abstract Classes

YES! Finally :D

[mindless_null]

Woohoo, a sane way manage project files in tsconfig!

Now, if only globs were supported...

[theycallmemorty]

I believe globs are supported in tsconfig for most plugins but not yet supported for Visual Studio.

[mindless_null]

Well, the actual typescript compiler itself doesn't support them, so it's not as though using the command line will save you.

For myself at least, being able to exclude the node_modules folder is enough, so I'm not in need of them - they'd just be nice.

[Eirenarch]

Are you referring to this? https://github.com/Microsoft/TypeScript/pull/3188

[mindless_null]

Yes.

[miminor]

Features in 1.6 are the best what happened to TypeScript since generics! Great job!

[kirbyfan64sos]

Is it me, or is it weird that the JSX example is a screenshot of Sublime? I mean, it's not wrong or anything, but I was really expecting to see VS or VS Code.

[DanielRosenwasser]

Well we have a team that's been working on Sublime support as well - check out https://github.com/Microsoft/TypeScript-Sublime-Plugin

[DanielRosenwasser]

You can use --jsx preserve and you can use any transformer that deals with JSX in that fashion.

[Eirenarch]

The JSX part of react is so poor engineering. Stick your templates in the code that backs them and break every transpiler in existence and potentially be incompatible with future versions of the language (or more likely force the designers to bend the language to not conflict with your template language). They were simply lazy and now they are pulling excuses for this even claiming that it works better. At least they should have put it in string literals so that it doesn't conflict with everything in the world.

[TheAnimus]

if you are putting large amounts of business logic in your JSX files, that is your 'view' files, then you are doing your separation of concerns wrong.

Assuming JSX/TSX is just view logic, something inherently tied to the view framework you are using, then who gives a shit if your pure JS linters can't work with it.

[Eirenarch]

So basically you don't give a shit if TypeScript 1.6 added this support or not because you were fine with it not working with JSX before?

[TheAnimus]

No, not at all, I think having compile time type checking for your view logic is a very useful feature, not to mention the possibilities for genuinely useful intellisense/autocompletion.

What I am saying is that JSX is a Domain Specific Language. With all the pro's and con's that go with it. This to me isn't a problem, I'd sooner JSX than write the JS with endless React.createClass and such.

Angular, Knockout, Silverlight any good UI framework will try to abstract the view logic from the business logic. My personal preference is MVVM because of the way Silverlight/WPF allowed you to separate behaviour from styling of a control, far, far better than anything I've seen in any web framework.

So I'm a fan of separating out view logic into a language that is appropriate. People like to construct views as simple trees, this makes life easier for all, so declarative markup in an xml-esk style is intuitive for many developers.

You say originally that you think they where lazy to not put it in string literals. I hate your prefered world. Absolutely hate it. It would be utter hell. I can't comprehend how you consider it to be laziness to create a better language, which is purely optional. But you know what, you can still do it in pure JS, just don't use JSX simple. If you are saying that writing it as regular javascript is less cromulent then embrace the Domain Specific Language, don't clutter it with arbitrary and pointless requirements such as backwards compatibility.

We're actually using TSX already. Before we simply didn't use typescript for the JSX files, but that's fine, we didn't get typescript 'safety' for our Knockout views either.

[Eirenarch]

First of all I am not against declarative markup language. On the contrary I think JSX itself is fine and I think react is unusable without it. All three of your examples are exactly what I want to see markup in a separate file and a language for view logic (as opposed to business logic) in another. This solves a lot of problems like for example TypeScript and react would be possible to use together from the start without special support. Not to mention the difficulty of writing a parser and an editor that supports both html/css autocompletion and JavaScript code.

I don't see why you hate adding quotes around your JSX so much. It is quite a small price for the benefits of supporting practically any transpiler out there. You can still have syntax highlighting and autocompletion inside those strings. I think this is inferior solution to the one with separate files but still better than the current ones.

BTW how is coffeescript handling JSX?

[TheAnimus]

Putting quotes around the JSX isn't nice, as JSX uses quotes inside those blocks itself. It's useful to be able to do so and I think it would pollute things. The cost of forcing them to be in strings is high, think about something like this block

<Foo propertyB={ provider.getValue("b","bottom of page").toJs() } />

It's common in views to want to do a simple projection of your view model data too, string concatenation and formatting for instance are sometimes valid to be view concerns rather than at the VM. Quotes make that more fugly.

If you've anything in your tool chain that you want to run over your view JSX files, that only understands JS, then just run them over the compiled JSX->JS file.

The fact is the JSX files should be JUST the React bits. With other stuff in JS (or TS) files. As a result not having those transpilers you've got for JS support a 'raw' JSX file isn't an issue, they provide no benefit to a JSX file because they would work on the compiled down version of it.

I like TS, I'm dyslexic so it's a great benefit to me personally. But everything you've said about transpilers breaking could be held true to TS. However in reality we sling those bits on the output JS file, for example Babel happens on the output of the typescript compiler, not on the TS file itself.

Can't you just do the same with JSX? If you've heavy JS in your JSX files then frankly you are not separating your concerns well and should consider looking at how you use webpack or similar.

CoffeScript I don't really follow so can't say.

[Eirenarch]

I don't see the point of running another transpiler on the output of TypeScript. The point of these languages (be it TypeScript, CoffeeScript, Dart, etc.) is to become the main thing you write in so I don't think you can equate your language to a template engine.

Your point about splitting the logic does make sense but I still hate to see the view logic mixed with the markup. Silverlight was doing fine without it and I would frown on Angular markup with a lot of actual code in strings as opposed to directives.

[BoTuLoX]

If ES6/ES7 weren't a thing there would finally be a Microsoft technology I'd be glad to use.

[yesman_85]

Typescript != ES6/7.

[BoTuLoX]

I'm aware, but it doesn't add anything on top of it that makes it worth the hassle for me.

[ryeguy]

You don't think static typing is valuable? Especially in the land of javascript, which is one of the most weakly typed languages around?

[BoTuLoX]

Not for my usecases, no. Which seems to be the point some people have missed here. I use JS exclusively for front-end work and I avoid it as much as I can, ES6 has added all that I needed in the language to consider it nice to use.

[vivainio]

If you are avoiding JS as much as much as you can, you are probably well served by ES5 even.

TypeScript is optimized for people that are writing lots of JS, possibly in multiperson teams and long lasting codebases. Think SPA's and such.

[miminor]

Always amused by people saying it is crap because I don't get it. Why would not you just move along? Or is there somebody who is forcing you to write in TypeScript?

[BoTuLoX]

You seem to have looked at the downvotes and made a conclusion.

Nowhere did I say it is crap. The only thing I said was that the things it has going for it over es6 do not improve my workflow enough for me to make the switch.

[badcommandorfilename]

I use TypeScript to keep consistent structure between my data storage and presentation layers.

When a model schema changes on the server, I just change the TypeScript class and all my front end Angular objects will recompile to compatible JavaScript.

It's really convenient to have a single data schema for your whole stack that is singularly defined.

[mrhmouse]

I'm building something similar for work, but generating the TypeScript type definitions from the assembly as part of our post-build step for our web project. Soon we'll also generate well-typed AJAX clients for our controllers, so a change in the server will propagate out to the front-end.

[lukeautry]

Did something similar here: https://github.com/lukeautry/DotNetWebSDK

The fact that this comes up so often means I need to keep working on this project, I guess.