Announcing TypeScript 1.5(blogs.msdn.com)
blogs.msdn.com
Announcing TypeScript 1.5
http://blogs.msdn.com/b/typescript/archive/2015/07/20/announcing-typescript-1-5.aspx
89 comments
When I was coming up as a programmer I had a manager who took a "belts and suspenders" approach to software development. Adding types to JavaScript is not necessary, but I sleep better at night knowing my code is that much closer to being correct.
I used to feel safe with types as well, until I realized every bug found in production did pass the type checker and the full test suite.
To me, explicitly managing state and keeping parts of the system decoupled and simple to understand is now what I require in order to sleep peacefully at night.
A type system can help with this, but not that much.
To me, explicitly managing state and keeping parts of the system decoupled and simple to understand is now what I require in order to sleep peacefully at night.
A type system can help with this, but not that much.
That's just Selection Bias - the bugs that fail the type checker don't get into production!
I would be interested to hear other folks experience with TypeScript. We have move virtually all of the project I work on over to TypeScript but I am not seeing metrics improve (less bugs, quicker to fix etc). Gripes include lots of boilerplate TypeScript being generated and another learning curve for new starters (nearly everyone knows JS).
What are other folks experiences? Has it helped or hindered?
What are other folks experiences? Has it helped or hindered?
I started 2 months ago a big project using TypeScript on NodeJS ( I'm freelancer and I'm building an API Service for a company ).
CONS:
1. Contribute a couple of times to DefinitelyType repo, because I needed definitions that doesn't exist or modify existing ones with their updated versions ( this is really pain in the ass at this point, because you will most certainly end up using definitions that either doesn't match your version number or are poorly written ).
2. Report a couple of bugs to WebStorm 10 team ( I'm eagerly waiting for WS 11, which they say will improve the typescript support ).
3. Explain to my clients why I am using a beta version of a software for their precious product ( this is not a problem since today :) )
4. Sometimes the flexibility of typescript can slow you down a lot if you want to go deep with the proper typings and interface declarations. I actually spend a lot of time thinking how to organize my classes and interfaces now, instead of writing code.
PROS:
1. Code looks solid and professional ( CoffeeScript on the other - I was so much faster, but in the end I see not that easy readable code. )
2. Creating documentation is way easier ( using typedoc ). I never understood JSDocs as a pro and usually I spend lots of time on properly annotating, which is unneeded in TS.
3. There is no need to write `function(options) { if ( !options ) { throw new Error("Options required"); } }`. this becomes `function(options : Object) {}`. This removes a lot of boilerplate and really cleans many of those typesafety checks from your code.
4. I'm catching far more errors in the compilation phase than ever before ( see 3 ). I'm also not writing any typesafety tests for my modules ( I was so happy, when I realised that! ).
CONS:
1. Contribute a couple of times to DefinitelyType repo, because I needed definitions that doesn't exist or modify existing ones with their updated versions ( this is really pain in the ass at this point, because you will most certainly end up using definitions that either doesn't match your version number or are poorly written ).
2. Report a couple of bugs to WebStorm 10 team ( I'm eagerly waiting for WS 11, which they say will improve the typescript support ).
3. Explain to my clients why I am using a beta version of a software for their precious product ( this is not a problem since today :) )
4. Sometimes the flexibility of typescript can slow you down a lot if you want to go deep with the proper typings and interface declarations. I actually spend a lot of time thinking how to organize my classes and interfaces now, instead of writing code.
PROS:
1. Code looks solid and professional ( CoffeeScript on the other - I was so much faster, but in the end I see not that easy readable code. )
2. Creating documentation is way easier ( using typedoc ). I never understood JSDocs as a pro and usually I spend lots of time on properly annotating, which is unneeded in TS.
3. There is no need to write `function(options) { if ( !options ) { throw new Error("Options required"); } }`. this becomes `function(options : Object) {}`. This removes a lot of boilerplate and really cleans many of those typesafety checks from your code.
4. I'm catching far more errors in the compilation phase than ever before ( see 3 ). I'm also not writing any typesafety tests for my modules ( I was so happy, when I realised that! ).
One thing to note about your third pro (removing boilerplate type safety) is that if other code outside your TypeScript ecosystem starts calling your code, the lack of checks could hurt them.
Agreed on the points listed. Typescript really helps with code being more solid and professional. We have a large-ish server application written in typescript the really benefits from the OOP principles that typescript enforces. Some initial investment upfront from learning curve and thinking about proper architecture like you mentioned, but really pays dividends over time for adding features or making major changes.
Moving to TypeScript definitely helped us. The move itself revealed a couple undefined variable errors, and static typing has saved us a lot of pain. It was also extremely useful for when we decided to remove a few libraries; the static typing gave us confidence that we didn't miss a few usages.
My experience as well. The benefits I've seen have been easier refactoring, code completion and I find it faster to implement things with typescript highlighting issues in my editor so that I can correct them before seeing if it runs in a browser.
You can catch undefined variables with something like eslint or jshint.
We love TS here, and share the same experiences about finding bugs just in the conversion phase.
What I think is the best part though, and it helps when bringing new people in, is the crazy-good intellisense you can get in Javascript now.
Basically it makes averages developers much better, and skilled developers a bit better. Master level folks may just find some boilerplate generated code annoying, but for my definition of "Master" there aren't many of them around anyway (at least not where I work).
What I think is the best part though, and it helps when bringing new people in, is the crazy-good intellisense you can get in Javascript now.
Basically it makes averages developers much better, and skilled developers a bit better. Master level folks may just find some boilerplate generated code annoying, but for my definition of "Master" there aren't many of them around anyway (at least not where I work).
x2 on the intellisense.
When I moved my team's JS code to typescript, I found myself way way faster with the improved intellisense.
I wrote most of the code originally and understood it well, but even for an experienced developer, solid intellisense saves you from having to look up so many things.
When I moved my team's JS code to typescript, I found myself way way faster with the improved intellisense.
I wrote most of the code originally and understood it well, but even for an experienced developer, solid intellisense saves you from having to look up so many things.
In general, I suspect you'd get more benefit from starting new projects with TypeScript than "converting" existing ones.
The module/class/types system tends to push you in certain direction for your overall design, compared to a more amorphous vanillaJS.
Even then, the language features don't replace coding rules and discipline. To pick one feature, protected and private members are little more than polite suggestions in typescript, and can be bypassed easily if that's culturally acceptable in your dev team, losing the benefit of well defined interfaces between chunks of code. If Typescript feels generally useless and even a hindrance to a team, it's very possible that team is working outside of the bounds Typescript is meant for. For example, I can certainly imagine a tight knit bunch of crazed coders writing fantastic JS code that really doesn't fit in a java-like development model. If that's the case, you'd probably want to think about why your team migrated to Typescript in the first place, and what you were hoping to gain from it.
The generated boilerplate complaint surprises me a bit. Typescript produces very little extra code, and has almost zero runtime overhead. There's an 5 liner __extends helper function, but that's about it. Most of the time, a line of TS maps to an essentially identical line of JS. I understand that's becoming less true with the fancier syntactic sugar of recent releases, but we're still in the same general ballpark. (and of course, the extra code melts away if you're able to target higher ES versions.)
The learning curve bit really depends on your team's background. Folks coming from many non-JS language will have been exposed to modules/namespaces, classes and types. They will be able to write reasonable code with typescript for a while before even realizing JS has this strange and intriguing prototype mechanism, although it can be a bit of a shock when the day comes, and an ancient JavaScript bearded one sits them down and gives them The Talk about what lurks in the basement.
The module/class/types system tends to push you in certain direction for your overall design, compared to a more amorphous vanillaJS.
Even then, the language features don't replace coding rules and discipline. To pick one feature, protected and private members are little more than polite suggestions in typescript, and can be bypassed easily if that's culturally acceptable in your dev team, losing the benefit of well defined interfaces between chunks of code. If Typescript feels generally useless and even a hindrance to a team, it's very possible that team is working outside of the bounds Typescript is meant for. For example, I can certainly imagine a tight knit bunch of crazed coders writing fantastic JS code that really doesn't fit in a java-like development model. If that's the case, you'd probably want to think about why your team migrated to Typescript in the first place, and what you were hoping to gain from it.
The generated boilerplate complaint surprises me a bit. Typescript produces very little extra code, and has almost zero runtime overhead. There's an 5 liner __extends helper function, but that's about it. Most of the time, a line of TS maps to an essentially identical line of JS. I understand that's becoming less true with the fancier syntactic sugar of recent releases, but we're still in the same general ballpark. (and of course, the extra code melts away if you're able to target higher ES versions.)
The learning curve bit really depends on your team's background. Folks coming from many non-JS language will have been exposed to modules/namespaces, classes and types. They will be able to write reasonable code with typescript for a while before even realizing JS has this strange and intriguing prototype mechanism, although it can be a bit of a shock when the day comes, and an ancient JavaScript bearded one sits them down and gives them The Talk about what lurks in the basement.
The ability to rename a function or class attribute, accross modules, has been a great help maintaining programs larger than a few thousands lines.
Typescript definitely helped on all the projects I've used it.
The main con is that sometimes things are not very clear and you might end up spending time on something that typescript can't handle (eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled).
The pros:
- being able to refactor stuff easily with the compiler telling you
- catch typos easily (I remember watching Dan Abramov video at react europe and some of the errors he showed would be a compilation error in TS)
- if you maintain all your classes/object definitions in one file (except maybe stuff like state of a React component which doesn't need to be shared), you have all your types at one place and anyone can come in and have a clear view of the project: I had someone come help me on a previous project and it took him basically no time to get a grip on the project structure/models
- DefinitelyTyped so you can also type your calls to third party libraries and what they return
Make sure to only use ES6 imports (no internal modules) and it's pretty close to babel but with types.
The main con is that sometimes things are not very clear and you might end up spending time on something that typescript can't handle (eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled).
The pros:
- being able to refactor stuff easily with the compiler telling you
- catch typos easily (I remember watching Dan Abramov video at react europe and some of the errors he showed would be a compilation error in TS)
- if you maintain all your classes/object definitions in one file (except maybe stuff like state of a React component which doesn't need to be shared), you have all your types at one place and anyone can come in and have a clear view of the project: I had someone come help me on a previous project and it took him basically no time to get a grip on the project structure/models
- DefinitelyTyped so you can also type your calls to third party libraries and what they return
Make sure to only use ES6 imports (no internal modules) and it's pretty close to babel but with types.
> eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled
Typescript 1.4 to the rescue with union types!
Though I would argue that if this is code you're writing yourself, a function that returns multiple types is bad design. Though given the prevalence of different types for different strings, the way they've typed things like addEventListener is interesting.
Typescript 1.4 to the rescue with union types!
Though I would argue that if this is code you're writing yourself, a function that returns multiple types is bad design. Though given the prevalence of different types for different strings, the way they've typed things like addEventListener is interesting.
It actually didn't work with 1.5 beta, can't remember the exact failure. This function actually returns an object depending on the single param, an enum member. All the objects are extending a main type with a couples different properties on each, it's cleaner than having a switch everywhere i want to instantiate one ofthose
There is definitely a learning curve, and sometimes it can feel like you're fighting against TypeScript instead of having it work for you. However, there have definitely been cases of it being useful. Upgrading from React v0.12 to v0.13 was great because I immediately saw all of the places where the API needed updating. I think moving forward much of the friction will slowly removed (added ES6 features, JSX support, etc).
If you're using a typed server language, or can get typed API definitions you can get through stack compile time safety. Writing an ASP.Net MVC application using Entity Framework I can now have a DB change go into my C# and then into Typescript thanks to T4 templates like Typelite.
The other aspect is that if you're a C# shop it is so similar as to reduce the learning curve. Especially if you want to write OO front end code.
The other aspect is that if you're a C# shop it is so similar as to reduce the learning curve. Especially if you want to write OO front end code.
To add to what everyone else is saying: I started using TS back in the 0.8 days, before generics were a thing. Since then, I have built several projects with TypeScript and migrated one JavaScript project to TS. These projects also involved Knockout, WebSQL, jQuery and other extras. Along the way, I got most of my colleagues hooked as well. When a new project starts up, the question is usually " Is there a compelling reason to use plain JavaScript instead of TypeScript here? ", not the other way around.
The good parts :
* The type system serves as a great safety net and prevents a whole class of bugs.
* Intellisense is far smarter than you would get from JavaScript (no more silly IDEs with both jQuery's .append() and DOM's .appendChild() in the same intellisense suggestion). This enables refactorings and intelligent assistance such as Find All References, which is much more brittle in plain JS.
* Classes are much more convenient and readable than old-school inheritance solutions. Those old solutions were also a huge problem for JS intellisense.
* AMD Modules paired with Require.js are much more centralized than "add these fifty script tags to the HTML document, in the right order". That's more due to AMD, but TypeScript adds some nice syntax sugar on top of that.
* Arrow functions. No more `var that = this` to keep callbacks working.
* Generics, function overloads, etc. - depends on the things you use in your code. If most of your viewmodel properties are Knockout Observables, generics are a life saver. If you're chaining Promises, again, generics can cover their return/param types. Function overloads come in handy if you have factories building objects based on string parameters (example: document.createElement() returns different classes based on the name passed in). And so on.
The bad parts :
* New language to learn. And it keeps evolving.
* Requires an additional build step. There's a large amount of small projects without any build process out there - integrating TS into such a project can be difficult and open a new can of worms related more to the build process than TS (e.g. "do you commit the generated JS and sourcemaps, or provision a build server to package them?"). Of course, if you're already using Grunt/Ant/Phing/whatever else, this is not a big problem. (You should be using a build process at least to aggregate your JS into one blob, if nothing else.)
* Definitions for third-party libraries. DefinitelyTyped helps a lot here, but there are still things that it doesn't cover, and it can be time-consuming to keep a definition file in sync with a library as the library updates.
* IDE support. After using PHPStorm/IntelliJ and Visual Studio Express/Community, Visual Studio wins hands down. IntelliJ's support was quite disappointing and glitchy, especially its lack of intellisense. Visual Studio Code, Community and Express are all free, but the latter two are quite bulky and running them alongside a different IDE can be slow.
* Debugging can be a bit challenging due to sourcemaps, depending on the target browser. I prefer to disable sourcemaps and debug the generated JS directly, but that requires some mental juggling and is not everyone's cup of tea.
The good parts :
* The type system serves as a great safety net and prevents a whole class of bugs.
* Intellisense is far smarter than you would get from JavaScript (no more silly IDEs with both jQuery's .append() and DOM's .appendChild() in the same intellisense suggestion). This enables refactorings and intelligent assistance such as Find All References, which is much more brittle in plain JS.
* Classes are much more convenient and readable than old-school inheritance solutions. Those old solutions were also a huge problem for JS intellisense.
* AMD Modules paired with Require.js are much more centralized than "add these fifty script tags to the HTML document, in the right order". That's more due to AMD, but TypeScript adds some nice syntax sugar on top of that.
* Arrow functions. No more `var that = this` to keep callbacks working.
* Generics, function overloads, etc. - depends on the things you use in your code. If most of your viewmodel properties are Knockout Observables, generics are a life saver. If you're chaining Promises, again, generics can cover their return/param types. Function overloads come in handy if you have factories building objects based on string parameters (example: document.createElement() returns different classes based on the name passed in). And so on.
The bad parts :
* New language to learn. And it keeps evolving.
* Requires an additional build step. There's a large amount of small projects without any build process out there - integrating TS into such a project can be difficult and open a new can of worms related more to the build process than TS (e.g. "do you commit the generated JS and sourcemaps, or provision a build server to package them?"). Of course, if you're already using Grunt/Ant/Phing/whatever else, this is not a big problem. (You should be using a build process at least to aggregate your JS into one blob, if nothing else.)
* Definitions for third-party libraries. DefinitelyTyped helps a lot here, but there are still things that it doesn't cover, and it can be time-consuming to keep a definition file in sync with a library as the library updates.
* IDE support. After using PHPStorm/IntelliJ and Visual Studio Express/Community, Visual Studio wins hands down. IntelliJ's support was quite disappointing and glitchy, especially its lack of intellisense. Visual Studio Code, Community and Express are all free, but the latter two are quite bulky and running them alongside a different IDE can be slow.
* Debugging can be a bit challenging due to sourcemaps, depending on the target browser. I prefer to disable sourcemaps and debug the generated JS directly, but that requires some mental juggling and is not everyone's cup of tea.
> New language to learn. And it keeps evolving.
A lot of the “new language” parts is ES6, stuff that will be becoming more commonly used soon and which there is value in. The parts that are actually TypeScript itself are very much more restricted and really are just bits around the type system.
A lot of the “new language” parts is ES6, stuff that will be becoming more commonly used soon and which there is value in. The parts that are actually TypeScript itself are very much more restricted and really are just bits around the type system.
I find TS to be quite productive, especially when combined with a great editor that supports it (Visual Studio Code).
To me it seems like a lot of extra cognitive overhead, though if you are using VS it may or may not be worth it. I've been using babeljs and traceur before that for transpiling combined with browserify. You can get a similar experience with more extras with webpack.
To me, simply being able to break up methods into discrete testable modules, then composing those methods into either workflows or structured utilities, you don't need the cognitive overhead of strict typing nearly as much. Unfortunately, going that route takes discipline.
What typescript and es6 tends to bring is cleaner class syntax, which imho is a detriment to the use of JS in most cases. People tend to put things into classes that really don't need to be. You data structures can be plain objects instantiated as needed (generally via JSON passing), and most of your workflow logic can again be a module that is an object which returns a composite of discrete, or at least bound/wrapped functions that themselves are independent and testable.
One thing you should probably strive for in a green project where there is a lot of JS, and multiple developers is 100% test coverage for JS. If you are having serious issues with being able to test your code, odds are your structure needs to be cleaned up. With utilities like sinon and proxyquire you should be able to shim for testing anything a method needs to be exercised.
It's also worth noting that test coverage doesn't guarantee good code, it only ensures that you've looked at every piece of code a couple of times. It's that forced review/refactor for testing that gets you thinking in terms of usability. Filling out an existing software with unit tests without refactoring as you go, only gives you some protection against regressions.
I have totally lost track of where I was going... I guess it just comes down to that, for me, TS brings the limitations in terms of testing that exist in Java and .Net and force them on JS. JS is inherently more easily testable than many other languages.
To me, simply being able to break up methods into discrete testable modules, then composing those methods into either workflows or structured utilities, you don't need the cognitive overhead of strict typing nearly as much. Unfortunately, going that route takes discipline.
What typescript and es6 tends to bring is cleaner class syntax, which imho is a detriment to the use of JS in most cases. People tend to put things into classes that really don't need to be. You data structures can be plain objects instantiated as needed (generally via JSON passing), and most of your workflow logic can again be a module that is an object which returns a composite of discrete, or at least bound/wrapped functions that themselves are independent and testable.
One thing you should probably strive for in a green project where there is a lot of JS, and multiple developers is 100% test coverage for JS. If you are having serious issues with being able to test your code, odds are your structure needs to be cleaned up. With utilities like sinon and proxyquire you should be able to shim for testing anything a method needs to be exercised.
It's also worth noting that test coverage doesn't guarantee good code, it only ensures that you've looked at every piece of code a couple of times. It's that forced review/refactor for testing that gets you thinking in terms of usability. Filling out an existing software with unit tests without refactoring as you go, only gives you some protection against regressions.
I have totally lost track of where I was going... I guess it just comes down to that, for me, TS brings the limitations in terms of testing that exist in Java and .Net and force them on JS. JS is inherently more easily testable than many other languages.
No good metrics on my end, but anecdotally, the compiler regularly catches bugs that I would have had to find via testing. So, depending on how you track bugs, these types of things might have never made it to your bug tracker, just manifested as dev time. Not that I don't have bugs, it's just catching some. Is it worth having a compile step? Not clear.
In my mind though, the main benefit is types as documentation, both for devs & tool support. Via DefinitelyTyped it makes integrating new libraries simpler. It has made refactoring much more straight forward. I started a side project on the weekend where I wanted a chrome extension, and I made that a typescript and have absolutely no regrets. I've been doing lots of regular refactoring, and while the codebase is miniscule, it's a lot more mechanical to make changes (change the type, look for red squigglies) than really needing to think about where the changes are.
But I feel like our code is very much much more navigable than just straight JS. Being able to know the type of a thing and just jump to its definition makes it that much easier to read. I might have been scarred by my previous experiences trying to read large dynamically typed projects, but you can't just jump into most files and be able to figure out what is going on (particularly with classes).
We only have one typescript codebase, which we moved to from coffeescript, and that was a huge win, partly because of coffeescript, but also because the coffeescript codebase was a disaster and needed some rework. When I originally ported it, it was about 4k LoC in a single file, and now it is 11k across 93 files. My team wasn't entirely thrilled with typescript to start, but some of the features in 1.4 (union types, typedefs) made people happier. We have some very different coding styles, from my end where I want to type everything, to the any-soup we get in some parts.
So, I can't call it an unmitigated success, some of what the codebase needed was just some general structure, but 11k isn't exactly a huge project either, and it's structure is really not very complicated (most of it is completely independent modules).
So, after all that rambling, things I like:
- code navigability (particularly because anything you do a method call tends to be typed)
- code completion
- refactoring is simple
- catches straight forward bugs earlier, rather than me finding them when I test
So, despite it having types, the main benefit has not really less bugs, it's made my life interacting with the code simpler, and it has made bugs caught by the compiler easier to track down.
I think there was a real missed opportunity to have browser definitions split up by browser version so that you could more easily specify a target set and have it show you when you use something not supported though.
In my mind though, the main benefit is types as documentation, both for devs & tool support. Via DefinitelyTyped it makes integrating new libraries simpler. It has made refactoring much more straight forward. I started a side project on the weekend where I wanted a chrome extension, and I made that a typescript and have absolutely no regrets. I've been doing lots of regular refactoring, and while the codebase is miniscule, it's a lot more mechanical to make changes (change the type, look for red squigglies) than really needing to think about where the changes are.
But I feel like our code is very much much more navigable than just straight JS. Being able to know the type of a thing and just jump to its definition makes it that much easier to read. I might have been scarred by my previous experiences trying to read large dynamically typed projects, but you can't just jump into most files and be able to figure out what is going on (particularly with classes).
We only have one typescript codebase, which we moved to from coffeescript, and that was a huge win, partly because of coffeescript, but also because the coffeescript codebase was a disaster and needed some rework. When I originally ported it, it was about 4k LoC in a single file, and now it is 11k across 93 files. My team wasn't entirely thrilled with typescript to start, but some of the features in 1.4 (union types, typedefs) made people happier. We have some very different coding styles, from my end where I want to type everything, to the any-soup we get in some parts.
So, I can't call it an unmitigated success, some of what the codebase needed was just some general structure, but 11k isn't exactly a huge project either, and it's structure is really not very complicated (most of it is completely independent modules).
So, after all that rambling, things I like:
- code navigability (particularly because anything you do a method call tends to be typed)
- code completion
- refactoring is simple
- catches straight forward bugs earlier, rather than me finding them when I test
So, despite it having types, the main benefit has not really less bugs, it's made my life interacting with the code simpler, and it has made bugs caught by the compiler easier to track down.
I think there was a real missed opportunity to have browser definitions split up by browser version so that you could more easily specify a target set and have it show you when you use something not supported though.
I think the critical point for TypeScript will be 1.6 with async/await - at this point it goes from "nice I have types now" to "OK this solves most of my problems with JS".
Looking forward to Angular 2 and TS 1.6
Looking forward to Angular 2 and TS 1.6
Is this (async/await) not just a feature of ES7?
Personally I would love to see the decoupling of TypeScript's type checker from its transpiler. The ability to use TS with Babel, or Flow with MS's transpiler, would be liberating and spur further innovation.
Personally I would love to see the decoupling of TypeScript's type checker from its transpiler. The ability to use TS with Babel, or Flow with MS's transpiler, would be liberating and spur further innovation.
You can decouple now. Set the TypeScript output target to ES6 and then pass it all through BabelJS.
It works really well for me and the TypeScript tooling is really good (VS Code or Atom).
It works really well for me and the TypeScript tooling is really good (VS Code or Atom).
How do you integrate this into a webpack build? Run the typescript plugin first, then the babel plugin? Is there issues using es7 babel stage 0 features like async/await and decorators if you do this? Thanks :-)
I think they're going in the opposite direction as they've implemented JSX support as a part of TypeScript. I mean, I love what they are doing but sometimes I wish we could have all these features as macros/plugins to something like sweet.js. By the way, IIRC, Babel also supports plugins so in theory, type-checking could be implemented as a Babel plugin as well.
IIRC JSX support is only implemented as parsing and type-checking. There is no JS generation. The output will contain the same JSX, which means you'll have to use a JSX compiler on it.
The Typescript compiler can emit JS for use with React from JSX. This is a good blog post about it: http://www.jbrantly.com/typescript-and-jsx/
You can use jsxtyper to generate TypeScript interfaces: https://github.com/fuselabs/jsxtyper
You can do it in current JavaScript implementations already: https://github.com/bjouhier/galaxy#asyncawait-in-javascript
Yes, but who has the patience to wait another 5+ years to get ES7?
> the critical point for TypeScript will be 1.6 with async/await
Is that the official plan? I ask since async/await will presumably be going into the actual JS spec, so I'd expect engines to hold off adding support except behind some kind of warning flag.
Is that the official plan? I ask since async/await will presumably be going into the actual JS spec, so I'd expect engines to hold off adding support except behind some kind of warning flag.
They won't add async/await as a direct code instructions, but as tranlated code / pollyfill.
Like Babel does, and like TypeScript does for a lot of stuff.
A lot of browser engines don't have classes either, especially any older version.
Like Babel does, and like TypeScript does for a lot of stuff.
A lot of browser engines don't have classes either, especially any older version.
I just started a new project. We were using TypeScript for some important client side communication libraries which had no UI. This new project has a lot of UI. I chose Babel since it has built-in support for JSX -- that seemed like a bigger win than type safety.
TypeScript also have JSX support. It's in master right now.
And you can use it today with unofficial "Not" TypeScript https://github.com/TypeStrong/ntypescript or simply using atom-typescript extension for Atom which has it installed.
Thanks...
I found the closed issue:
https://github.com/Microsoft/TypeScript/issues/3203
And some docs from the contributor's branch:
https://github.com/RyanCavanaugh/jsx-intro
Nothing yet mentioned in the master's markdown. Do you know when the next TypeScript release is planned for which will include this?
I found the closed issue:
https://github.com/Microsoft/TypeScript/issues/3203
And some docs from the contributor's branch:
https://github.com/RyanCavanaugh/jsx-intro
Nothing yet mentioned in the master's markdown. Do you know when the next TypeScript release is planned for which will include this?
TypeScript 1.6 will have this. Unknown release date but there is this: https://twitter.com/jntrnr/status/620607598903996417
oh man, this makes me so happy. Two projects I really really enjoy are finally coming together without any hacks. I knew it could only be a matter of time - and I had it working with a little React.jsx(`<component />`) hack, but still, having the TS team implement it natively just makes it feel right. thanks to everyone involved! ... Can't wait till webstorm will fully support this with component property intellisense and everything. woot!
You just made my day with this!!!
Shameless plug but hopefully helpful: http://www.jbrantly.com/typescript-and-jsx/
And more: http://blog.mgechev.com/2015/07/05/using-jsx-react-with-type... http://basarat.gitbooks.io/typescript/content/docs/jsx/tsx.h...
And more: http://blog.mgechev.com/2015/07/05/using-jsx-react-with-type... http://basarat.gitbooks.io/typescript/content/docs/jsx/tsx.h...
I like to use r-dom to get around JSX. I feel like, with JSX, I tend to copy-paste code or not refactor something into it's own method. With r-dom, it forces you to realize you're writing Javascript (not HTML) and try to write DRY code.
https://www.npmjs.com/package/r-dom
https://www.npmjs.com/package/r-dom
I was using babel, but the compiler seems to crash every chance it gets. It should be able to handle simple editing without anywhere near a crash.
When I first tried typescript I was disappointed with the lack of support for ES6 features like destructuring assignment, template strings, and other things I had in coffeescript.
It's nice to see that this will soon change! I'll be interested to see how some of my projects in ES6 will translate to typescript.
It's nice to see that this will soon change! I'll be interested to see how some of my projects in ES6 will translate to typescript.
What I would love to see is JSdoc annotations being output from the Ts->Js step. I already add types to everything, my api documentation should be simple to generate per function. Would be DRY and another feather in Typescript's cap IMHO.
https://github.com/Microsoft/TypeScript/issues/10
It would be great if it did.
I heard somewhere that the TypeScript team were also looking at outputting closure annotation to help the closure compiler optimize TS output.
I heard somewhere that the TypeScript team were also looking at outputting closure annotation to help the closure compiler optimize TS output.
Closure supports nullability (and non-nullability) annotations which TS does not. Otherwise it's fairly straightforward to do this already, with the current compiler API.
For those looking for a place to learn it
https://www.edx.org/course/introduction-typescript-microsoft...
I am not realted to this site in anyway, I am just using it.
https://www.edx.org/course/introduction-typescript-microsoft...
I am not realted to this site in anyway, I am just using it.
I really hate this part:
///<reference>
+1 I hate the reference tags....
the new version handles tsconfig.json, so no more need for ///<reference>
I consider myself at best a mediocre JS developer, that wants to get better. I'm interested in TypeScript but worry it would hinder my ability to improve my knowledge of the core language. I want to know how ES6 improves the language, not how TypeScript's syntax of ES6 improves the language. I know I could use regular JS files with TS but if I don't want to do any transpilation that seems redundant.
Has anybody else felt that way and did you go forward with TS or stick with vanilla JS?
Has anybody else felt that way and did you go forward with TS or stick with vanilla JS?
I felt the same until I finally broke down and did it.
Basically, if you want to use ES6 (or ES7) features and are targeting an environment that might not have native support (browsers) or inconsistent support (browsers, io.js, node.js) then you will inevitebly need or want a build step at some point. You could probably get by with some on-the-fly transpiling for a little bit but I would avoid that as a long-term solution except for maybe in tests.
I highly recommend setting up a build step in any project for BabelJS to ES5, TypeScript to ES5, or my favorite, TypeScript to ES6 to BabelJS to ES5.
Not only will you get awesome language features, you will also get some really great tooling in VS Code or Atom.
Also, it's worth noting that all of these language features are pretty much all optional so you can ease into them.
Basically, if you want to use ES6 (or ES7) features and are targeting an environment that might not have native support (browsers) or inconsistent support (browsers, io.js, node.js) then you will inevitebly need or want a build step at some point. You could probably get by with some on-the-fly transpiling for a little bit but I would avoid that as a long-term solution except for maybe in tests.
I highly recommend setting up a build step in any project for BabelJS to ES5, TypeScript to ES5, or my favorite, TypeScript to ES6 to BabelJS to ES5.
Not only will you get awesome language features, you will also get some really great tooling in VS Code or Atom.
Also, it's worth noting that all of these language features are pretty much all optional so you can ease into them.
The question to ask yourself is: Do I want static typing?
If yes, then TypeScript is quite similar to plain JavaScript and introduces this feature you want.
If no, then JavaScript should be sufficient.
If yes, then TypeScript is quite similar to plain JavaScript and introduces this feature you want.
If no, then JavaScript should be sufficient.
Considering Babel solves most ES2015/2016 needs and has support for flow, what does TS still bring to the table for people who aren't using Visual Studio?
Serious question. I last looked at TS when it had plenty of warts (e.g. verbose metadata to make imports work, no real JS API) and since switched to Babel via JSX+harmony. Flow integrates nicely and seems to be better at understanding implicitly typed (legacy) code, too. TS's main selling points seem to be VS integration and Angular's blessings.
Serious question. I last looked at TS when it had plenty of warts (e.g. verbose metadata to make imports work, no real JS API) and since switched to Babel via JSX+harmony. Flow integrates nicely and seems to be better at understanding implicitly typed (legacy) code, too. TS's main selling points seem to be VS integration and Angular's blessings.
> has support for flow
I've used both Typescript and Flow. In my experience, Typescript is far superior to Flow.
In terms of the sorts of errors they catch, they're about the same. In practice, Flow caught essentially no real errors that Typescript did not, and vice versa. (This is based on my workflow, YMMV obviously.)
However, Typescript is installable through NPM and runs as a basic Node module that reads files and parses text when you call it. Flow is written in OCaml, which means it's not available through NPM. This means either installing a separate binary (if one exists for your system) or installing an OCaml compiler so you can compile it from source. Afterwards, Flow uses a client-server setup, which makes it really annoying to run in a headless and automated environment. It's also surprisingly slow; it took a full ten seconds to typecheck a small project the first time. Supposedly the server makes it faster to do repeated checks, but honestly, the Typescript compiler is fast enough that this seems like a solution in search of a problem.
Also, Flow would keep getting confused and insisted on typechecking my node_modules. This was a problem because one of my imports had a third-level dependency with syntax error in an unused test, which meant that my entire Flow typecheck would fail. I couldn't add it to the [ignore] section of my ~/.flowconfig, because then Flow would literally pretend the file didn't exist, and then the project wouldn't compile due to missing imports!
All in all, I'm sure there's some way to set up flow without running into any of the above issues, but it definitely was way more work to set up (compared to a simple 'npm install'), and for seemingly no benefit whatsoever.
I've used both Typescript and Flow. In my experience, Typescript is far superior to Flow.
In terms of the sorts of errors they catch, they're about the same. In practice, Flow caught essentially no real errors that Typescript did not, and vice versa. (This is based on my workflow, YMMV obviously.)
However, Typescript is installable through NPM and runs as a basic Node module that reads files and parses text when you call it. Flow is written in OCaml, which means it's not available through NPM. This means either installing a separate binary (if one exists for your system) or installing an OCaml compiler so you can compile it from source. Afterwards, Flow uses a client-server setup, which makes it really annoying to run in a headless and automated environment. It's also surprisingly slow; it took a full ten seconds to typecheck a small project the first time. Supposedly the server makes it faster to do repeated checks, but honestly, the Typescript compiler is fast enough that this seems like a solution in search of a problem.
Also, Flow would keep getting confused and insisted on typechecking my node_modules. This was a problem because one of my imports had a third-level dependency with syntax error in an unused test, which meant that my entire Flow typecheck would fail. I couldn't add it to the [ignore] section of my ~/.flowconfig, because then Flow would literally pretend the file didn't exist, and then the project wouldn't compile due to missing imports!
All in all, I'm sure there's some way to set up flow without running into any of the above issues, but it definitely was way more work to set up (compared to a simple 'npm install'), and for seemingly no benefit whatsoever.
I don't wanna say that, but a language created by such a large company, which is open-sourced since day one and developed by a team of professionals with a solid research before any lines of code have been written ... sounds a like a big thing on the table for may day-to-day choices in this sea of possibilities.
I'd like to try flow but it isn't available yet on windows [1] so it's not even an option for me (I'm on windows and I like to keep my things multi-platform friendly if possible). At the moment I'm using babel in Atom and typescript in VisualStudio.
[1] https://github.com/facebook/flow/issues/6
[1] https://github.com/facebook/flow/issues/6
> what does TS still bring to the table for people who aren't using Visual Studio?what does TS still bring to the table for people who aren't using Visual Studio?
It doesn't require Visual Studio. Most major IDEs and some text editors have support either from Microsoft or the developers of the IDE/editor[1].
Also, strict typing (which I consider a huge plus for any long term large project to help make it sane).
I think it matters (though maybe not for everyone) that Anders Hejlsberg (of Delphi and C# creation fame) is behind the architecture of the language.
> no real JS API
Not sure what you mean by that, please clarify. JS notation works fine in it (since typescript is just a super set of JS and typing is optional). If you want to add types to a JS library, you just build an interface for it. Lots of examples of how to do that out there[2].
[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Edit...
[2] https://github.com/borisyankov/DefinitelyTyped
It doesn't require Visual Studio. Most major IDEs and some text editors have support either from Microsoft or the developers of the IDE/editor[1].
Also, strict typing (which I consider a huge plus for any long term large project to help make it sane).
I think it matters (though maybe not for everyone) that Anders Hejlsberg (of Delphi and C# creation fame) is behind the architecture of the language.
> no real JS API
Not sure what you mean by that, please clarify. JS notation works fine in it (since typescript is just a super set of JS and typing is optional). If you want to add types to a JS library, you just build an interface for it. Lots of examples of how to do that out there[2].
[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Edit...
[2] https://github.com/borisyankov/DefinitelyTyped
> JS API
I mean a JS interface to the transpiler. At the time there was only the CLI, nothing that worked on strings or streams within node code.
> IDE support ... strict typing ...
Ditto for flow, though.
I mean a JS interface to the transpiler. At the time there was only the CLI, nothing that worked on strings or streams within node code.
> IDE support ... strict typing ...
Ditto for flow, though.
The compiler api has gotten a lot better: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
If you just want string->string compilation, there's typestring, which wraps the api: https://www.npmjs.com/package/typestring
If you just want string->string compilation, there's typestring, which wraps the api: https://www.npmjs.com/package/typestring
[deleted]
Last time I tried flow (maybe 6 months ago?), it didn't work very well for me. I can't remember the details unfortunately.
Typescript covers pretty much all the ES6 features that I use while flow is still missing let/const apparently. I only miss async/await and that should be in TS 1.6 so it's not a big deal for me and I believe you should be able to do a TS -> Babel -> ES5 workflow if you wanted by having ES6 as target for TS. For JSX, I prefer using React.DOM anyway but support will be in 1.6 and is already in master.
TS main selling point is DefinitelyTyped which means typing for pretty much all the third party code and the fact that it's been out for a couple of years now. A tool to convert .d.ts to flow definition has been on flow short-term todo list since november and without it, flow is not viable for me.
TS definitely shines when starting new projects though, it can be a bit annoying on a legacy codebase.
(I use Pycharm, not VS and it integrates well in it, minus lagging a bit behind versions)
Typescript covers pretty much all the ES6 features that I use while flow is still missing let/const apparently. I only miss async/await and that should be in TS 1.6 so it's not a big deal for me and I believe you should be able to do a TS -> Babel -> ES5 workflow if you wanted by having ES6 as target for TS. For JSX, I prefer using React.DOM anyway but support will be in 1.6 and is already in master.
TS main selling point is DefinitelyTyped which means typing for pretty much all the third party code and the fact that it's been out for a couple of years now. A tool to convert .d.ts to flow definition has been on flow short-term todo list since november and without it, flow is not viable for me.
TS definitely shines when starting new projects though, it can be a bit annoying on a legacy codebase.
(I use Pycharm, not VS and it integrates well in it, minus lagging a bit behind versions)
Thanks for the insights. I haven't encountered any issues with third party code myself and don't mind the client/server model, but for me the killer app is Babel support (so flow is only a type checker, not another transpiler).
Do imports and import resolution work out of the box in TS these days? Last time I tried, I had to jump through hoops to get it to understand node imports and it wouldn't work without magical comments. I also don't want to have to wrap everything in module declarations -- the import logic of node should be sufficient. If TS has sorted these problems out, it might be worth another look for me.
Do imports and import resolution work out of the box in TS these days? Last time I tried, I had to jump through hoops to get it to understand node imports and it wouldn't work without magical comments. I also don't want to have to wrap everything in module declarations -- the import logic of node should be sufficient. If TS has sorted these problems out, it might be worth another look for me.
You just have to declare which external module (3rd party dep) you are using so typescript knows how to apply typings.
Ie you can use ES6 imports, you just need to have a /// <reference path="../typings/all.d.ts" /> line or declare them in tsconfig.json now (I believe, haven't checked yet).
I agree the modules are tricky and my least favourite thing about TS though
Ie you can use ES6 imports, you just need to have a /// <reference path="../typings/all.d.ts" /> line or declare them in tsconfig.json now (I believe, haven't checked yet).
I agree the modules are tricky and my least favourite thing about TS though
Eh. Those magical comments were what turned me off using TS to begin with. If I'm importing stuff, I'm already declaring my dependencies. TS seems to prefer re-inventing the wheel whereas flow just builds on what is already there.
But that's just my (unfairly biased) impression.
EDIT: Shame Flow is written in OCaml rather than built on Node. That's the only thing I prefer about TS at this point.
But that's just my (unfairly biased) impression.
EDIT: Shame Flow is written in OCaml rather than built on Node. That's the only thing I prefer about TS at this point.
You don't need Visual Studio to have automatic refactoring and code-complete. Atom, for example, supports that.
TypeScript's benefits include all the generic benefits of type checking.
TypeScript's benefits include all the generic benefits of type checking.
So it brings nothing that babel+flow doesn't do already? The only advantage I seem to find is being backed by MS and blessed by Angular (i.e. Google). Sorry if I sound dismissive. I'm just trying to figure out why so many seem to find TS exciting outside the MS sphere.
Flow is not available on windows, typescript is available on all major OSes.
TypeScript is probably more refined and has better tooling than Flow as it's a lot older. One could ask what Flow brings to the table.
[deleted]
[deleted]
Anyone has Dart vs TS comparison ?
I'm heavy Dart user - interested hearing someone having experience in both.
I was testing Dart in late 2013, for the admin pages of a hobby project of mine. But switched to TS because:
- As of now, TS and JS result in faster pages for me, because with TS and JS I can use React.js instead of Angular or Angular-Dart, and render the pages server side. And TS + React is for me easier to make it run fast, also after page load.
- Dart makes the fastest browser faster (except on initial page load, see above), but other browsers slow down, because they need to download the Dart runtime. This tradeoff feels like a not-a-good-idea, at least not for the homepage and other pages that should load in an instant for new users. So I wouldn't be able to use Dart everywhere? And then I'd have to use both Dart and TS/JS = too complicated.
Minor things:
- I think I felt a bit annoyed that Dart only made warnings of things that I would have wanted to be compilation time errors.
- I like TS better, it looks a bit more like Scala with the `: Type` annotations.
- Dart didn't work well in Firefox for me, it felt like boring to try to investigate what was wrong. (This was in November 2013 perhaps.)
The things I don't like about TS, is that it takes long to compile. And that it takes a while to learn how to use it — I still don't know much about it actually. And I haven't found any good free TS editor on Linux. (I'm about to try Atom I think.)
If it's okay, I'd be interested in having a look at your Dart project? After all I spent fairly much time with Dart; it would be interesting to see what other people build with it :-)
- As of now, TS and JS result in faster pages for me, because with TS and JS I can use React.js instead of Angular or Angular-Dart, and render the pages server side. And TS + React is for me easier to make it run fast, also after page load.
- Dart makes the fastest browser faster (except on initial page load, see above), but other browsers slow down, because they need to download the Dart runtime. This tradeoff feels like a not-a-good-idea, at least not for the homepage and other pages that should load in an instant for new users. So I wouldn't be able to use Dart everywhere? And then I'd have to use both Dart and TS/JS = too complicated.
Minor things:
- I think I felt a bit annoyed that Dart only made warnings of things that I would have wanted to be compilation time errors.
- I like TS better, it looks a bit more like Scala with the `: Type` annotations.
- Dart didn't work well in Firefox for me, it felt like boring to try to investigate what was wrong. (This was in November 2013 perhaps.)
The things I don't like about TS, is that it takes long to compile. And that it takes a while to learn how to use it — I still don't know much about it actually. And I haven't found any good free TS editor on Linux. (I'm about to try Atom I think.)
If it's okay, I'd be interested in having a look at your Dart project? After all I spent fairly much time with Dart; it would be interesting to see what other people build with it :-)
Thanks for sharing!
My Dart thingy is commercial NDA bla bla bla - so the only thing I can say it's more than 20K LOC. I was always afraid that such a big app couldn't be mantained in lang without proper IDE on non-windows (for Dart I'm using Dart's team Eclipse plugin and/or Webstorm plugin).
In my case I'm just too lazy to code in lang without lexical this and as I understand JS is TS subset, so you still can shot yourself in the foot really easy, also from what I hear JS/TS is better suited for small projects whereas Dart shines when project gets bigger (tree shaking, proper SDK) and perf really matters. On the con side: I would love Dart had as good IDE/plugin as TS has on Windows (Visual Studio).
My Dart thingy is commercial NDA bla bla bla - so the only thing I can say it's more than 20K LOC. I was always afraid that such a big app couldn't be mantained in lang without proper IDE on non-windows (for Dart I'm using Dart's team Eclipse plugin and/or Webstorm plugin).
In my case I'm just too lazy to code in lang without lexical this and as I understand JS is TS subset, so you still can shot yourself in the foot really easy, also from what I hear JS/TS is better suited for small projects whereas Dart shines when project gets bigger (tree shaking, proper SDK) and perf really matters. On the con side: I would love Dart had as good IDE/plugin as TS has on Windows (Visual Studio).
Do you use Dart for your whole website? How about page load times for the homepage? Or do you use Dart for pages / things that won't appear until the user knows what everything is about and is interested already, and won't mind ... 200 extra ms to download the Dart runtime?
Or is it an internal in-company application?
Do you happen to know how many kb JS code gets downloaded to a browser that doesn't support Dart natively?
(Unless this is too classified :-) )
Yes weird things happens sometimes with JS... a little bit more often with JS than with TS I think because TS is more restrictive.
Or is it an internal in-company application?
Do you happen to know how many kb JS code gets downloaded to a browser that doesn't support Dart natively?
(Unless this is too classified :-) )
Yes weird things happens sometimes with JS... a little bit more often with JS than with TS I think because TS is more restrictive.
It's Single Page Application used mostly from customer's intranet - currently around 1.6MB uncompressed (js version) - only initial page load is painful and takes around 2.3 sec from internet (on my decent DSL). But since it's just work tool they don't care about page loads that much as they do about feature completness.
I'm using Polymer-Dart on frontned + Dropwizard on backend (these days I would use Dart on the server side too, but when I was starting it wasn't mature enough). Overall I'm pretty happy with this tech except I hoped for faster Web Components adoption (better Polymer support for non-Chrome)
Thanks for sharing. Hmm, 1.6 MB minified and gzipped that might mean something like 300-400kb, which sounds fine to me. Edit Aha you wrote uncompressed — I suppose the JS was minified already then, and then the bundle will be larger, okay.
Full stack Dart seems like a good alternative. I wonder how popular it'll become now when there's Rust, Go and Scala.js too :-)
Full stack Dart seems like a good alternative. I wonder how popular it'll become now when there's Rust, Go and Scala.js too :-)
I'm sorry, I couldn't resist.
On a more serious note I'll have to see ho it works out phasing it into an existing, old, hacky (in many sad places) project