Why does TypeScript have to be the answer to anything?
Sponsored By
DISCLAIMER: I don't work on TypeScript. I am not involved with that team and this is all my own opinion and conjecture.
UPDATE: After this post I sat down with Anders in Denmark at the GOTO 2012 Conference sin Aarhus and asked him bunch of questions about TypeScript. That recorded audio podcast is now available.
TypeScript was announced and folks are saying "TypeScript is clearly Microsoft's answer to Google's Dart" or "So TypeScript is Microsoft's answer to CoffeeScript."
I was chatting with Jez Humble today about the intense interest and some little gnashing of teeth around TypeScript and he offered this little gem of a quote:
It's disappointing when smart people display a profound ignorance of computing history. - Jez Humble
TypeScript has been out a day. It's way early to see if it has legs, but it seems initially promising.
TypeScript and Dart
People have compared TypeScript to Dart. That's comparing apples to carburetors. TypeScript builds on JavaScript so there's no JS interop issues. Dart is a native virtual machine written from scratch. Dart interops with JavaScript...but it's not JS. It doesn't even use the JavaScript number type for example.
TypeScript and CoffeeScript
I'm a huge CoffeeScript fan although it is a different language with a syntax of its own to learn. What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more. You don’t currently get that in CoffeeScript.
So what is TypeScript?
TypeScript is a superset of JavaScript and you write it like you write JavaScript which I like. Any existing JavaScript is already TypeScript. One argument has been made that TypeScript is for people who don't want to learn JavaScript. I don't buy that. As Ward Bell said in an email:
TypeScript is not a crutch any more than JSLint is a crutch. It doesn’t hide JavaScript (as CoffeeScript tends to do). - Ward Bell
I think Ward says it well. Folks rail against static typing but they don't complain about JSLint. TypeScript offers optional type annotations - it's hardly a perversion of JavaScript.
From what I can see after using TypeScript for a few days is this. It gives you type checking, explicit interfaces and easier module exports. In fact, it's a little like getting some of tomorrow's ECMAScript 6 early in a way that's compatible with today's JavaScript. ES6 won't be out for at least a year but we can play with some of those features today.
Things that I like about TypeScript:
- It's Open Source and under the Apache 2.0 license
- You can install the tools easily with
- npm install typescript -g
- You can git the source
- git clone https://git01.codeplex.com/typescript
- You can play with it online at http://www.typescriptlang.org/Playground
Things I don't like about TypeScript (these are mostly implementation things)
- No splitscreen editor like Visual Studio's existing CoffeeScript editor
- UPDATE: While this isn't "official" support, Mads has updated Web Essentials 2012 with a splitscreen editor. The two teams are going to work together on a more official solution.
- Doesn't generate .js on save, requires a build.
- UPDATE: The Web Essentials extension does this for us.
- You have to add a BeforeBuild target to your ASP.NET application's CSPROJ:
<Target Name="BeforeBuild">
<Exec Command=""$(PROGRAMFILES)\Microsoft SDKs\TypeScript\0.8.0.0\tsc" @(TypeScriptCompile ->'"%(fullpath)"', ' ')" />
</Target>
I will continue to use TypeScript and evaluate it, but I think the fact that it's open source, it creates JavaScript and it feels comfortable to me as a C# programmer means it will fill a useful niche.
This quote from Luke Hoban, co-creator of TypeScript really hits the spot.
"CoffeeScript is to Ruby as TypeScript is to Java/C#/C++." - Luke Hoban
If you love Ruby, you'll enjoy CoffeeScript as it makes the JavaScript more like the Ruby. The same is true with TypeScript. It brings useful features into JavaScript in an ultimately compatible and syntax-friendly way using language constructs you're comfortable with.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
October 02, 2012 16:44
Is it open source as in open source? Or MS open-source? Will you accept pull requests? Is the main git branch behind MS firewalls and periodically pushed to codeplex making patches/branches a PITA?
Matt Freeman
Completely Agree Scott ... the CoffeeScript/VanillaJS argument has happened, and I'm sure there will be more to come.
If you're in the party that doesn't like this - fine and great, but don't rain on others if they do happen to like it.
I personally think if you build anything with over 30+ script files (large node app or SPA), this is a God-send for just managing all of that... and the best part... if you don't want to use the types, you don't have to!
If you're in the party that doesn't like this - fine and great, but don't rain on others if they do happen to like it.
I personally think if you build anything with over 30+ script files (large node app or SPA), this is a God-send for just managing all of that... and the best part... if you don't want to use the types, you don't have to!
Quite right, choices are good, TypeScript doesn't replace anything it compliments the development of JavaScript by alternative means.
We can all debate the implementation details, the pros, the cons, but arguing its existence is irrelevant if it passes the 'is this something that I trust to use when I'm developing' i.e this is not a poorly thought out idea, then more power to use the developers. These are our choices to make, and more choice is always good here.
To use an anaology, the bucket full of large stones looks full, but you can fill the spaces between the large stones with smaller stones, and lots of them. Our bucket full of EverythingToDoWithJavaScript stones has its big stones (native JavaScript, JQuery etc) but CoffeeScript, TypeScript and lots of other js tools and frameworks have there place.
We can all debate the implementation details, the pros, the cons, but arguing its existence is irrelevant if it passes the 'is this something that I trust to use when I'm developing' i.e this is not a poorly thought out idea, then more power to use the developers. These are our choices to make, and more choice is always good here.
To use an anaology, the bucket full of large stones looks full, but you can fill the spaces between the large stones with smaller stones, and lots of them. Our bucket full of EverythingToDoWithJavaScript stones has its big stones (native JavaScript, JQuery etc) but CoffeeScript, TypeScript and lots of other js tools and frameworks have there place.
Dart and CoffeeScript are things that look interesting to me, but I don't have a lot of time to invest in additional learning curves unless there's an immediate and unavoidable need.
I looked at the TypeScript examples and a light immediately went on.
I just love it when a bunch of people that don't have enough work to do stand around the proverbial water cooler comparing things that they've probably never even tried.
It's useful. If you like it, use it.
I looked at the TypeScript examples and a light immediately went on.
I just love it when a bunch of people that don't have enough work to do stand around the proverbial water cooler comparing things that they've probably never even tried.
It's useful. If you like it, use it.
I have work on several big projets and it became a nightmare to maintain Javascript file over the time. I found interesting that some organisation work toward a solution to help developer to be able to work with Javascript in a sane manner. I haven't try yet TypeScript but if it works directly (not hidding) with Javascript and work fine with library like JQuery, I guess I might give a try.
You named your article 'Why does it have to be an answer to anything'. Well, I think that's the question and you didn't (IMHO) answer it in the slightest, i.e.: why or why not. You simply addressed what it is, but that's not what's important, IMHO, and the post title suggested indeed what's important, but it's left unanswered. Let me do a humble attempt to answer it ;)
The thing is that Hejlsberg spent significant time on this as well as other people, which they thus didn't spend on C# and .NET. Now, it might be they did this to get a break from C#, .NET and everything related to it, as, lets face it, they worked on that for a long long time. Things tend to get boring over time.
However, why Hejlsberg invested the time in this is IMHO the real question: what problem does he try to solve, and more importantly: that's not solvable with anything else? If the answer to that question is: "Javascript at the moment lacks a certain amount of features to make .NET devs jump ship", then I can understand why time was spend on this. However, why do .NET devs have to jump ship, if that's the reason?
If the answer is simply: "because .net and C# lack things JS has", why not build these into C# and/or .NET? Or better: leverage what's already there and extend it to make it an even better choice than JS for e.g. serverside development.
Because... the code written in Typescript, is that mainly UI-helper code or application logic? If the former, why bother with a new language, UI code is and will always be: horrible to write, no matter what you use. If it's the latter... isn't it simply re-inventing the wheel, re-creating a language for a problem which has already been solved years ago, by the same person/team: .NET / C#?
Personally, I fail to see why MS invests time in Javascript at all. The thing is that a JS dev has no ties with Microsoft nor Microsoft products. If you convert a dev who uses Microsoft products or has ties to Microsoft products to a JS dev, that dev is effectively cut 'free' from MS and therefore will not make MS any money. Also, by doing so, the platforms which do make money for MS get less and less devs, making them less relevant for the work they are designed for.
I know it sounds great when you look at it from the 'If we support JS all the way, the JS devs will come to us as well!', but just because you support JS doesn't mean the JS devs have an incentive to move to Microsoft platforms and tie themselves to Microsoft products.
Maybe I'm just a little disappointed MS doesn't invest more energy in .NET and C# to make them the first choice for app development on microsoft platforms/products and instead does the opposite.
The thing is that Hejlsberg spent significant time on this as well as other people, which they thus didn't spend on C# and .NET. Now, it might be they did this to get a break from C#, .NET and everything related to it, as, lets face it, they worked on that for a long long time. Things tend to get boring over time.
However, why Hejlsberg invested the time in this is IMHO the real question: what problem does he try to solve, and more importantly: that's not solvable with anything else? If the answer to that question is: "Javascript at the moment lacks a certain amount of features to make .NET devs jump ship", then I can understand why time was spend on this. However, why do .NET devs have to jump ship, if that's the reason?
If the answer is simply: "because .net and C# lack things JS has", why not build these into C# and/or .NET? Or better: leverage what's already there and extend it to make it an even better choice than JS for e.g. serverside development.
Because... the code written in Typescript, is that mainly UI-helper code or application logic? If the former, why bother with a new language, UI code is and will always be: horrible to write, no matter what you use. If it's the latter... isn't it simply re-inventing the wheel, re-creating a language for a problem which has already been solved years ago, by the same person/team: .NET / C#?
Personally, I fail to see why MS invests time in Javascript at all. The thing is that a JS dev has no ties with Microsoft nor Microsoft products. If you convert a dev who uses Microsoft products or has ties to Microsoft products to a JS dev, that dev is effectively cut 'free' from MS and therefore will not make MS any money. Also, by doing so, the platforms which do make money for MS get less and less devs, making them less relevant for the work they are designed for.
I know it sounds great when you look at it from the 'If we support JS all the way, the JS devs will come to us as well!', but just because you support JS doesn't mean the JS devs have an incentive to move to Microsoft platforms and tie themselves to Microsoft products.
Maybe I'm just a little disappointed MS doesn't invest more energy in .NET and C# to make them the first choice for app development on microsoft platforms/products and instead does the opposite.
Frans - Hjelsberg talks about compiling C# to javascript in the intro video to TypeScript, and gives reasons why it's always going to be awkward when it comes to leveraging javascript libraries.
Of course - if you really want to use C# in the browser, you can always use Silverlight. Yeah. Exactly. Javascript is here to stay, on the web.
Of course - if you really want to use C# in the browser, you can always use Silverlight. Yeah. Exactly. Javascript is here to stay, on the web.
@Frans Bouma:
I think you underestimate a lot javascript, it's not just a UI-Helper language anymore, full apps are written in javascript and run in any (decent) browser on any device/OS, you just can't get that with .NET
I think you underestimate a lot javascript, it's not just a UI-Helper language anymore, full apps are written in javascript and run in any (decent) browser on any device/OS, you just can't get that with .NET
FYI -- You can enable some support for CoffeeScript (i.e. style based warning squiggles) in SublimeText.
If you use SublimeText + the SublimeLinter package (https://github.com/SublimeLinter/SublimeLinter), you can get the equivalent of "coffee -l" as you code in CoffeeScript.
They are a couple of commits away from having this replaced with CoffeeLint, a much better linter for Coffee.
Also keep in mind that the CoffeeScript compiler rewrite is nearing completion, which will enable some interesting new syntax tree parsing functionality (including source maps), which opens the door for additional tooling support. Technically you can get sourcemaps out now if you want.
This still doesn't buy you refactoring (something you'll likely never get in an editor like Sublime) or a host of other fancier things that VS can do.. but it's a pretty good compromise for a fast edit / compile cycle (something VS is IMHO not very good at).
If you use SublimeText + the SublimeLinter package (https://github.com/SublimeLinter/SublimeLinter), you can get the equivalent of "coffee -l" as you code in CoffeeScript.
They are a couple of commits away from having this replaced with CoffeeLint, a much better linter for Coffee.
Also keep in mind that the CoffeeScript compiler rewrite is nearing completion, which will enable some interesting new syntax tree parsing functionality (including source maps), which opens the door for additional tooling support. Technically you can get sourcemaps out now if you want.
This still doesn't buy you refactoring (something you'll likely never get in an editor like Sublime) or a host of other fancier things that VS can do.. but it's a pretty good compromise for a fast edit / compile cycle (something VS is IMHO not very good at).
I think that the comparison between TypeScript and JSLint is interesting for reasons other then those Ward gives. JSLint's proposition is that there's a subset of JavaScript that forms a decent language, whereas TypeScript's proposition seems to be that JavaScript is deficient without the addition of static type checking. Whether you buy into the latter proposition depends on whether you believe a) that managing large projects in JS is a problem, and b) that the solution to that problem is static typing.
All of that says to me that TypeScript is for those that wish that JS was something else rather than what it is. It strikes me that it would appeal much less to developers who actually like JS's dynamic, functional, prototypal nature. CoffeeScript is going to appeal to those people more because it offers more terse ways to express the same patterns that they would have used to write JS before.
All of that says to me that TypeScript is for those that wish that JS was something else rather than what it is. It strikes me that it would appeal much less to developers who actually like JS's dynamic, functional, prototypal nature. CoffeeScript is going to appeal to those people more because it offers more terse ways to express the same patterns that they would have used to write JS before.
@frans - it's nothing to do with jumping ship, from C# to JS. If you build, lets say a Facebook app or Facebook game (as is my day job), mixing ASP.NET MVC4, WebAPI and rich Javascript, the least productive element to me, and hardest to collaborate on when working as a team, is the Javascript component. TypeScript looks very promising to make me more productive. I was evaluating CoffeeScript, but TypeScript's more incremental approach looks very useful. For me, it looks like a promising tool to add to my belt.
@frans - plus a UI/logic split isn't that helpful. I've already started testing AngularJs and TypeScript together. Works well to use TypeScript with client side MVC/MVVM with typed controllers and models, which combines both UI/logic elements.
@frans - and on investment focus, because of the closer link between server and client (think real time and SignalR) any investment in Javascript is also in many regards an investment in .NET server technologies.
@frans - plus a UI/logic split isn't that helpful. I've already started testing AngularJs and TypeScript together. Works well to use TypeScript with client side MVC/MVVM with typed controllers and models, which combines both UI/logic elements.
@frans - and on investment focus, because of the closer link between server and client (think real time and SignalR) any investment in Javascript is also in many regards an investment in .NET server technologies.
@frans - .Net dev's write javascript too....
Pretty much anyone that is using JavaScript wants the features associated with a statically typed language. And, done in such an elegant way.
Pretty much anyone that is using JavaScript wants the features associated with a statically typed language. And, done in such an elegant way.
Frans - Anders didn't write it, he joined the project late. The team is just a few people, compared to hundreds (thousands?) on .NET. You're giving TypeScript more gravitas than needed, perhaps because Anders is involved.
SteveR - Extremely astute and thoughtful comment!
Ethan - Excellent point. The real money will be on Source Maps. None of these techs will ever catch on big without them.
SteveR - Extremely astute and thoughtful comment!
Ethan - Excellent point. The real money will be on Source Maps. None of these techs will ever catch on big without them.
From a quick look TypeScript seems like an interesting addition to JavaScript. It's nice that it's build on top instead of as a replacement so you can opt in when needed. MS doesn't seem to want to displace JavaScript but augment and make the ecosystem better.
Watching the Anders video triggered a little thought on the culture created by static or dynamic programming and a possibly negative effect of better tooling.
http://objectatrest.wordpress.com/2012/10/02/typescript-its-not-about-dynamic-vs-static/
Watching the Anders video triggered a little thought on the culture created by static or dynamic programming and a possibly negative effect of better tooling.
http://objectatrest.wordpress.com/2012/10/02/typescript-its-not-about-dynamic-vs-static/
@frans This seems a little cynical, even for a bitter guy like me. I prefer not to speculate on motives (which are unknowable anyway) and focus on what it does. My first thought is that it is built to help with large javascript projects, which currently take up a lot of brain space to just manage where things are at.
Why wouldn't MS invest time in JavaScript? It seems clear that if you want to play in the web space, you have no other choice.
Why wouldn't MS invest time in JavaScript? It seems clear that if you want to play in the web space, you have no other choice.
@Scott: Aha! That's a nice bit of info that was IMHO not expressed elsewhere. In that light, it indeed looks like I have given it more gravitas than I should have. It sounds lame perhaps, but I'm sort of relieved. :)
Excellent post!
I see Typescript ultimately as a time saver. It allows me to code and debug faster (especially in VS2012). Its going to be most appealing to C++/Java/C# coders - and its a brilliant idea that's being a bit oversold. Its just tooling.
The danger is the layer of abstraction it adds to those that don't know Javascript . C# coders that start using Typescript thinking that 'its just like C#' because it looks syntactically similar are going to fall down hard as they realize just how different Javascript's prototype/function based approach is.
I think you should use Typescript if you already know how to build the code Typescript compiles into, and want to save time -- but if you don't know Javascript then at you should least use that great Typescript playground to examine and understand the Javascript code that is being generated for you.
I want to see Typescript tutorials that, every step of the way, show the compiled Javascript and explain what's really being created.
I see Typescript ultimately as a time saver. It allows me to code and debug faster (especially in VS2012). Its going to be most appealing to C++/Java/C# coders - and its a brilliant idea that's being a bit oversold. Its just tooling.
The danger is the layer of abstraction it adds to those that don't know Javascript . C# coders that start using Typescript thinking that 'its just like C#' because it looks syntactically similar are going to fall down hard as they realize just how different Javascript's prototype/function based approach is.
I think you should use Typescript if you already know how to build the code Typescript compiles into, and want to save time -- but if you don't know Javascript then at you should least use that great Typescript playground to examine and understand the Javascript code that is being generated for you.
I want to see Typescript tutorials that, every step of the way, show the compiled Javascript and explain what's really being created.
How easy will this be to debug? Although I see the benefits in the compile-time checking, won't it be a pain to have to debug it via the generated Javascript code in Firebug, DevTools etc?
Have Ms comitted to the ECMA version of javascript or is this just another attemt to get more vendor-lockin on the javascript language?
Javascript beeing a subset of typescript, which javascript?
Javascript beeing a subset of typescript, which javascript?
I think TypeScript's merit lies in exactly what Scott highlighted and what Anders explained in was for in his presentation - helping developers write better, maintainable, application-scale javascript at development time.
Plus, the fact that it truly is a superset of JavaScript, means I can dip in when needed and it doesn't require me to go with a big bang implementation or conversion. That's been one of my big hesitations with CoffeeScript - it truly requires a full-on commitment. Everybody on the team needs to be on board with the new short-hand syntax.
For anyone coming from any c-based language background, this should be a welcome addition as it retains javascript's syntax and just adds some sugar at development time to make decomposition and recomposition easier, debugging easier and ultimately prevent more bugs from making it to production. Other than that, it's just javascript.
I see native javascript as the assembler language of the web. CoffeeScript, TypeScript, etc. are higher level functional languages that sit on top of it and there will probably be more to come. As long as they all compile down to javascript for runtime, then how is this different from any higher level language abstraction over x86 assembler?
I'd much rather see this approach which embraces JavaScript and builds on top of it vs. another plugin or VM-based approach.
Plus, the fact that it truly is a superset of JavaScript, means I can dip in when needed and it doesn't require me to go with a big bang implementation or conversion. That's been one of my big hesitations with CoffeeScript - it truly requires a full-on commitment. Everybody on the team needs to be on board with the new short-hand syntax.
For anyone coming from any c-based language background, this should be a welcome addition as it retains javascript's syntax and just adds some sugar at development time to make decomposition and recomposition easier, debugging easier and ultimately prevent more bugs from making it to production. Other than that, it's just javascript.
I see native javascript as the assembler language of the web. CoffeeScript, TypeScript, etc. are higher level functional languages that sit on top of it and there will probably be more to come. As long as they all compile down to javascript for runtime, then how is this different from any higher level language abstraction over x86 assembler?
I'd much rather see this approach which embraces JavaScript and builds on top of it vs. another plugin or VM-based approach.
Microsoft prove in his history that the only important thing for them is the money. Microsoft is a company I don't trust. I test azure for linux machines, but didn't pick it because I am afraid that Microsoft changes again his opinion and decide that azure linux instances are not good for them and close that platform.
With TypeScript is happening to me the same. Maybe they generate a really good language. And maybe that becomes popular. Imagine that most of the browser start parsing and compiling typescript. Maybe microsoft release a new version of the source code that is tie to... lets say DirectX, and you can no longer run it in your android phone. That the updates only work on windows phones. That they optimize only for their compilers (thing that is perfectly normal).
I don't trust on microsoft. I don't believe that if this success, they will start using it in a unimaginable way to try to kill the rest of competitors.
So unless they start showing that is a real open source language, where google people can even commit... sorry, but i prefer you to test with this staff while I work.
With TypeScript is happening to me the same. Maybe they generate a really good language. And maybe that becomes popular. Imagine that most of the browser start parsing and compiling typescript. Maybe microsoft release a new version of the source code that is tie to... lets say DirectX, and you can no longer run it in your android phone. That the updates only work on windows phones. That they optimize only for their compilers (thing that is perfectly normal).
I don't trust on microsoft. I don't believe that if this success, they will start using it in a unimaginable way to try to kill the rest of competitors.
So unless they start showing that is a real open source language, where google people can even commit... sorry, but i prefer you to test with this staff while I work.
I am really curious how easy will it be to debug it? I mean breakpoints, step into and so on. Will it debug on the 'compiled' JS code or against TS code?
I don't think your comparison with Dart is as clear as it should be...
- TypeScript shares exactly Dart's primary goal of providing structure to web development to facilitate the creation of large-scale apps.
- Adding optional typing is the primary feature of both languages
- Dart has a primary goal of transpiling efficiently to JavaScript so it runs ubiquitously in all modern browsers (as does TypeScript)
- The transpiled version of Dart does use the JavaScript number type - there is nothing else it can use
- You've pointed out the only difference between the transpiled JS and the Dart VM which is that the Dart VM will choose to use a proper *int* number type where it's safe to do so - where as every number in JS is a float, which is horrid for integer performance. You've made this sound like it's common that it deviates from the transpiled JS when in fact it's the only difference - which it does for better perf.
- Ironically enough, Dart looks more like C# than TypeScript, that wasn't clear either
- TypeScript shares exactly Dart's primary goal of providing structure to web development to facilitate the creation of large-scale apps.
- Adding optional typing is the primary feature of both languages
- Dart has a primary goal of transpiling efficiently to JavaScript so it runs ubiquitously in all modern browsers (as does TypeScript)
- The transpiled version of Dart does use the JavaScript number type - there is nothing else it can use
- You've pointed out the only difference between the transpiled JS and the Dart VM which is that the Dart VM will choose to use a proper *int* number type where it's safe to do so - where as every number in JS is a float, which is horrid for integer performance. You've made this sound like it's common that it deviates from the transpiled JS when in fact it's the only difference - which it does for better perf.
- Ironically enough, Dart looks more like C# than TypeScript, that wasn't clear either
How can you have vendor lockin with an open source implementation of an open specification?
I think it's still possible to love JavasScript and embrace TypeScript at the same time. Just because a language is dynamic doesn't mean that it doesn't have "intent". If I write a function displayFirstName(firstName) my intent is that firstName is a string. The fact the I *can* pass in a function for firstName does me absolutely no good. I think of TypeScript as less of a language and more of a JavaScript library that allows me enforce my intent during design time while giving me first-class tooling support that would not normally be possible with a dynamic language.
Guillermo - You should do more research. ASP.NET webstack is open source and has taken commits happily from others including the Mono guys so it would work on Linux. This is not going to change.
Azure supports Linux, happily, and this will not change.
This is not the Microsoft of years past. Find a new reason to dislike them, these won't work.
Azure supports Linux, happily, and this will not change.
This is not the Microsoft of years past. Find a new reason to dislike them, these won't work.
A Dart team member's take on TypeScript:
http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd
http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd
Who can stop Microsoft to support native Typescript execution on a feature release of IE?
With a statically typed language in place , IE & IIS aware and compatible with native Typescript, together with rozlyn technology, we may end up with a feature where web development with C# will be compatible with ALL browsers without any plugin installation needed.
With a statically typed language in place , IE & IIS aware and compatible with native Typescript, together with rozlyn technology, we may end up with a feature where web development with C# will be compatible with ALL browsers without any plugin installation needed.
Hi Scott!
It's usually easier for me to hate these Microsoft innovations :) This time, not as much.
For my way of programming, I'm not interested in building an entire application using TypeScript. I've gone on the voyage personally and put dynamic languages into production. I found none of the typical drawbacks that I was warned about. I don't miss Visual Studio. I can't remember the last time I experienced a type mismatch error (but it would have been in the Foxbase+ years). My understanding of productivity has little to do with tooling anymore.
That said, I'm enthusiastic about TypeScript in particular as an IDL, like Thrift, Protobuf, Avro, etc (or even COM IDL if you wanna go back that far).
A good avenue of exploration with TypeScript is in creating schemas that live at system and sub-system boundaries.
You could call these "contracts", but that's a bit too muddy and brings all kinds of concepts and biases along for the ride.
Schema is a good thing for protocols. I don't want to have a protocol between every darned object - but when I do, it's nice to have a bit of tooling support.
It's about getting some "fail fast" optimizations for free when failing slow is extremely expensive - like when leaving the in-process memory and going to the wire, or IO, or etc.
Hope you're well!
Best,
Scott
It's usually easier for me to hate these Microsoft innovations :) This time, not as much.
For my way of programming, I'm not interested in building an entire application using TypeScript. I've gone on the voyage personally and put dynamic languages into production. I found none of the typical drawbacks that I was warned about. I don't miss Visual Studio. I can't remember the last time I experienced a type mismatch error (but it would have been in the Foxbase+ years). My understanding of productivity has little to do with tooling anymore.
That said, I'm enthusiastic about TypeScript in particular as an IDL, like Thrift, Protobuf, Avro, etc (or even COM IDL if you wanna go back that far).
A good avenue of exploration with TypeScript is in creating schemas that live at system and sub-system boundaries.
You could call these "contracts", but that's a bit too muddy and brings all kinds of concepts and biases along for the ride.
Schema is a good thing for protocols. I don't want to have a protocol between every darned object - but when I do, it's nice to have a bit of tooling support.
It's about getting some "fail fast" optimizations for free when failing slow is extremely expensive - like when leaving the in-process memory and going to the wire, or IO, or etc.
Hope you're well!
Best,
Scott
@Guillermo:
This is nothing but weak FUD, best kept on that withering wine of bitterness otherwise known as Slashdot. This is not your father's Micro$oft, and uttering thinly-veiled rants smothered in thick, slippery slope fallacy sauce is inane and childish. Even - by some large jump of the imagination - if Microsoft wanted to integrate TypeScript into their browser, it would have little effect on the rest of the Web where Internet Explorer no longer has a stranglehold.
This is nothing but weak FUD, best kept on that withering wine of bitterness otherwise known as Slashdot. This is not your father's Micro$oft, and uttering thinly-veiled rants smothered in thick, slippery slope fallacy sauce is inane and childish. Even - by some large jump of the imagination - if Microsoft wanted to integrate TypeScript into their browser, it would have little effect on the rest of the Web where Internet Explorer no longer has a stranglehold.
@demis - I think , in the past we've all hated Javascript the bad parts, many of us loved that at least you it had lamdas etc, all of us wanted something more, and were annoyed that it was the sole survivor, and option as the browser language, so we've experimented with building on top of it. Various worldviews, and distain for JS come through.
So as for Dart versus TypeScript. I think typescript has made more peace with javascript that dart. Dart tries to fix javascript more, while TypeScript tries to "go with the grain" more.
That's my take anyhow.
So as for Dart versus TypeScript. I think typescript has made more peace with javascript that dart. Dart tries to fix javascript more, while TypeScript tries to "go with the grain" more.
That's my take anyhow.
From what I can tell, the only reason not to think that TypeScript adds something to the JavaScript ecosystem is that it is from Microsoft.
As an experienced MS developer, I guess I have some deep-seated trust issues when it comes to Microsoft.
That said, it does look promising. I'm going to withhold judgement until I see some reviews from people who are already in the thriving JavaScript community and have experience with using current toolsets in the large JavaScript code-bases that TypeScript purports to support.
"From the company that brought us the non-standard browser that keeps on giving, the IDE that crashes 5 times a day, and JScript, a custom version of JavaScript that served the sole purpose of tying developers to IE, we bring you "TypeScript".
It's got nothing to do with IE (yet), but don't worry, we can think of plenty of ways that we can leverage this to tie you into our products."
As an experienced MS developer, I guess I have some deep-seated trust issues when it comes to Microsoft.
That said, it does look promising. I'm going to withhold judgement until I see some reviews from people who are already in the thriving JavaScript community and have experience with using current toolsets in the large JavaScript code-bases that TypeScript purports to support.
Listen, if a new piece of tech isn't an answer to something, then what are we even talking about?
What problem does TypeScript solve?
What problem does TypeScript solve?
Personally I think it's dangerous to step up the ladder of abstraction without understanding the rungs you've skipped over.
I find it far more valuable to learn JavaScript properly (i.e. being able to grok the compiled TypeScript), than attempt to sidestep them. Learn it's bad parts (hey it's good to understand why language features aren't good!) it's functional heritage and the (dis)advantages of dynamic languages. As a programmer it's always good to expose yourself to things you don't normally encounter day-to-day, and i think JavaScript is the perfect language to open your mind a little. If you spend all day writing in static, strongly-typed languages treat JavaScript as a learning opportunity, an adventure into a strange, exotic and interesting world!
I'll try to reserve complete judgement until I can spend some time writing code, and maybe TypeScript will convince me otherwise as new features are added, but for now I enjoy expanding my mind a little with some of JS' craziness :-)
I find it far more valuable to learn JavaScript properly (i.e. being able to grok the compiled TypeScript), than attempt to sidestep them. Learn it's bad parts (hey it's good to understand why language features aren't good!) it's functional heritage and the (dis)advantages of dynamic languages. As a programmer it's always good to expose yourself to things you don't normally encounter day-to-day, and i think JavaScript is the perfect language to open your mind a little. If you spend all day writing in static, strongly-typed languages treat JavaScript as a learning opportunity, an adventure into a strange, exotic and interesting world!
I'll try to reserve complete judgement until I can spend some time writing code, and maybe TypeScript will convince me otherwise as new features are added, but for now I enjoy expanding my mind a little with some of JS' craziness :-)
It's very similar to Google Traceur. Why Microsoft didn't want to join Google in bringing ECMAScript Harmony to today's browsers?
Some of the comments here have been mind blowing.
People have a right to criticize a piece of technology (I myself am no fan of the ECMAScript proposals) but they should really take the time to appreciate the issues at play before they do.
If people cannot understand the need for typing in JavaScript, they simply haven't written enough of it. Renaming an instance member is ridiculously difficult and always leaves you feeling like you've dropped a baby. Ctrl+Shift+H is not the answer folks.
Overall, I am very pleased with the interface functionality and optional typing. My only concern is debugging, but presumably the compiler can/will be able to produce the required source maps for the Chrome developer tools.
So Scott, can you get Anders on Hanselminutes ;-)
People have a right to criticize a piece of technology (I myself am no fan of the ECMAScript proposals) but they should really take the time to appreciate the issues at play before they do.
If people cannot understand the need for typing in JavaScript, they simply haven't written enough of it. Renaming an instance member is ridiculously difficult and always leaves you feeling like you've dropped a baby. Ctrl+Shift+H is not the answer folks.
Overall, I am very pleased with the interface functionality and optional typing. My only concern is debugging, but presumably the compiler can/will be able to produce the required source maps for the Chrome developer tools.
So Scott, can you get Anders on Hanselminutes ;-)
There is a statically compiled CoffeeScript: github.com/Steida/este
Brought to you by Google Closure Compiler.
Brought to you by Google Closure Compiler.
And as soon as someone writes a coffescriptish layer on top of TypeScript I will be all in.
Forget classes, I don't need them just give me an automatic closure on the file and a way for "function" to not be 30% of my codebase
Forget classes, I don't need them just give me an automatic closure on the file and a way for "function" to not be 30% of my codebase
@george , typescript already has that. while in coffescript you can just do a parameterless function with => 1 for instance, in Typescript you have to do () => 1 but still its far between that decorating "lambdas" with function() { return 1 }
…And with its introduction, some unquantifiable number of man hours have been restored to humanity that would have otherwise been used trying to track down a missing semicolon, misspelled property name, or one of the many other annoyances of debugging a dynamic language. ;)
To comment on what Frans Bouma was getting at... The answer here is obvious, IMO.
TypeScript benefits Microsoft because their developer community (primarily C# developers) are leaving in droves to go to JavaScript. Further, MS has invested heavily in JavaScript in it's new products, intending that to be a language of choice for Windows development of the future. Sweet!
Microsoft wants it's community of C# developers to use JavaScript and stay on the MS stack, and continue using MS developer tools like Visual Studio.
So...
How to make JavaScript more comfortable for C# developers?
How to give JavaScript a better static analysis story so that more of the features of Visual Studio development are available and relevant?
TypeScript!
It's a middle ground intended to ease the transition from C# to JavaScript and provide the kinds of development tools, programming model, and workflow that C# developers have become accustomed to.
While we're at it, why don't we ladle strong typing into Python and Ruby too! Then we can use Visual Studio for all the things!
Anyway.. To me this is obviously the strategy, and it's a good one. TypeScript is actually a really interesting solution to this. That said, I would not use it. I also do not use CoffeeScript.
That's because I *like* the JavaScript syntax. There is nothing to fix. Write JavaScript correctly, and the problems everyone is mentioning just aren't there. JavaScript is NOT a pure object-oriented language. Stop trying to make it be that. It's multiparadigm. It's imperative, it's functional, and its also object-oriented. It's weakly typed and dynamically typed, and that's a good thing. It's extremely *simple* as well. Why over-complicate it?
Quick question, C# devs of the world... How much time did you spend messing around with generics, dependency injection, IoC, extremely complex polymorphisms, etc.? So much that you started building a sense of pride around how well you could wrangle those things. That's like being proud of how well you can juggle five monkeys while cooking your breakfast. Why do you want to juggle monkeys if you don't have to?
The same mindset encourages people to do things like seal their classes "just in case".. When has sealing a class ever helped anyone? It doesn't improve security. It doesn't avoid problems. It creates problems that don't need to be there.
Look at how much of that stuff that you don't have to do in JavaScript, because there is no pointless type system getting in your way. It's flexible and easy to work with because of it's very permissive type system. Why would anyone want to take that away?
Who wants compilation-time type errors? No one. They don't really help anything. People will say that static/strong typing benefits integration amongst distributed teams, improves code quality and prevents one bad programmer from bombing an entire system by stopping the code before it's deployed at compile time.
That's kind of a load of bull. Good testing helps. Good documentation helps. Use those instead. Dont' try to avoid them. Build a CI/CD system that requires a high level of test coverage. Let that be your gateway.
Developer tools are a *coping mechanism* for overly complicated development situations. Why do JS developers not use Visual Studio, or Eclipse, or NetBeans? Because they don't need to. Tools can get in the way and encourage bad practices.. a false sense of security. Sure, there is a balance. That's why we don't all use edlin, or Notepad. Instead we use a very nice middle ground, like vi, emacs, SublimeText, etc...
As for Dart and other languages of that nature (check out Vala, btw, it's sweet)... Not JavaScript, and doesn't really relate. TypeScript is just some (unnecessary) additional syntax and constraints, for JavaScript. Dart and Vala are completely different runtimes/compilation environments.
Ok, I really didn't mean to rant like that. But I did... :P
TypeScript benefits Microsoft because their developer community (primarily C# developers) are leaving in droves to go to JavaScript. Further, MS has invested heavily in JavaScript in it's new products, intending that to be a language of choice for Windows development of the future. Sweet!
Microsoft wants it's community of C# developers to use JavaScript and stay on the MS stack, and continue using MS developer tools like Visual Studio.
So...
How to make JavaScript more comfortable for C# developers?
How to give JavaScript a better static analysis story so that more of the features of Visual Studio development are available and relevant?
TypeScript!
It's a middle ground intended to ease the transition from C# to JavaScript and provide the kinds of development tools, programming model, and workflow that C# developers have become accustomed to.
While we're at it, why don't we ladle strong typing into Python and Ruby too! Then we can use Visual Studio for all the things!
Anyway.. To me this is obviously the strategy, and it's a good one. TypeScript is actually a really interesting solution to this. That said, I would not use it. I also do not use CoffeeScript.
That's because I *like* the JavaScript syntax. There is nothing to fix. Write JavaScript correctly, and the problems everyone is mentioning just aren't there. JavaScript is NOT a pure object-oriented language. Stop trying to make it be that. It's multiparadigm. It's imperative, it's functional, and its also object-oriented. It's weakly typed and dynamically typed, and that's a good thing. It's extremely *simple* as well. Why over-complicate it?
Quick question, C# devs of the world... How much time did you spend messing around with generics, dependency injection, IoC, extremely complex polymorphisms, etc.? So much that you started building a sense of pride around how well you could wrangle those things. That's like being proud of how well you can juggle five monkeys while cooking your breakfast. Why do you want to juggle monkeys if you don't have to?
The same mindset encourages people to do things like seal their classes "just in case".. When has sealing a class ever helped anyone? It doesn't improve security. It doesn't avoid problems. It creates problems that don't need to be there.
Look at how much of that stuff that you don't have to do in JavaScript, because there is no pointless type system getting in your way. It's flexible and easy to work with because of it's very permissive type system. Why would anyone want to take that away?
Who wants compilation-time type errors? No one. They don't really help anything. People will say that static/strong typing benefits integration amongst distributed teams, improves code quality and prevents one bad programmer from bombing an entire system by stopping the code before it's deployed at compile time.
That's kind of a load of bull. Good testing helps. Good documentation helps. Use those instead. Dont' try to avoid them. Build a CI/CD system that requires a high level of test coverage. Let that be your gateway.
Developer tools are a *coping mechanism* for overly complicated development situations. Why do JS developers not use Visual Studio, or Eclipse, or NetBeans? Because they don't need to. Tools can get in the way and encourage bad practices.. a false sense of security. Sure, there is a balance. That's why we don't all use edlin, or Notepad. Instead we use a very nice middle ground, like vi, emacs, SublimeText, etc...
As for Dart and other languages of that nature (check out Vala, btw, it's sweet)... Not JavaScript, and doesn't really relate. TypeScript is just some (unnecessary) additional syntax and constraints, for JavaScript. Dart and Vala are completely different runtimes/compilation environments.
Ok, I really didn't mean to rant like that. But I did... :P
Here you go, at-home-audience, chew on this.
Low Level Javascript
"LLJS is a typed dialect of JavaScript that offers a C-like type system with manual memory management. It compiles to JavaScript and lets you write memory-efficient and GC pause-free code less painfully, in short, LLJS is the bastard child of JavaScript and C."
http://mbebenita.github.com/LLJS/
Low Level Javascript
"LLJS is a typed dialect of JavaScript that offers a C-like type system with manual memory management. It compiles to JavaScript and lets you write memory-efficient and GC pause-free code less painfully, in short, LLJS is the bastard child of JavaScript and C."
http://mbebenita.github.com/LLJS/
Another interesting take on a language that "transpiles to JS"...
Moescript
I was just in Shanghai for 沪JS and met the creator of this language. During the hackathon, we wrote SourceMap support for Moescript. Wicked!
Needs better docs though. :)
Moescript
I was just in Shanghai for 沪JS and met the creator of this language. During the hackathon, we wrote SourceMap support for Moescript. Wicked!
Needs better docs though. :)
@Scott: You ask: "How can you have vendor lockin with an open source implementation of an open specification?"
Do you believe Microsoft did never took influence on any company which creates a standard?
Do you believe Microsoft did never took influence on any company which creates a standard?
"Who wants compilation-time type errors? No one."
really?! Scott commented once that compilation is like the first unit test. It's a genuine step forward.
"While we're at it, why don't we ladle strong typing into Python and Ruby too! Then we can use Visual Studio for all the things!"
Not sure why you'd want to do that. JavaScript is not equivilent to Ruby. One differentiator, Ruby is elegant, and I don't need to read a "good parts" book to pretend JavaScript is too.
really?! Scott commented once that compilation is like the first unit test. It's a genuine step forward.
"While we're at it, why don't we ladle strong typing into Python and Ruby too! Then we can use Visual Studio for all the things!"
Not sure why you'd want to do that. JavaScript is not equivilent to Ruby. One differentiator, Ruby is elegant, and I don't need to read a "good parts" book to pretend JavaScript is too.
@Scott
I know @Guillermo was catching a lot of flack for his comments regarding ye olde embrace-and-extend mantra from Microsoft. The reply you gave him perhaps answered that, but I think the unfortunate (growing?) distrust between devs and Microsoft goes way deeper than this. And I'm not talking about just personal preferences - I'm talking about business-changing decisions. The company I work for has in the past year and a half gone from being a completely MS shop (with regards to development) to a mostly Apple shop - despite the fact that we don't really like the way Apple treats developers. There were a number of factors involved in this, but the two main ones were the lack of good alternatives to the iPad for deployment to enterprise-type customers for .NET (although iPad is also far from ideal) and a feeling that Microsoft was not always going to be there for us due to the treatment of WPF and Silverlight. I don't want to drag WPF into this, per se, but I do think Microsoft's change in UI strategies leaves the more conservative elements of business (i.e. the enterprises that tend to have big dollar signs attached to contracts) a bit out in the cold. And that's one of the big differences (in my opinion) between MS and Apple: MS has traditionally been more stable with regards to development environments and longevity of platforms, etc. - friendlier to devs and to businesses. The feeling that this may no longer be true has some folk thinking that there's less comparative *disadvantages* to developing on other platforms.
So where am I trying to go with this? I think Guillermo (from his talk of Azure) may represent more the enterprise type of devs, and if not him, there are many others that do. To me, the question that matters with regards to this technology is the one that my boss will ask me if I try bringing it up as a potential solution: "Is this language going to have long-term support from Microsoft?" I know that sounds extremely harsh given this is essentially day one of the technology, but I bring it up because I think some clear vision and a roadmap, etc., from MS up front could leverage their strengths and start to give them an edge in certain areas. So this is not a rant, but rather a request for MS to make this a language I can recommend to my boss.
All that being said, let's talk about the tech for a moment. Everybody's been talking about how this will be great to interop with JavaScript. Well, I'd like to say that strong typing makes the path to interoping to native libraries a lot easier. I know that's not popular, but it's an important enterprise-ish sort of question. I once worked with Siebel CRM software and despite large portions of it being complete crap, the fact that its odd, optionally-typed version of ECMA script was able to interop out to things like C libraries was crucial to creating the Borg that are enterprise systems. This also has the interesting effect that embedding TypeScript could be a pleasant experience, as well.
At any rate, thanks for taking a moment to get this far. I'm not trying to flame, and I hope that someday soon I can see a post here touting MS's strategy for long-term support for TypeScript and how it's the best thing for businesses since sliced bread.
I know @Guillermo was catching a lot of flack for his comments regarding ye olde embrace-and-extend mantra from Microsoft. The reply you gave him perhaps answered that, but I think the unfortunate (growing?) distrust between devs and Microsoft goes way deeper than this. And I'm not talking about just personal preferences - I'm talking about business-changing decisions. The company I work for has in the past year and a half gone from being a completely MS shop (with regards to development) to a mostly Apple shop - despite the fact that we don't really like the way Apple treats developers. There were a number of factors involved in this, but the two main ones were the lack of good alternatives to the iPad for deployment to enterprise-type customers for .NET (although iPad is also far from ideal) and a feeling that Microsoft was not always going to be there for us due to the treatment of WPF and Silverlight. I don't want to drag WPF into this, per se, but I do think Microsoft's change in UI strategies leaves the more conservative elements of business (i.e. the enterprises that tend to have big dollar signs attached to contracts) a bit out in the cold. And that's one of the big differences (in my opinion) between MS and Apple: MS has traditionally been more stable with regards to development environments and longevity of platforms, etc. - friendlier to devs and to businesses. The feeling that this may no longer be true has some folk thinking that there's less comparative *disadvantages* to developing on other platforms.
So where am I trying to go with this? I think Guillermo (from his talk of Azure) may represent more the enterprise type of devs, and if not him, there are many others that do. To me, the question that matters with regards to this technology is the one that my boss will ask me if I try bringing it up as a potential solution: "Is this language going to have long-term support from Microsoft?" I know that sounds extremely harsh given this is essentially day one of the technology, but I bring it up because I think some clear vision and a roadmap, etc., from MS up front could leverage their strengths and start to give them an edge in certain areas. So this is not a rant, but rather a request for MS to make this a language I can recommend to my boss.
All that being said, let's talk about the tech for a moment. Everybody's been talking about how this will be great to interop with JavaScript. Well, I'd like to say that strong typing makes the path to interoping to native libraries a lot easier. I know that's not popular, but it's an important enterprise-ish sort of question. I once worked with Siebel CRM software and despite large portions of it being complete crap, the fact that its odd, optionally-typed version of ECMA script was able to interop out to things like C libraries was crucial to creating the Borg that are enterprise systems. This also has the interesting effect that embedding TypeScript could be a pleasant experience, as well.
At any rate, thanks for taking a moment to get this far. I'm not trying to flame, and I hope that someday soon I can see a post here touting MS's strategy for long-term support for TypeScript and how it's the best thing for businesses since sliced bread.
I think typescript is a nice try just as dart and coffee script, but I believe the purpose of such languages are misleading.
There is no reason to change javascript.
When you are in Rome do as the Romans do.
The above rule applies to programming as well. (When I code in C#, I don't do it the javascript way and vica versa)
Learning javascript takes significantly less effort than deal with the tooling and the problems with debugging.
The Web already has its Lingua Franca, it's called javascript
There is no reason to change javascript.
When you are in Rome do as the Romans do.
The above rule applies to programming as well. (When I code in C#, I don't do it the javascript way and vica versa)
Learning javascript takes significantly less effort than deal with the tooling and the problems with debugging.
The Web already has its Lingua Franca, it's called javascript
I like writing my own javascript. This is another abstraction layer it seems. Reminds me of WebForms or EF. Here learn another pseudo language to help you write the actual language. Could see where TypeScript could be useful to some coders though. Especially on large js projects.
Typescript? meh.
Simply annotate your JavaScript with javadoc tags, and compile it with Google's Closure compiler, https://developers.google.com/closure/compiler/
There you have "type checking, interfaces and easier module exports". Today.
TypeScript offers too little real value to motivate me to switch.
Where is:
- namespacing?
- *destructors!?* one of the Big time-saving issues when writing large apps I'd say.
- "yield" keyword?
- list comprehensions?
- generics? (if you wan't real use for type-checking).
-------
JavaScript++ is the only new web-language I find any beauty and actual, useful, additions in:
http://jspp.javascript.am/
(It's what Coffescript should have been IMHO..)
Simply annotate your JavaScript with javadoc tags, and compile it with Google's Closure compiler, https://developers.google.com/closure/compiler/
There you have "type checking, interfaces and easier module exports". Today.
TypeScript offers too little real value to motivate me to switch.
Where is:
- namespacing?
- *destructors!?* one of the Big time-saving issues when writing large apps I'd say.
- "yield" keyword?
- list comprehensions?
- generics? (if you wan't real use for type-checking).
-------
JavaScript++ is the only new web-language I find any beauty and actual, useful, additions in:
http://jspp.javascript.am/
(It's what Coffescript should have been IMHO..)
@All / @Scott
I got same response on my FB links when I blogged about TypeScript. Ppl saying why Microsoft trying to change the existing system, why adding a new layer. I have only one answer for them, maybe I'm wrong.
I don't think Microsoft trying to add new layer in existing programming, they are just trying to implement a new fashion to write JavaScript codes, there is nothing like business because your code is ultimately getting translated into JavaScript that you love. So, if you like JavaScript coding fashion you will love TypeScript, we are still using its preview, huge to come.
I got same response on my FB links when I blogged about TypeScript. Ppl saying why Microsoft trying to change the existing system, why adding a new layer. I have only one answer for them, maybe I'm wrong.
I don't think Microsoft trying to add new layer in existing programming, they are just trying to implement a new fashion to write JavaScript codes, there is nothing like business because your code is ultimately getting translated into JavaScript that you love. So, if you like JavaScript coding fashion you will love TypeScript, we are still using its preview, huge to come.
You should do more research. ASP.NET webstack is open source and has taken commits happily from others including the Mono guys so it would work on Linux. This is not going to change.
Nice to know that ! But don't know no one that run windows servers. I am on the start up market in Berlin, and also when I was leaving on Spain, and the last time a saw a Microsoft server was in the university. more than 10 years ago.
Azure supports Linux, happily, and this will not change.
I know I was testing that. I still doesn't trust on Microsoft.
This is not the Microsoft of years past. Find a new reason to dislike them, these won't work.
I think this is not a fight. So please... don't get angry. Companies are persons and the persons in Microsoft are mostly the same than past yeras. Look at Steve Ballmer for example. His character is directly translated to the company. And currently that is still the case. Microsoft is a company made for money. The only thing that is important is money.
Call me wired, but I prefer to deal with companies that worries more about persons. Companies that focus more in make the users happy, than companies that just want to get any single $ cent from the user.
I just want to remark a few facts:
* For example, Today this article about Microsoft behaviors with inde game developers. This is like dealing with the typical sales person.
* Yesterday, a few websites telling that microsoft start using a responsive css layout. That was a lie. Only on the landingpage ! Anything you click on the landing page moves you to a fixed 9XX layout ! You see. Marketing again instead of doing real things.
* Microsoft reject support for opengl in the browser(I know that opengl can sucks in comparison with directx). That will cause a huge delay on the adoption of 3d for the web. Ok, Microsoft have his directX... but sadly... is not open and you can only use on PC and with windows. So the rest of the world can just depend on the decision of microsoft.
* Any microsoft employee I meet on my life told me that there are a lot of managers and meetings, and that their work is not so productive (if you compare with other companies). And also, after a few years working at Microsoft I saw that people loosing passion for what they used to love: programming If the developers doesn't have passion .. You can't trust on the product. But maybe on this point I am wrong. Sadly I don't meet enough Microsoft employees.
Microsoft doesn't now to share his power. When I see things like typescript makes me sad. Typescript could be nice, but with a company like microsoft behind, I only can think that microsoft is trying to beat competitors like google chrome, instead of creating a good product.
This is nothing but weak FUD, best kept on that withering wine of bitterness otherwise known as Slashdot. This is not your father's Micro$oft, and uttering thinly-veiled rants smothered in thick, slippery slope fallacy sauce is inane and childish. Even - by some large jump of the imagination - if Microsoft wanted to integrate TypeScript into their browser, it would have little effect on the rest of the Web where Internet Explorer no longer has a stranglehold.
I never expect to say this, but the Microsoft fans are getting more annoying (and blind) than Linux or Mac fans. Seams like the Steve Ballmer effect of screaming to the people "Developers! Developers! Developers!", like if they where just things to feed, have finally got his effect.
Maybe I'm late to the party but Web Essentials (the editor linked in the post) says it has support for TypeScript. That's probably as of today.
Compile on save seems to be there (not tried yet).
See here.
Compile on save seems to be there (not tried yet).
See here.
If Microsoft wants to move forward in the web, move into the ecmascript directly. Become the best browsers supporting the last standard. Make the people of jQuery to need to install InternetExplorer to develop the latest version ecmascript.
But as always, Microsoft wants to do things. Is in his bubble where all the things are Microsoft. Without thinking if make sense or not. They just saw a market oportunity an go for it. They saw github get popular. All the people start using it, and today I discover that they are trying to copy with codeplex. LOL
But coming back to the topic, sorry. For the same reason that CoffeScript (for me) sucks, Typescript also sucks. Once you compile to javascript is a pain (if you are testing in different browsers) to come back to the source code if something fails. Because there are not integrated debugger.
What I think is going to happen: If Typescript doesn't success, microsoft will drop the support in less than a Year. If success Microsoft will be the first browser (IE) having native support, and cool debugging tools in internet explorer plus a boost of performance, trying that the rest of the browsers to follow microsoft. A thing that Microsoft is missing in the last years.
And if you want to call me a troll. Go for it. I don't trust on Microsoft CEO/CTO, etc...
But as always, Microsoft wants to do things. Is in his bubble where all the things are Microsoft. Without thinking if make sense or not. They just saw a market oportunity an go for it. They saw github get popular. All the people start using it, and today I discover that they are trying to copy with codeplex. LOL
But coming back to the topic, sorry. For the same reason that CoffeScript (for me) sucks, Typescript also sucks. Once you compile to javascript is a pain (if you are testing in different browsers) to come back to the source code if something fails. Because there are not integrated debugger.
What I think is going to happen: If Typescript doesn't success, microsoft will drop the support in less than a Year. If success Microsoft will be the first browser (IE) having native support, and cool debugging tools in internet explorer plus a boost of performance, trying that the rest of the browsers to follow microsoft. A thing that Microsoft is missing in the last years.
And if you want to call me a troll. Go for it. I don't trust on Microsoft CEO/CTO, etc...
You are right. Some people even comparing TypeScript with c#...
--
LIVEditor - text editor with a Firebug-like UI at
--
LIVEditor - text editor with a Firebug-like UI at
I've been trying typescript today, just rewriting a couple of js files in an angularjs / asp.net webapi project I'm working on and I love it - I'm going to convert everything when I get some time. It feels like coffeescript with curly braces, semicolons, and contract support. I really prefer C style syntax to Ruby style syntax, so coffeescript didn't work very well for me.
The split screen editor and process-on-save features from the web essentials addon are awesome additions and make it much more usable (I don't want to have to recompile hence reboot my web app when I'm changing the client side bits).
I think this is going to be a great addition to my toolkit, good job :)
P.S. the name is a bit bland though...
The split screen editor and process-on-save features from the web essentials addon are awesome additions and make it much more usable (I don't want to have to recompile hence reboot my web app when I'm changing the client side bits).
I think this is going to be a great addition to my toolkit, good job :)
P.S. the name is a bit bland though...
I've been using it for two days now and am loving it.
Moved the JS code that I wrote the last couple of weeks to ts and created declarations for libraries that the code called into.
So far so good.
When I've got more time I will look in some more detail at bundling, maybe investigate whether closure to declaration files can be automated, and a convert the-open-ts-file-to-js VS command so that I don't have to rebuild the server while debugging. (Currently I make some changes in the generated js file till I figured out what went wrong)
Moved the JS code that I wrote the last couple of weeks to ts and created declarations for libraries that the code called into.
So far so good.
When I've got more time I will look in some more detail at bundling, maybe investigate whether closure to declaration files can be automated, and a convert the-open-ts-file-to-js VS command so that I don't have to rebuild the server while debugging. (Currently I make some changes in the generated js file till I figured out what went wrong)
I'd try a response to each remark, but I'll keep it as condensed as possible.
@Guillermo - Mono, from my experience, runs our MVC application for work perfectly fine. I haven't finished our Web API component, but from what I've read, more of the same functionally. If TypeScript doesn't succeed and developers aren't using it, sure, Microsoft will probably stop supporting it (though I'm not sure saying "supporting" it is the proper term as it reads to be as more of a side project). But 1) isn't that the case with a lot of open source projects? 2) doesn't it generate ECMA JavaScript that you can then use with your non-vendor locked in implementation and pretend the whole TypeScript thing never happened? If it is open source, what prevents an outside entity from putting together a Linux or OSX implementation of it so that they could bring a sense of comfort for C#/Java developers migrating to their platform for "less scary" Javascript development?
It's okay that you don't want to use Azure. You did your research like countless others and put your lot in the bucket you felt most beneficial to you, just as others have. There are other cloud solutions (or just web hosting in general) that run ASP.NET applications just fine. Personally, I think the anti-Microsoft thing is rooted primarily in the past. In a world where Internet Explorer wasn't working toward (or fully? I really stopped keeping track) towards standardization with the incremental IE releases. Is there a company you do trust developmentally? Google started out developer friendly, and to a greater extent still is, but what once was given for free in a few big cases is being charged for now (Maps being the common one) or deprecated entirely. And no one can fault them for that as they are a company that has to make the stockholders happy too. I would say Microsoft in recent years has actually been more friendly with developers. Sure, you do have technologies that become deprecated for any number of reasons, but in the case of Silverlight and WPF, XAML is still there so in a sense, it isn't all for nothing (besides, nothing prevents you from using the toolset to continue making WPF applications for Windows 7).
If you have interest in having your cake and eating it to (in regards to picking-and-choosing the Microsoft technologies you like and integrating them with others), I recommend Tekpub. Not a customer nor employee or anyone else with any real interest in the company (asides from the fact I do think they're doing a good thing and wish them the best), but for me, personally, it opened my eyes to PostgreSQL and MVC working hand-in-hand. Note, that isn't to say I view SQL Server negatively, but it helped in allowing me to use the tools that I like (and with the code base we already have) with the system our project lead wants to get behind.
And isn't that what we should really care about? Engineering solutions?
Robert
@Guillermo - Mono, from my experience, runs our MVC application for work perfectly fine. I haven't finished our Web API component, but from what I've read, more of the same functionally. If TypeScript doesn't succeed and developers aren't using it, sure, Microsoft will probably stop supporting it (though I'm not sure saying "supporting" it is the proper term as it reads to be as more of a side project). But 1) isn't that the case with a lot of open source projects? 2) doesn't it generate ECMA JavaScript that you can then use with your non-vendor locked in implementation and pretend the whole TypeScript thing never happened? If it is open source, what prevents an outside entity from putting together a Linux or OSX implementation of it so that they could bring a sense of comfort for C#/Java developers migrating to their platform for "less scary" Javascript development?
It's okay that you don't want to use Azure. You did your research like countless others and put your lot in the bucket you felt most beneficial to you, just as others have. There are other cloud solutions (or just web hosting in general) that run ASP.NET applications just fine. Personally, I think the anti-Microsoft thing is rooted primarily in the past. In a world where Internet Explorer wasn't working toward (or fully? I really stopped keeping track) towards standardization with the incremental IE releases. Is there a company you do trust developmentally? Google started out developer friendly, and to a greater extent still is, but what once was given for free in a few big cases is being charged for now (Maps being the common one) or deprecated entirely. And no one can fault them for that as they are a company that has to make the stockholders happy too. I would say Microsoft in recent years has actually been more friendly with developers. Sure, you do have technologies that become deprecated for any number of reasons, but in the case of Silverlight and WPF, XAML is still there so in a sense, it isn't all for nothing (besides, nothing prevents you from using the toolset to continue making WPF applications for Windows 7).
If you have interest in having your cake and eating it to (in regards to picking-and-choosing the Microsoft technologies you like and integrating them with others), I recommend Tekpub. Not a customer nor employee or anyone else with any real interest in the company (asides from the fact I do think they're doing a good thing and wish them the best), but for me, personally, it opened my eyes to PostgreSQL and MVC working hand-in-hand. Note, that isn't to say I view SQL Server negatively, but it helped in allowing me to use the tools that I like (and with the code base we already have) with the system our project lead wants to get behind.
And isn't that what we should really care about? Engineering solutions?
Robert
For those that wanted to see how TypeScript compares with Dart, I've ported some TypeScript examples to Dart to highlight the language differences between the 2 languages:
https://gist.github.com/3817303
In the Ray Tracer port I was able to use some of Dart's features like operator overloading, implicit interfaces, string interpolation, visibility by convention, etc. to make the code more readable.
https://gist.github.com/3817303
In the Ray Tracer port I was able to use some of Dart's features like operator overloading, implicit interfaces, string interpolation, visibility by convention, etc. to make the code more readable.
As you say, a light went on when I looked at it: it seems like a very light and unobtrusive extension, although it's super-powerful if you want it to be. I also do a bunch of stuff in C#, and this thing makes sense to me - especially since it's still JavaScript and all my existing code will be understood by it. I have a feeling that little sleeper bugs will be far easier to find with this thing - at the compiler level.
It remains to be seen whether this thing starts to remove some of the flexibility from JavaScript - in a way, you don't want to think about JavaScript as a typed language because one of the "good" (quotes are deliberate) things is that you can start breaking rules and ignoring typing - important if you're dealing with something like a DOM which is also a weakly-typed thing (unless you think of everything as a bunch of strings). I'll be playing with this *a lot* over the next few weeks to see what I can figure out.
It remains to be seen whether this thing starts to remove some of the flexibility from JavaScript - in a way, you don't want to think about JavaScript as a typed language because one of the "good" (quotes are deliberate) things is that you can start breaking rules and ignoring typing - important if you're dealing with something like a DOM which is also a weakly-typed thing (unless you think of everything as a bunch of strings). I'll be playing with this *a lot* over the next few weeks to see what I can figure out.
I think this is just another example of Microsoft NIH, the same way ASP.NET MVC started after there were multiple open source frameworks to do the same thing. Microsoft just has too many employees that have to justify their jobs, and just like everywhere else most devs would rather work on something new than fix the things that are broken. If it doesn't catch on no one will get paid to work on it anymore and it will die like countless previous Microsoft technologies: perpetual movement in some direction, usually so devs have more reasons to pay for new versions of Visual Studio.
@Eric Barnard -- My company's main product is sitting at 433 JavaScript files as of right now, all managed/written by about 14 devs or so. Honestly maintaining and building a JS application that big just isn't a problem. I think most fear of dynamically typed languages -- or fear of JS -- is just that, fear. In practice the fears basically never come to fruition. I feel like TypeScript is a solution looking for a problem.
What about script#?
At work I use script# extensively and I find it very useful (though lacking several features such as generics and extension methods). Why hasn't microsoft adopted script#?
Having the power of resharper when developing client side code in script# is a pleasure.
At work I use script# extensively and I find it very useful (though lacking several features such as generics and extension methods). Why hasn't microsoft adopted script#?
Having the power of resharper when developing client side code in script# is a pleasure.
@Matt: You're 100% correct. Design Patterns coupled with organizational frameworks like BackboneJS make building large-scale applications in JavaScript both a breeze and a pleasure.
@Tom, be sure to check out http://www.saltarelle-compiler.com where an open-source compiler is picking up where Script# has languished since the Script# compiler is closed.
Your post suggests (but does not say) that users comparing TypeScript with Dart or CoffeeScript "display a profound ignorance of computing history". I find this attack insulting and ill-grounded. I compare TypeScript and Dart because they share a common design goal: making it easier than pure Javascript to write large-scale client or server programs for the web.
I honestly believe there is a fair and interesting comparison to be made, and your way to dismiss this as "comparing apples to carburetors" is again disdainful and inappropriate.
I honestly believe there is a fair and interesting comparison to be made, and your way to dismiss this as "comparing apples to carburetors" is again disdainful and inappropriate.
I threw together a nuget package that adds an msbuild targets file to your project. It will run the tsc compiler and clean up its output so that you can double click on the errors in Visual Studio and jump to the file/line/column.
https://www.nuget.org/packages/Sholo.TypeScript.Build
You need to set the Build Action in the properties Window to 'TypeScriptCompile' for anything that you want tsc to compile. From a few days of tinkering with TypeScript, I've found that the .ts files that are doing the referencing should be set to TypeScriptCompile, but the files that are only being referenced should not, but ymmv. Also, you may need to Show All Files and add the original .js file. If you want to group related .ts/.js/.d.ts files together, take a look at the VsCommands extension. Workflow is also pretty nice with NetDemon/similar extensions.
https://www.nuget.org/packages/Sholo.TypeScript.Build
You need to set the Build Action in the properties Window to 'TypeScriptCompile' for anything that you want tsc to compile. From a few days of tinkering with TypeScript, I've found that the .ts files that are doing the referencing should be set to TypeScriptCompile, but the files that are only being referenced should not, but ymmv. Also, you may need to Show All Files and add the original .js file. If you want to group related .ts/.js/.d.ts files together, take a look at the VsCommands extension. Workflow is also pretty nice with NetDemon/similar extensions.
What I simply wanted that to annotate my method in C# Class with [Server] tag which means it runs on server and [Client] which runs on client. So selfishly I don't have to learn another language and I hated javascript. I have written of such nature comment on Scottgu blog some 3/4 years back.
I ask again to do such enhancement in C# as its also supporting functional language. As l see nothing has happen in that area I learnt Javascript.
Now don't make us learn new language, I beg you, I touch your feet.
I ask again to do such enhancement in C# as its also supporting functional language. As l see nothing has happen in that area I learnt Javascript.
Now don't make us learn new language, I beg you, I touch your feet.
Hi Scott, thanks for the post, insightful, do you know if there are any plans for unit test support for TypeScript, or if it already does support unit testing?
Thanks.
Thanks.
@guillermo. What do you expect? Microsoft is a business. You start a business to make money.
Can't wait to explore TypeScript after reading your blog. So do you think Typescript encourages us to for Server side code in javascript,
Hey scott, how you manage to get this much knowledge? Can you give bit of your brain to me also :)
@Jed Turlach – You are disappointed with MS because they intend to retire Silverlight and yet at the same time you say you are writing iPad apps for the enterprise. This neatly sums up the problem. Lots of customers now desire to use apps other than IE to access corporate applications. Many users like to use, for example, iOS devices. Safari on iOS does not allow third party plugins. It is entirely possible that Microsoft asked Apple if they would allow a Silverlight plugging on iOS and Apple said ‘no’. In this case, given that their market share in the browser space is declining, Microsoft have the option to either a) continue their focus on Silverlight and accept that a huge percentage of users out their could not access applications if their browser does not accept a Silverlight plugin or b) bite the bullet and embrace HTML5/Javascript etc. I think they HAD to choose the latter.
Thanks for writing this up. I didn't see much difference from CoffeeScript (which is generally well liked), except Microsoft was going to make it work with their tooling. The general disdain from the web was disappointing, but not unexpected. Microsoft has the sins of the father working against it.
There is fantastic Channel 9 video with Anders and Lars Bak (chief architect & team lead for Dart)on Dart, JavaScript, and TypeScript. It was definitely worth 43 minutes of my life.
http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart
http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart
I was watching the #typescript tag on Twitter for a while. The majority of comments are positive, but you do get the occassional "we don't need no stinkin' TypeScript/Dart/CoffeeScript" types of response.
I refer your readers to this survey from 2011 which finds that 99 of the top 100 sites on the web have JavaScript errors. The only one that didn't was Google.
Google developed Dart - I wonder if it's not just a co-incidence that theirs is the only error-free site!
I refer your readers to this survey from 2011 which finds that 99 of the top 100 sites on the web have JavaScript errors. The only one that didn't was Google.
Google developed Dart - I wonder if it's not just a co-incidence that theirs is the only error-free site!
@Mahesh,
You cannot invoke a static constructor, so what would supply parameters? A static constructor does NOT create a new INSTANCE.
You cannot invoke a static constructor, so what would supply parameters? A static constructor does NOT create a new INSTANCE.
Comparing to Dart and CoffeeScript is all well and nice, but what about compiling C# to JavaScript? Isn't it the obvious solution for developers? It's already supported in any version of Visual Studio, it honors existing developer knowledge and existing design-time tools, and it's super productive and rich language... For example:
http://sharpkit.net/Live.aspx
http://sharpkit.net/Live.aspx
Nice post! I've been playing with TypeScript. Check out my TypeScript Tutorials
I was looking for information about TypeScript when I stumbled on this post. Took me time to read all the comments but it did helped me. Thanks a lot for the post and thank to commenters for their insight.
One thing doh...
When I see comments like "learn pure JavaScript, you don't need TypeScript if you know JavaScript, etc..."
I just want to say one thing at that: Ok, so learn ASM cause if you know ASM you won't need C++ anymore or other upper level language and by the way, ASM need to be compiled so why don't you learn machine language like in the early days of computing. I used to help my big brother work with that, what a pain!
Common... Every programming language is superset of something else but make programmers life a lot more easy. I remember my early days in computer programming. The first program I did all by myself was written in MS Basic on a TRS 80 model 1 and a after that Tandy 1000.
Good old days! No way... It was a pain in the ... and when (Turbo) Pascal came along I was happy to leave Basic! And when I've got my first 386 machine with Windows and VB it was back to Basic but the VB way. Was fun.
And so on...
But back to the subject... I learned JavaScript in the late 90's, used it for some projects but I parted with JavaScript, HTML, CSS when I started doing ActionScript, PHP, Flash and Flex work. So I didn't touch much JavaScript in the last 9 years. Now, comes all the iDevices with no adoption of the FlashPlayer and HTML, JavaScript and CSS are becoming the way to go again. And I find out that my knowledge of JavaScript dates a lot, new things are in, new frameworks etc... Back to learning...
But, If someone create a tool that can help me leverage the work, and learn in the same time by studying the output, I'm more than willing to use it. But first, I need working results!
Just my 2cents.
One thing doh...
When I see comments like "learn pure JavaScript, you don't need TypeScript if you know JavaScript, etc..."
I just want to say one thing at that: Ok, so learn ASM cause if you know ASM you won't need C++ anymore or other upper level language and by the way, ASM need to be compiled so why don't you learn machine language like in the early days of computing. I used to help my big brother work with that, what a pain!
Common... Every programming language is superset of something else but make programmers life a lot more easy. I remember my early days in computer programming. The first program I did all by myself was written in MS Basic on a TRS 80 model 1 and a after that Tandy 1000.
Good old days! No way... It was a pain in the ... and when (Turbo) Pascal came along I was happy to leave Basic! And when I've got my first 386 machine with Windows and VB it was back to Basic but the VB way. Was fun.
And so on...
But back to the subject... I learned JavaScript in the late 90's, used it for some projects but I parted with JavaScript, HTML, CSS when I started doing ActionScript, PHP, Flash and Flex work. So I didn't touch much JavaScript in the last 9 years. Now, comes all the iDevices with no adoption of the FlashPlayer and HTML, JavaScript and CSS are becoming the way to go again. And I find out that my knowledge of JavaScript dates a lot, new things are in, new frameworks etc... Back to learning...
But, If someone create a tool that can help me leverage the work, and learn in the same time by studying the output, I'm more than willing to use it. But first, I need working results!
Just my 2cents.
@Michel:
I don't mean to be a smart ass, but assembly isn't compiled - it's assembled. Furthermore, you're making a bit too large of a distinction between assembly and machine code, seeing as how machine code is just assembly in binary form, and each byte/word/dword/etc of machine code correlates directly to an instruction/operand/whatever in assembly. While I'm sure you knew all this, (and most likely used inaccurate vocabulary to keep things simple) many developers today unfortunately don't, so I thought I'd go ahead and correct the technicalities, as I feel it's pretty important for a developer to know how the underlying machine works.
@Everyone:
That said, my view is pretty similar to Michel's, though probably a bit more jaded. (Sad, given that I'm only 25) To avoid going off on an eight paragraph rant about the state of the development industry/community as a whole, and why I feel like it's growing more and more nauseating, I'll try to keep this simple: Very few things in this world are black and white. While some of us would like to force the act of development into a restrictive interpretation that fits their own usage cases, it's important to understand that none of us are all that special. We all have distinct preferences when writing code, and as a result, have different requirements for the language we choose to use as an intermediary to our end goals. For the sake of progress, please stop interpreting your own opinions and preferences for facts and "Best Practices".
Social commentary aside, I actually like the way that TypeScript implements its intended functionality. I tend to take a minimalist approach to most development, so I like the fact that it produces clean, readable JavaScript that's accessible from the global scope. (Unlike Dart, which I feel bloats the underlying DOM with unnecessary wrappers, and then packages the entire thing up in a closure to prevent access from the actual JavaScript) My problem with TypeScript revolves around a more basic need that I'm surprised hasn't been mentioned more: its limited documentation. Maybe I'm asking for too much, but I sort of expect more from a language's documentation than a few Hello World-esque sample applications, (which don't even cover all the built-in keywords or types) and a language specification document. (which I don't see benefiting anyone but those looking to write lexers for the language) It's a little tedious to have to dig through a project's source repository just to figure out what it can actually do.
Anyways, with most of my projects, static typing would just makes things more tedious, but there were a small handful of projects in the past that would've been a lot easier if I had TypeScript, so I definitely won't rule it out for future use.
I don't mean to be a smart ass, but assembly isn't compiled - it's assembled. Furthermore, you're making a bit too large of a distinction between assembly and machine code, seeing as how machine code is just assembly in binary form, and each byte/word/dword/etc of machine code correlates directly to an instruction/operand/whatever in assembly. While I'm sure you knew all this, (and most likely used inaccurate vocabulary to keep things simple) many developers today unfortunately don't, so I thought I'd go ahead and correct the technicalities, as I feel it's pretty important for a developer to know how the underlying machine works.
@Everyone:
That said, my view is pretty similar to Michel's, though probably a bit more jaded. (Sad, given that I'm only 25) To avoid going off on an eight paragraph rant about the state of the development industry/community as a whole, and why I feel like it's growing more and more nauseating, I'll try to keep this simple: Very few things in this world are black and white. While some of us would like to force the act of development into a restrictive interpretation that fits their own usage cases, it's important to understand that none of us are all that special. We all have distinct preferences when writing code, and as a result, have different requirements for the language we choose to use as an intermediary to our end goals. For the sake of progress, please stop interpreting your own opinions and preferences for facts and "Best Practices".
Social commentary aside, I actually like the way that TypeScript implements its intended functionality. I tend to take a minimalist approach to most development, so I like the fact that it produces clean, readable JavaScript that's accessible from the global scope. (Unlike Dart, which I feel bloats the underlying DOM with unnecessary wrappers, and then packages the entire thing up in a closure to prevent access from the actual JavaScript) My problem with TypeScript revolves around a more basic need that I'm surprised hasn't been mentioned more: its limited documentation. Maybe I'm asking for too much, but I sort of expect more from a language's documentation than a few Hello World-esque sample applications, (which don't even cover all the built-in keywords or types) and a language specification document. (which I don't see benefiting anyone but those looking to write lexers for the language) It's a little tedious to have to dig through a project's source repository just to figure out what it can actually do.
Anyways, with most of my projects, static typing would just makes things more tedious, but there were a small handful of projects in the past that would've been a lot easier if I had TypeScript, so I definitely won't rule it out for future use.
Strike my criticism on the documentation, actually. In retrospect, it was an ignorant preconception of mine based on an incorrect assumption. Based on the "language specification" documents found in many other languages, I judged TypeScript's before actually taking a look. After finally getting around to taking a look, I see my expectations were completely off-base.
I could care less if this was the best thing since sliced bread. If it's from Microsoft I am not using it.
"It brings useful features into JavaScript in an ultimately compatible and syntax-friendly way using language constructs you're comfortable with."
That's looking at it from a C# developers perspective who won't advocate anything unless its strongly typed and in some way mimics the features C#. Personally I don't find the JavaScript syntax awkward at all.
That's looking at it from a C# developers perspective who won't advocate anything unless its strongly typed and in some way mimics the features C#. Personally I don't find the JavaScript syntax awkward at all.
The idea of progressively enhancing JavaScript with ES6-style syntax, and compiling to plain JavaScript without the need for a run-time, is actually nothing new - it's just an idea that suddenly got attention I suppose because Microsoft put their name behind it.
http://www.mascaraengine.com/
This has IDE support (Eclipse) and is very similar to TypeScript. It has been around for a good five years, as I recall.
It is a commercial product, so I am excited to see an open source alternative :-)
http://www.mascaraengine.com/
This has IDE support (Eclipse) and is very similar to TypeScript. It has been around for a good five years, as I recall.
It is a commercial product, so I am excited to see an open source alternative :-)
Web Essentails has dropped TypeScript support in favor of the official plugin. No more split screen.
Didn't see this mentioned here yet so I thought i'd just paste it:
http://madskristensen.net/post/Web-Essentials-2013-Where-is-the-TypeScript-support.aspx
Didn't see this mentioned here yet so I thought i'd just paste it:
http://madskristensen.net/post/Web-Essentials-2013-Where-is-the-TypeScript-support.aspx
Comments are closed.