I saw the original announcement of Typescript at JSconf EU last year. It was an interesting moment: everyone was expecting another Dart, or less (there's a sea of Macs and most professional JS devs experience of Microsoft is IE) but stayed to listen to the presentation out of respect for the creator, who also made Delphi and C#.
Pretty much everyone came out impressed. Typescript is just JS with type hints, and neat warnings if you send a function something which its signature doesn't expect.
You can make a JS project a Typescript one immediately, adding type hints as you go, which for large projects is damn useful. The output, however, is pure regular old JS.
It's just like a CSS preprocessor, but for JS - transparently adding some optional awesomeness.
It works on Linux/Mac and SublimeText (albeit you don't get all the VS Intellisense stuff IIRC) too. I'm looking forward to trying it on a new project.
Typescript is in my peripheral vision so far but that really makes me want to look into it properly.
How do you think does it fit in with ES6? I feel like we're coming to a point in time where there should be a major shift in how we write javascript in a modern way -- so far my thought process has been that Coffescript is a nice stopgap before ES6 and the dust has almost settled enough to write ES6 first sorta..
TypeScript is far better suited than CoffeeScript if your goal is ES6. TypeScript currently outputs as ES3 or ES5 depending on a flag. ES6 to follow. It's very much up in the air with CoffeeScript.
ES6 is very important for them. For example, classes and modules in Typescript are essentially lifted directly from ES6, and they aim to remain compatible with ES6 as it evolves.
It's completely unrelated to CoffeeScript, as CS does practically no static analysis and generally CS does almost nothing more than pure JS. What it does is it translates some keywords to a chunks of JavaScript code. If JS had macros - sweet.js! - Coffee would be completely unneeded.
TypeScript is entirely different thing. It adds a layer of static analysis to the language, which does not end in the code that actually runs. Generally everything you type in Coffee has an equivalent in compiled JS; it is not so with TypeScript, where you can write pages of code which won't be visible in the compiled JS.
CS and TS have different goals and are different things, and the only thing they have in common is that they both "transpile"/compile some language to another. Hardly a similarity that makes them very close.
Actually I would appreciate TypeScript implementation on top of Coffee (or the other way around, whichever would be simpler). There is a dialect of CS that supports contracts (you really, really should start using contracts anyway), but that's yet another thing that cannot hope to replace static verification of certain things in programs.
You're absolutely right.
I'm an C# dev who switched to JavaScript stack and using TypeScript already for 5-6 months. It was just a first-look description for the TypeScript.
Btw, TypeScript also aiming to fix context problem so in callbacks 'this' keyword is always related to parent class.
I disagree.
1. Coffeescript is far from ugly, and also not particularly similar to Ruby :p
2. Typescript includes types and brackets. Coffeescript does not.
3. Icedcoffescript includes async/defer keywords. I include this last point only as a result of a personal perspective that if you're going to use coffeescript, you might as well use icedcoffeescript.
It's all what you're used to reading. If all you've been staring at are various curly-brace languages then of course you're going to prefer that.
I was primarily a curly-brace developer for 10 years, but changed my mind after a few years of Python, Ruby and Lua. Now I actually think these languages look better than the curly-brace family.
async/await is on their roadmap, though I'd estimate about a year before it'll be in a stable version (I wouldn't be surprised if it'll be available on a feature branch much sooner, but with lower expectation of stability).
FWIW, I've only tested emacs support. It's definitely sub-par. Barely indentation and syntax highlighting, we're still in need of a real typescript-mode for emacs.
I appreciate the effort, (I can't say the same for other Microsoft projects), but it's still not fun to play with typescript in emacs (as opposed to more mature projects like Python, C or, of course, Lisp).
Is there more than just syntax support in Sublime? I was pretty psyched when TypeScript was first announced but quickly bummed that the Sublime plugin didn't have any of the fancy autocomplete features.
TypeScript is a language for application-scale JavaScript development.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.
The JavaScript gotchas will still getcha, such as variable hoisting. I tend to forget they are still there when working in TypeScript, but that's my fault.
When you comfortable with JavaScript, there is nothing can scare you in TypeScript.
The only thing is - to get a best you need to prepare. If you using some library, I should find (or write, or generate) proper definition file for this library (Interface). But when you get all together - you have a lot of happy hours of coding :)
I am very excited by Typescript. I think JS was badly in need of some better typing. This release looks like it adds a lot: overloading on constants, enums, and generics will all lead to better typing. Never thought I'd say it, but thanks, Microsoft!
Whoa, thank you sir. I assumed it didn't support it because I couldn't find a Typescript plugin when I searched their repository. I didn't think it would just be built in.
The TypeScript tooling is completely open source (and actually written in TypeScript itself). So yeah I think we should see more support for TypeScript as it gains more traction.
I've been burned way too many times with Microsoft and there technology. I suggest that no one build any long lasting apps with this. They will dump it when something new and shiny comes along. Unless its based on C# or uses Visual Studio don't use it.
I now work at Microsoft, but was previously a long time developer in the Microsoft ecosystem (primarily C++). I would be the last guy to disagree with your experience and I am telling everyone who will listen internally what it was like to be on the outside.
But the Typescript project has some things going for it:
1. It's open source.
2. It's closely aligned with EC6, the upcoming Javascript standard.
3. It's compatible with existing Javascript libraries.
4. It's useful as it is, to add type checking to Javascript. It doesn't require a massive growing ecosystem to remain viable.
5. The compiler outputs standard idiomatic Javascript, which you could take and run with if you no longer wanted Typescript.
And, yes, there's a Visual Studio plugin for it if that's your cup of tea.
You can use Visual Studio Express 2012 for Web, which is no cost. Older VS's you can of course launch the command line compiler. The generated Javascipt is not mangled and is quite debuggable.
That might work in a startup, not in an enterprise environment where your computer image is controlled regularly by IT and all software requires approval before use.
Ouch. Can you give me some examples? A lot of companies have this issue: Google and Apple both dump tech left and right. If it's open source software and it's popular, though, there's a good chance the community will make sure it sticks around.
Microsoft didn't kill Silverlight, the iPad killed Silverlight. As for VB6, I think many here would agree that it was better off killed. You can still run VB6 apps on even Windows 8 though.
I disagree. Microsoft killed Silverlight. Your iPad argument means that we should all just skip native development and stick with HTML5.
Either Silverlight or WPF should be the favored Windows desktop development environment. Instead, they are both EOL and the incomplete Metro environment is the current way to do Windows desktop development.
In fact, if you are a Microsoft developer, you've lost Win32, MFC, ATL, WinForms, WPF, and Silverlight. The Windows desktop developer currently is waiting to see how Metro improves.
Um... Without Win32 there is no WinRT (do you think Windows isn't Windows anymore because of the advent of a new touch-first user experience and app model (with a centralized app store with simple and predictable app install/uninstall/update mechanics)?)
Without Win32 there is no Windows shell, touch first or not... There is no Visual Studio, Office, Photoshop, Premiere, etc, etc... You can have something new, different and still have what has always been there. This is what compatibility is all about... Can you run Windows 7 (and Windows XP) applications on Windows 8? Yes, of course you can.
Don't mistake the things you can't do in the WinRT environment (Win32 APIs you can't call, for example) with the end of those things (and what they are a part of)... MFC shipped a new version in 2012. WPF is at version 4.5. ATL is just a "high" level way to program COM just like WinRT, in fact... You don't need ATL any time you program to a COM-based ABI. You don't need WPF to build XAML-based WinRT apps. On x86 machines, there is a desktop for a reason and the reason is the same as it's always been.
All of those kits still work though and will continue to work for a long, long time. More than a decade, probably two. And...at least 3 of them are better kits than the unholy triumvirate of html, js and css.
As a developer in the Microsoft ecosystem - I have lost nothing and only gained new choices at each turn of events. That's because we run Windows internally and so do all of our clients and partners. Now tell me which one of those kits I can't use to build an app for them?
Windows RT is DOA so I'm safely ignoring Metro and it's lame sandbox...at least until general purpose computers are outlawed :)
Which itself could be traced back to Adobe trying to make Flash -> native iOS a thing. Apple's process is too expensive to manage the flood of games that would come from that.
Microsoft killed Silverlight like Adobe killed Flash. Ipad killed nothing. And it is not the first product MS kills. they did it and will do again and again ,... that's the price to pay when relying on closed technologies.
For people looking for an editor in which to try out TypeScript, I'll note that there's a neat looking community-written TypeScript extension[1] for Brackets[2]. (I work on Brackets).
I've been using dynamically typed languages consistently since 2005, but I'm curious to give TypeScript a try to see how it feels. The last statically typed language I used was Java (2004), and that was not a wholly pleasant experience.
If the selling point for TypeScript is adding static types/analysis to JavaScript, do we expect that it is the trend that other popular dynamic languages e.g. python/ruby/php will likely follow?
I think TypeScript is a cool idea, but I actually want runtime type checking. I don't know how many developers code with "design by contract" where you have contracts enforced not just at compile time, but at runtime. It allows for some incredibly smart, pluggable systems. I really don't know why there isn't more done with runtime type checking in various dynamic languages.
is it just me or Microsoft is slowly converting Javascript into C#? Don't get me wrong I like typescript but next thing you know we have .NETJS floating around :)
Actually my major grief is that they are using Microsoft's Codeplex software repository services which feel little old fashioned and cumbersome after all Github hipstering :)
Pretty much everyone came out impressed. Typescript is just JS with type hints, and neat warnings if you send a function something which its signature doesn't expect.
You can make a JS project a Typescript one immediately, adding type hints as you go, which for large projects is damn useful. The output, however, is pure regular old JS.
It's just like a CSS preprocessor, but for JS - transparently adding some optional awesomeness.
It works on Linux/Mac and SublimeText (albeit you don't get all the VS Intellisense stuff IIRC) too. I'm looking forward to trying it on a new project.