TypeScript and the Road to 1.0(blogs.msdn.com)
blogs.msdn.com
TypeScript and the Road to 1.0
http://blogs.msdn.com/b/typescript/archive/2013/10/17/typescript-and-the-road-to-1-0.aspx
8 comments
I can't speak for CoffeeScript or ClojureScript, but Evan Czaplicky does get paid to work on Elm: http://elm-lang.org/blog/announce/Elm-and-Prezi.elm
I really love TypeScript because one of the projects goals is to become redundant one day. They're building what they hope JavaScript will get to evolve into.
That's not entirely true. While TypeScript is closely aligning itself with the proposed ES6 syntax for classes and modules, there is no expectation that ECMAScript will add optional static type checking. If you want statically typed JavaScript you are always going to need something like TypeScript.
With that said, as ES6 evolves and becomes more widely supported there will be aspects of the TypeScript compiler that will no longer be needed (e.g. classes, modules, fat arrow functions, etc.).
With that said, as ES6 evolves and becomes more widely supported there will be aspects of the TypeScript compiler that will no longer be needed (e.g. classes, modules, fat arrow functions, etc.).
> If you want statically typed JavaScript you are always going to need something like TypeScript.
I think that is a valid statement only within the context of the next ECMA release. In other words, that's not to say that whichever successive version after ES6 can't include it, or any version thereafter.
I think that is a valid statement only within the context of the next ECMA release. In other words, that's not to say that whichever successive version after ES6 can't include it, or any version thereafter.
You could make that argument about any missing feature. I haven't seen any serious support for optional typing in JS; so at this point it would be fair to say that GP is correct.
Well, there once was a forlorn EcmaScript version, aka ES4, which included rather similar concepts ( http://www.ecmascript.org/es4/spec/overview.pdf ) :
> Structural function types describe functions and methods. The type
> function (int, string): boolean
> describes a Function object that takes two arguments, one int and the other string, and which returns a boolean
Given that a great many other concepts from ES4 are finding their ways into ES6, it is not implausible that this one may also reappear into a more consensual specification someday.
> Structural function types describe functions and methods. The type
> function (int, string): boolean
> describes a Function object that takes two arguments, one int and the other string, and which returns a boolean
Given that a great many other concepts from ES4 are finding their ways into ES6, it is not implausible that this one may also reappear into a more consensual specification someday.
That is a good point that it could apply to any missing feature; my point is that to say that any particular feature is "never" going to make it into the language is short-sighted at best. Just a handful of years ago, you could say that "if you want some form of Function.prototype.bind then you're always going to have to polyfill it yourself", which of course would be a 100% inaccurate statement.
Fair enough. I just haven't heard of the ECMAScript standards committee seriously considering adding static type checking to the language. The closest things I've seen are the proposed guards [1] and trademarks [2] features for ES7.
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:guards [2]: http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:guards [2]: http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
Well, maybe you are mixing it with Google's Traceur-compiler?
https://github.com/google/traceur-compiler
https://github.com/google/traceur-compiler
To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side).
I really hope I can do something like
for (
I really hope I can do something like
for (
ra <- asycn_opA(),
rb <- async_opB(ra),
_ <- asycn_opC(ra, rb)
> it's the lack of language syntax support for asynchronous programming
spawn(function*() {
var ra = yield async_opA();
var rb = yield async_opB(ra);
yield async_opC(ra, rb);
});
FWIW, there is talk of adding async/await like features (C#, Python) to TypeScript in a post 1.0 release.
So if you used Q or a similar library:
Q.async(function*() {
var ra = yield opA();
var rb = yield opB(ra);
yield opC(ra, rb);
})().done();
Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6)
Here's your example rewritten in the 'monads' library (I probably need a better name):
monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });
Here's your example rewritten in the 'monads' library (I probably need a better name):
monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });
Is that open source? I'd be interested in taking a look.
[deleted]
Does optional typing really work? I've always felt (or presumed) that once you start putting types in, it kinda starts spreading everywhere and eventually will look like full static typing. I'd rather have tests than types.
It is good to see people try different things though, so congrats on release.
It is good to see people try different things though, so congrats on release.
I've used typescript on a few projects now. What I've seen is that when first hacking on some code I use almost no types. Maybe some are inferred, and that's nice, but if not whatevs. As I'm playing with the code though, like when I'm re-reading a function or if I'm trying to debug something, I'll often add in types to see if the compiler can point anything out.
In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky.
I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).
In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky.
I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).
>Does optional typing really work?
From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#.
Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything.
If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there.
Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.
From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#.
Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything.
If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there.
Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.
If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside.
You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).
You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).
> If it spreads everywhere then that is because it is valuable everywhere.
Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty.
My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty.
My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
> ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ...
That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error.
And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.
That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error.
And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.
> I'd rather have tests than types.
False dichotomy.
You want both and you need both.
False dichotomy.
You want both and you need both.
> I'd rather have tests than types.
Why? Let the compiler do the testing for you.
Why? Let the compiler do the testing for you.
Depends on what you mean. It doesn't spread in the same way that const correctness spreads in C++, i.e. once you add const somewhere you are forced to add it to a bunch of other places as well.
Optional typing works. Why wouldn't it?
Sorry if this comes across as somewhat tangential, but I'm still wondering if/when we'll have JavaScript runtimes (V8, Chakra, SpiderMonkey, whatever) that can export runtime type information, even if only enabled in a 'debug' mode?
I love the idea of optional typing being supported (whether in the base language or TypeScript/Closure/etc) but it's maddening to think of trying to have to add the type information manually to existing code, especially code with lots of good test coverage, knowing that the JavaScript runtime seems to have to figure it out anyway (at least based on talks about V8 from the past).
This kind of functionality seems even more important for projects like DefinitelyTyped, where people are trying to track the public API's for projects that sometimes have a lot of churn. Having runtimes export their runtime type information (which seems to have sufficient mapping to source based on existing debugger experiences in Chrome, IE10+, etc) and allowing the creation of tooling that can populate/check/etc the type information in source seems like a big potential win.
Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript adoption among existing projects seems reasonable, but TypeScript type information seems to still be 'add it yourself' for now?
Am I just missing something that makes this far more complex/difficult/intractable than I realize?
I love the idea of optional typing being supported (whether in the base language or TypeScript/Closure/etc) but it's maddening to think of trying to have to add the type information manually to existing code, especially code with lots of good test coverage, knowing that the JavaScript runtime seems to have to figure it out anyway (at least based on talks about V8 from the past).
This kind of functionality seems even more important for projects like DefinitelyTyped, where people are trying to track the public API's for projects that sometimes have a lot of churn. Having runtimes export their runtime type information (which seems to have sufficient mapping to source based on existing debugger experiences in Chrome, IE10+, etc) and allowing the creation of tooling that can populate/check/etc the type information in source seems like a big potential win.
Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript adoption among existing projects seems reasonable, but TypeScript type information seems to still be 'add it yourself' for now?
Am I just missing something that makes this far more complex/difficult/intractable than I realize?
I think the one think that TypeScript needs to get it going is modularity. If another project like [harp](https://github.com/sintaxi/harp) could use TypeScript as a library and could compile the code without having to result to system commands would be a great thing.
However, I think if someone came up with a system to add optional typing through the use of string literals it would be awesome. That way we can have perfectly valid JavaScript with the benefits of certain JavaScript engines and type checkers. The string literal would be before a function declaration like:
However, I think if someone came up with a system to add optional typing through the use of string literals it would be awesome. That way we can have perfectly valid JavaScript with the benefits of certain JavaScript engines and type checkers. The string literal would be before a function declaration like:
"add(Number, Number) -> Number";
var add = function(x, y) { return x + y; };
The TypeScript compiler can be used as a library, I believe.
The Closure Compiler has a whole type system that lives in doc comments:
https://developers.google.com/closure/compiler/docs/js-for-c...
and I believe there's a command line option for doing type checking. Alas, Closure Compiler is written in Java rather than JavaScript so you can't use it quite as seamlessly as TypeScript's compiler.
The Closure Compiler has a whole type system that lives in doc comments:
https://developers.google.com/closure/compiler/docs/js-for-c...
and I believe there's a command line option for doing type checking. Alas, Closure Compiler is written in Java rather than JavaScript so you can't use it quite as seamlessly as TypeScript's compiler.
I hope they'll integrate a JavaScript debugger to TypeScript and Visual Studio, possibly with source mapping. (I would specifically need Node.js debugging).
I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.
I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.
Visual Studio allows you to debug TypeScript directly with source maps if you install the free plugin: http://www.microsoft.com/en-us/download/details.aspx?id=3479...
What debugger is that using? Note that I'm not looking for debugging browser-side TypeScript/JavaScript code.
I think that's the point, there is no difference between TypeScript and Node.js Modules.
So how should I use a TypeScript module like typescript-collections with Node.js? If I don't add /// <reference path>, intellisense doesn't seem to work, but if I add /// <reference path> and import, I had some errors too.
1. https://github.com/basarat/typescript-collections
1. https://github.com/basarat/typescript-collections
I couldn't be more underwhelmed by what TypeScript has to offer vs vanilla JavaScript or CoffeeScript.
Reading through the marketing material from MS it seems like the entire value proposition is "statically typed languages make it easier to think about your program, also we added the class keyword so you don't feel lost"
I suppose if you believe those claims or are really interested in using MS development tools, TypeScript is for you.
IMO, ClojureScript is much more interesting and has a far greater value proposition for complex front-end development.
Reading through the marketing material from MS it seems like the entire value proposition is "statically typed languages make it easier to think about your program, also we added the class keyword so you don't feel lost"
I suppose if you believe those claims or are really interested in using MS development tools, TypeScript is for you.
IMO, ClojureScript is much more interesting and has a far greater value proposition for complex front-end development.
> ...also we added the class keyword so you don't feel lost
I believe EcmaScript 6 plans on adding the class keyword and TypeScript's implementation reflects the current draft of how classes in ES6 will work.
> ...statically typed languages make it easier to think about your program...
Out of curiosity, do you normally program using statically typed languages?
If not, I can see why you would be underwhelmed. Then again, I shouldn't be surprised by your reaction. This is Hacker News and TypeScript is by Microsoft.
I believe EcmaScript 6 plans on adding the class keyword and TypeScript's implementation reflects the current draft of how classes in ES6 will work.
> ...statically typed languages make it easier to think about your program...
Out of curiosity, do you normally program using statically typed languages?
If not, I can see why you would be underwhelmed. Then again, I shouldn't be surprised by your reaction. This is Hacker News and TypeScript is by Microsoft.
Not a huge fan of the class keyword in ES6 either...
I do not use statically typed languages and I have nothing against MSFT; I was solely commenting on TypeScript as a language.
I do not use statically typed languages and I have nothing against MSFT; I was solely commenting on TypeScript as a language.
Sorry about my Microsoft remark. It was kind of inflammatory. I didn't originally have it in my comment but was inspired to add it in for some reason. I try to keep my inflammatory rhetoric out of HN.
TypeScript's best feature (imo) is its (optional) static-typing so if you don't like static-typing to begin with, then yeah, it doesn't have much else to offer you.
To each his own.
TypeScript's best feature (imo) is its (optional) static-typing so if you don't like static-typing to begin with, then yeah, it doesn't have much else to offer you.
To each his own.
[deleted]
Well, value proposition is error messages and code completion, not "make it easier to think about your program". You may argue types don't help people much, but types do help tooling. (Not in the sense being untyped causes some tooling impossible, but in the sense being typed substantially reduces tooling implementation effort.)
This. TypeScript is a tool to sell Visual Studio, nothing more. If people are leaving VS because it can't do the magic things to JavaScript that it can to C# that's a big thread to Microsoft. TypeScript is about protecting the thing that makes them money.
Rubbish. TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, hence its rather quick adoption internally. Channel 9 has quite a lot of information about who is using it.
It does help Visual Studio and other tooling, but to say it is only "to sell Visual Studio, nothing more" is ridiculous.
It does help Visual Studio and other tooling, but to say it is only "to sell Visual Studio, nothing more" is ridiculous.
> TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively,
This implies that you can't develop large scale apps without type checking, which obviously isn't true.
What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as I originally said.
This implies that you can't develop large scale apps without type checking, which obviously isn't true.
What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as I originally said.
Nope, and incidentally its not the same thing you originally said at all
productively
You missed the most important word.
As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Productivity goes way up when the tooling can check basic errors.
(Part of me still wishes Haskell was an option for web scripting but I can dream)
productively
You missed the most important word.
As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Productivity goes way up when the tooling can check basic errors.
(Part of me still wishes Haskell was an option for web scripting but I can dream)
>> (Part of me still wishes Haskell was an option for web scripting but I can dream)
You're not the only one: http://www.di.unipi.it/didadoc/lfc/OtherPapers/Iteroperabili...
(n.b, this is from 1999)
You're not the only one: http://www.di.unipi.it/didadoc/lfc/OtherPapers/Iteroperabili...
(n.b, this is from 1999)
You're wrong, it can be done productively, the evidence is the thousands (tens of thousands?) of such apps that exist on the web, most of which were written in regular JavaScript.
You don't know how productive those developers were on those projects, nor do you know if TS would have made those developers more productive. Granted, the original claim wasn't comparative, but that's the point I'll make anyway.
Interesting theory, let's see how it plays out in the marketplace. If typed languages are indeed more productive we should see them start to win out in, say NPM, right? Today the overwhelming majority of NPM modules are JavaScript, but if the same modules can be written more productively in TypeScript or Dart or another typed alternative, you should start to see those modules win out. Fewer bugs, more able to concentrate on features.
Indeed over the long term modules isn't a bad idea as the interface requirements and discoverability would benefit massively from better tooling, a la optional typing.
Out of how many of the big ones are using scripting tools/language-to-language translation though? Hint: much more than you seem to be aware of/think.
Whether its Google Web Toolkit/Java/C#-to-Javascript generators, Closure templating, Haskell/Clojure/etc. mini-languages, TypeScript, etc. (Job Ad Requirements are one of the great ways to see all this stuff)
When you start working on big applications (e.g. I worked for 5 years on a huge electronic HR application covering everything from timesheets to recruitment to content management to CRM with multi-country, multi-language, multi-regulatory, multi-company, multi-site, multi-thousand users requirements) you realise JavaScript has serious shortcomings...although I still really like the language the tooling and knowledge advances have really, really helped.
Whether its Google Web Toolkit/Java/C#-to-Javascript generators, Closure templating, Haskell/Clojure/etc. mini-languages, TypeScript, etc. (Job Ad Requirements are one of the great ways to see all this stuff)
When you start working on big applications (e.g. I worked for 5 years on a huge electronic HR application covering everything from timesheets to recruitment to content management to CRM with multi-country, multi-language, multi-regulatory, multi-company, multi-site, multi-thousand users requirements) you realise JavaScript has serious shortcomings...although I still really like the language the tooling and knowledge advances have really, really helped.
Some people see a conspiracy everywhere. Get help!
The more likely conclusion is Microsoft is open-sourcing a tool the found useful internally when building large JavaScript apps.
The more likely conclusion is Microsoft is open-sourcing a tool the found useful internally when building large JavaScript apps.
Who said anything about a conspiracy? Conversation probably went something like:
Suit: People aren't using Visual Studio for JavaScript, why not?
VS PM: We can't do Intellisense properly, so people are using Sublime.
Suit: What can we do about that?
Anders: Let's create our own language that works better with VS.
Suit: People aren't using Visual Studio for JavaScript, why not?
VS PM: We can't do Intellisense properly, so people are using Sublime.
Suit: What can we do about that?
Anders: Let's create our own language that works better with VS.
> TypeScript is a tool to sell Visual Studio, nothing more.
I'll have you know I paid for my WebStorm license because of its TypeScript support =)
I'll have you know I paid for my WebStorm license because of its TypeScript support =)
Are TypeSscript and CoffeeScript really that much different?
From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.
From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.
I use CoffeeScript in my day job for the last 2 years.
I've been using TypeScript in my startup the last 6 months.
They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.)
CoffeeScript tries to do clever things for you, which often results in inefficient code. For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array. (Looping over 1000 elements at the end of a function? CS just allocated a new array which will be dynamically resized at runtime multiple times, allocated 1000 buckets for the elements.)
CoffeeScript also can't make up its mind about whether parens are necessary. Function with multiple params? Not necessary. Chained function, like jQuery? Necessary. Most of the time. Function with no params? Necessary, unless you use the 'do' syntax.
It's a mess.
TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through.
Bottom line: Both are better than vanilla JS, I'd say. But I work with CoffeeScript when I have to. I work with TypeScript because I choose to.
I've been using TypeScript in my startup the last 6 months.
They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.)
CoffeeScript tries to do clever things for you, which often results in inefficient code. For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array. (Looping over 1000 elements at the end of a function? CS just allocated a new array which will be dynamically resized at runtime multiple times, allocated 1000 buckets for the elements.)
CoffeeScript also can't make up its mind about whether parens are necessary. Function with multiple params? Not necessary. Chained function, like jQuery? Necessary. Most of the time. Function with no params? Necessary, unless you use the 'do' syntax.
It's a mess.
TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through.
Bottom line: Both are better than vanilla JS, I'd say. But I work with CoffeeScript when I have to. I work with TypeScript because I choose to.
> For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array.
Simple, just return anything else, or nothing at all:
Well, in some cases they're optional, but it's predictable and hardly "can't make up its mind". I've never run into a problem with this. Implicit parens wrap to the end of a line or block expression, and it feels pretty natural:
I prefer to think of parens as sometimes optional.
Simple, just return anything else, or nothing at all:
myFn = () ->
for el of array
# loop body
return
Well, in some cases they're optional, but it's predictable and hardly "can't make up its mind". I've never run into a problem with this. Implicit parens wrap to the end of a line or block expression, and it feels pretty natural:
f g h obj -> f(g(h(obj)))
f g, h, obj -> f(g, h, obj)
f().g().h obj -> f().g().h(obj)
I prefer to think of parens as sometimes optional.
I guess I should have phrased it better -- that both are basically trying to "improve" upon perceived faults in vanilla JS, as well as adding perceived useful functionality. It's just that "improve" and "useful" is an implementation-specific definition that's defined by the particular project owners.
Thanks for the thorough info though, I've only used TS a little and CS none at all, though from what I've seen I'd side with you in that CS tries to be too clever and/or is too foreign for my non-Ruby brain, whereas TS more closely melds with my skillset.
Thanks for the thorough info though, I've only used TS a little and CS none at all, though from what I've seen I'd side with you in that CS tries to be too clever and/or is too foreign for my non-Ruby brain, whereas TS more closely melds with my skillset.
I've used both extensively and I'd disagree with you on almost every point.
> For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile.
This myth won't die.
False. Typescript will choke on most JavaScript files from the web. Because you will need to include definition files for any external library calls. If you use jQuery, for example, the compiler won't like your $('.class').doStuff() calls because it won't recognize it until you go find the jquery.d.ts file to include at the top of your file. Also, TypeScript will struggle with the dynamic-ness of JavaScript. To prove this to yourself, paste the contents of typeface.js into the play compiler at www.typescriptlang.org/Playground/ and you'll see all the red squigglies that you have to fix.
On the other hand, if you can do it in JavaScript, you can do it in CoffeeScript, because CS is NOT statically typed. You can use js2coffee to convert any valid JS on the web to coffeescript.
In my testing it takes me 25 times longer to take legacy code and convert it to TypeScript than to convert it to CoffeeScript. That's because "valid JavaScript is NOT valid TypeScript."
> CoffeeScript tries to do clever things for you, which often results in inefficient code.
I find that CoffeeScript's results are BETTER than the TypeScript code. For example, CoffeeScript automatically does array length caching in it's for loops, resulting in much faster loops. It also correctly converts == to === in comparisons, eliminating many nasty JavaScript bugs. TypeScript does neither. In my analysis, TypeScript generates poorer code than CoffeeScript.
> CoffeeScript also can't make up its mind about whether parens are necessary.
Use them all the time if you want, CS isn't dogmatic about it. EcmaScript 6 (and TypeScript too) will be moving toward optional parentheses too. It's a nice feature.
> TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through.
Anders has done a fine job of making TypeScript look like C#. It's one redeeming trait is that it helps the tooling for allowing refactoring and intellisense. I find it cumbersome and you have to put a lot of ceremony into your code just to get it working. It is roughly 35% more lines of code to do the same thing in TypeScript that you could do in CoffeeScript, and you are fighting the compiler more often. I think TypeScript would be an incredible burden for enterprise applications because of the need to include definition files. Think of the joys of upgrading your version of jQuery and having to find the jquery.d.ts file to go with it.
I recently presented a talk at a conference on the two languages and after evaluating both languages in depth, CoffeeScript was the clear winner. Both in the code it produces, but also the amount of effort to develop in it.
> For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile.
This myth won't die.
False. Typescript will choke on most JavaScript files from the web. Because you will need to include definition files for any external library calls. If you use jQuery, for example, the compiler won't like your $('.class').doStuff() calls because it won't recognize it until you go find the jquery.d.ts file to include at the top of your file. Also, TypeScript will struggle with the dynamic-ness of JavaScript. To prove this to yourself, paste the contents of typeface.js into the play compiler at www.typescriptlang.org/Playground/ and you'll see all the red squigglies that you have to fix.
On the other hand, if you can do it in JavaScript, you can do it in CoffeeScript, because CS is NOT statically typed. You can use js2coffee to convert any valid JS on the web to coffeescript.
In my testing it takes me 25 times longer to take legacy code and convert it to TypeScript than to convert it to CoffeeScript. That's because "valid JavaScript is NOT valid TypeScript."
> CoffeeScript tries to do clever things for you, which often results in inefficient code.
I find that CoffeeScript's results are BETTER than the TypeScript code. For example, CoffeeScript automatically does array length caching in it's for loops, resulting in much faster loops. It also correctly converts == to === in comparisons, eliminating many nasty JavaScript bugs. TypeScript does neither. In my analysis, TypeScript generates poorer code than CoffeeScript.
> CoffeeScript also can't make up its mind about whether parens are necessary.
Use them all the time if you want, CS isn't dogmatic about it. EcmaScript 6 (and TypeScript too) will be moving toward optional parentheses too. It's a nice feature.
> TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through.
Anders has done a fine job of making TypeScript look like C#. It's one redeeming trait is that it helps the tooling for allowing refactoring and intellisense. I find it cumbersome and you have to put a lot of ceremony into your code just to get it working. It is roughly 35% more lines of code to do the same thing in TypeScript that you could do in CoffeeScript, and you are fighting the compiler more often. I think TypeScript would be an incredible burden for enterprise applications because of the need to include definition files. Think of the joys of upgrading your version of jQuery and having to find the jquery.d.ts file to go with it.
I recently presented a talk at a conference on the two languages and after evaluating both languages in depth, CoffeeScript was the clear winner. Both in the code it produces, but also the amount of effort to develop in it.
TypeScript appears to compile even in the face of undefined variables.
Just went to the playground and dropped a random jQuery sample in: http://www.typescriptlang.org/Playground/#src=%24(%20documen...
You get squiggles yes, but you also get valid javascript. So it looks like you can paste random javascript into TypeScript and get it to compile. I went and tried with the actual compiler (to make sure it's not some artifact of the playground website), and confirmed you get a proper .js file out (and 2 messages, about $ being undefined).
Quick google makes it sound like getting rid of the squiggles / messages is pretty easy: http://stackoverflow.com/a/12755602/80572
I'm not sold on TypeScript yet (or any of the transpiled javascript languages, honestly), but this:
> False. Typescript will choke on most JavaScript files from the web.
Seems to be the actual false statement in this thread.
Just went to the playground and dropped a random jQuery sample in: http://www.typescriptlang.org/Playground/#src=%24(%20documen...
You get squiggles yes, but you also get valid javascript. So it looks like you can paste random javascript into TypeScript and get it to compile. I went and tried with the actual compiler (to make sure it's not some artifact of the playground website), and confirmed you get a proper .js file out (and 2 messages, about $ being undefined).
Quick google makes it sound like getting rid of the squiggles / messages is pretty easy: http://stackoverflow.com/a/12755602/80572
I'm not sold on TypeScript yet (or any of the transpiled javascript languages, honestly), but this:
> False. Typescript will choke on most JavaScript files from the web.
Seems to be the actual false statement in this thread.
Thanks for trying that out the jQuery example. They look to be making the compiler (or the playground site) more permissive lately. This didn't work in May when I last tried it out.
I've used the typescript compiler on a randomly-chosen JS library (typeface.js http://typeface.neocracy.org/typeface-0.15.js ) and it had dozens of compiler errors for me to fix before it would compile. The playground is now accepting them for some odd reason. This seems to be recent behavior or perhaps the node.js version of the compiler behaves differently?
I've used the typescript compiler on a randomly-chosen JS library (typeface.js http://typeface.neocracy.org/typeface-0.15.js ) and it had dozens of compiler errors for me to fix before it would compile. The playground is now accepting them for some odd reason. This seems to be recent behavior or perhaps the node.js version of the compiler behaves differently?
One thing that threw me off initially is the fact that typescript will complain about errors, but still do the translation of TS -> JS. For example:
In my experience so long as you don't have any syntax errors, tsc will give you back javascript. This is partly because the translation from typescript to javascript is incredibly straightforwards and ignores the types completely. Writing a nonvalidating, dumb but super fast ts -> js transpiler is about an afternoon's worth of work, especially if you bootstrapped from the typescript parser and tests.
var s = 'hello';
s.toExponential();
In my experience so long as you don't have any syntax errors, tsc will give you back javascript. This is partly because the translation from typescript to javascript is incredibly straightforwards and ignores the types completely. Writing a nonvalidating, dumb but super fast ts -> js transpiler is about an afternoon's worth of work, especially if you bootstrapped from the typescript parser and tests.
The title of the article is "...the Road to 1.0", you can imagine that they are continuously improving it to get there.
While it's not my opinion, I did read this quote somewhere:
"CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"
"CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"
If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.
If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative.
I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice.
As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer.
Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice.
As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer.
Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.
I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous.
The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections.
Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections.
Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
Transparent and instantaneous is my experience using grunt to watch and compile CS. It will only compile the changed file, not the entire codebase. It seems to happen instantaneously for me on file save, or at least within the time it takes for me to switch from my editor to my browser.
CS is aimed at making you more productive, TS is aimed at making you more correct, checking errors early.
Just my observation.
Just my observation.
>[TS and CS] both basically solve the same problems
TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation.
TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.
TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation.
TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.
CS also saves keystrokes and makes code more readable by offering things such as:
Reducing boilerplate for loop code:
Reducing boilerplate for loop code:
CS:
for el, index in arr
el.doThing(index)
JS:
for(var index=0; index < arr.length; index++) {
var el = arr[index];
el.doThing(index);
}
CS:
for own k, v of obj
console.log "#{k} is #{v}"
JS:
for(k in obj) {
if(!obj.hasOwnProperty(k))
continue;
console.log(k + " is " + obj[k]);
}
CS:
foobar = (foo = "default", bar = "shmefault") ->
# Go on...
JS:
function foobar(foo,bar) {
if(foo === null)
foo = "default"
if(bar === null)
bar = "shmefault";
// Go on...
}
CS:
str = "There are #{num} #{item}s available for $#{price} each"
JS:
str = "There are " + num + " " + item + "s available for $" + price + " each";
CS:
if obj?.prop?.exists?
console.log "obj.prop.exists"
JS:
if(typeof obj !== "undefined" && obj != null && obj.prop != null && obj.prop.exists != null)
console.log("obj.prop.exists")For kicks, here's Dart versions of those:
Reducing boilerplate for loop code:
Better iteration over objects:
Default function params:
Reducing boilerplate for loop code:
var index = 0;
for (var el in arr) {
el.doThing(index++);
}
Better iteration over objects:
obj.forEach((k, v) => print("$k is $v"));
Default function params:
foobar([foo = "default", bar = "shmefault") {
// Go on...
}
str = "There are $num ${item}s available for \$$price each"Does Dart compile that for loop down to a regular for loop instead of the JS for..in loop? Or are there any safeguards against someone adding a property to an array (not that they should)?
a = [1,2,3];
a.prop = "oops";
for(el in a)
console.log(el);
// > 0
// > 1
// > 2
// > oopsYes, but that's just some syntactic sugar. That stuff doesn't help with tooling/scaling.
By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.
By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.
Language is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool.
CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling.
In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely.
If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.
CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling.
In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely.
If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.
> [JS generated from CS] runs faster [than JS generated from Dart]
There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good.
> it runs faster thus has its strength in scaling
"Scaling" as in: more developers, more files, more lines of code. Bigger projects.
CS doesn't help with that one bit. It's just as difficult to handle as JS. This is why Google came up with stuff like the Closure Compiler, GWT, and now Dart.
> Syntax is the only thing we can compare.
There are also semantics and the whole environment. Syntax is a small fairly unimportant detail.
There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good.
> it runs faster thus has its strength in scaling
"Scaling" as in: more developers, more files, more lines of code. Bigger projects.
CS doesn't help with that one bit. It's just as difficult to handle as JS. This is why Google came up with stuff like the Closure Compiler, GWT, and now Dart.
> Syntax is the only thing we can compare.
There are also semantics and the whole environment. Syntax is a small fairly unimportant detail.
> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS.
Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or other features from TS/Dart.
Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or other features from TS/Dart.
> AMDs like Require.js or CommonJS
That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general.
Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other.
I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issues. Naturally, it's also way more convenient to use. You just import something. Done.
> doesn't need static typing or other features from TS/Dart
You also don't need a seat belt or airbags. If you don't make any mistakes, you'll be fine.
However, from a pragmatic point of view, these static checks are very handy. If you rewrite some parts of your code, the analyzer will tell you if you screwed something obviously up. It catches all the stupid mistakes, which means you can fully focus on the logical ones.
With JavaScript/Python/etc you have to run the code and actually hit that particular branch to trigger some sort of error/exception which will eventually help you to identify the actual issue.
You should just give it a try. Try any language/IDE combination which offers good tooling. Tooling can remove a lot of friction. There really is a point to all of this.
That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general.
Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other.
I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issues. Naturally, it's also way more convenient to use. You just import something. Done.
> doesn't need static typing or other features from TS/Dart
You also don't need a seat belt or airbags. If you don't make any mistakes, you'll be fine.
However, from a pragmatic point of view, these static checks are very handy. If you rewrite some parts of your code, the analyzer will tell you if you screwed something obviously up. It catches all the stupid mistakes, which means you can fully focus on the logical ones.
With JavaScript/Python/etc you have to run the code and actually hit that particular branch to trigger some sort of error/exception which will eventually help you to identify the actual issue.
You should just give it a try. Try any language/IDE combination which offers good tooling. Tooling can remove a lot of friction. There really is a point to all of this.
Don't get me wrong, I agree that the overall experience is important - the best language in the world would be shit if you had to use notepad.exe to develop in it.
You like your IDEs and static typing and tooling, and it works for you (and for many others). I like my CoffeeScript, my AMD/CJS modules, and testing, and it works for me (and for many others).
Your experiences and assertions are wildly different than mine. I've never found AMD modules a problem. I have found overwrought and verbose code to be a problem. File headers? Interfaces? Java-style OOP in my JS? No thanks.
I think we're both just stating subjective opinions without substantiation, so I'm done here.
You like your IDEs and static typing and tooling, and it works for you (and for many others). I like my CoffeeScript, my AMD/CJS modules, and testing, and it works for me (and for many others).
Your experiences and assertions are wildly different than mine. I've never found AMD modules a problem. I have found overwrought and verbose code to be a problem. File headers? Interfaces? Java-style OOP in my JS? No thanks.
I think we're both just stating subjective opinions without substantiation, so I'm done here.
> File headers?
No.
> Interfaces?
Implicit interfaces. It's kinda handy.
> Java-style OOP in my JS?
I'm not sure what qualifies as "Java-style" OOP. Is the stuff from ES7 also "Java-style"? How about the stuff from CS?
Well, you don't have to use classes. You can do everything with functions if you want.
> I think we're both just stating subjective opinions [...]
The difference is that I actually tried it.
No.
> Interfaces?
Implicit interfaces. It's kinda handy.
> Java-style OOP in my JS?
I'm not sure what qualifies as "Java-style" OOP. Is the stuff from ES7 also "Java-style"? How about the stuff from CS?
Well, you don't have to use classes. You can do everything with functions if you want.
> I think we're both just stating subjective opinions [...]
The difference is that I actually tried it.
So have I, chief.
I've used heavy IDEs before with Java, and I much prefer a simpler text editor like Vim or Sublime. I tried out TS a while back. All the examples I've seen were overweight, much like classical enterprise Java. Too much cruft.
Anyway, enjoy TS.
I've used heavy IDEs before with Java, and I much prefer a simpler text editor like Vim or Sublime. I tried out TS a while back. All the examples I've seen were overweight, much like classical enterprise Java. Too much cruft.
Anyway, enjoy TS.
You "scaling" is just a syntactic sugar to the underlying package/module solution. In js/coffee the syntax just don't care about it, and you use package/module with a library.
Most of the semantics or environment stuff are translated into function calls at last. Then the difference becomes the syntax again: how to use that function? Call it directly or translate a syntax?
I like coffee because it is practical scripting: Need code completion? Don't repeat yourself. Can't code without IDE? Make the language easier to use then you ain't gonna need it. Some people just can't believe a language can be that good without IDE, but remember: you interact with IDE through a language on keyboard/mouse too.
Most of the semantics or environment stuff are translated into function calls at last. Then the difference becomes the syntax again: how to use that function? Call it directly or translate a syntax?
I like coffee because it is practical scripting: Need code completion? Don't repeat yourself. Can't code without IDE? Make the language easier to use then you ain't gonna need it. Some people just can't believe a language can be that good without IDE, but remember: you interact with IDE through a language on keyboard/mouse too.
It's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes.
That's awesome that Dart includes those features, and I wish that I had lexical scoping in CS. But closures are a pretty easy workaround.
> TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.
That sounds like an IDE/editor feature, not a language feature. Setting up macros/snippets/etc in an IDE/editor will save keystrokes for most any language.
That's awesome that Dart includes those features, and I wish that I had lexical scoping in CS. But closures are a pretty easy workaround.
> TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.
That sounds like an IDE/editor feature, not a language feature. Setting up macros/snippets/etc in an IDE/editor will save keystrokes for most any language.
> That sounds like an IDE/editor feature, not a language feature.
Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.
Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.
By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit <tab> and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate).
CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I like JS, and I like that it doesn't try to shoehorn in concepts foreign to JS.
It's possible to build scalable systems in JS/CS without what TS/Dart offers. You might not be able to do so from your experience, but that doesn't mean it's not possible.
CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I like JS, and I like that it doesn't try to shoehorn in concepts foreign to JS.
It's possible to build scalable systems in JS/CS without what TS/Dart offers. You might not be able to do so from your experience, but that doesn't mean it's not possible.
That would be "snippet expansion" (pioneered in TextMate, if I'm not mistaken — well, that's where I saw it first).
"Autocompletion" is… "automatic": you type the beginning of a method name and you get a contextual menu following your cursor showing a list of suggestions. Many editors have that feature, either built-in or via plugins, but it's definitely an area where IDEs shine. If the editor/IDE has a way to infer scope, you get good completion, if not, you get mediocre completion.
But "snippet expansion" or "templates" as they are called in some IDEs is very easy and doesn't require statical analysis or whatever.
"Autocompletion" is… "automatic": you type the beginning of a method name and you get a contextual menu following your cursor showing a list of suggestions. Many editors have that feature, either built-in or via plugins, but it's definitely an area where IDEs shine. If the editor/IDE has a way to infer scope, you get good completion, if not, you get mediocre completion.
But "snippet expansion" or "templates" as they are called in some IDEs is very easy and doesn't require statical analysis or whatever.
> By "autocomplete" you mean [...]
All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method.
If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete "bar").
It's similar to writing C#, AS3, or Java with a good IDE. If you have never experience any of that, maybe you should give it a try.
> It's possible to build scalable systems in JS/CS without what TS/Dart offers.
Sure. It just requires more time and money.
You can, for example, also chop down a tree by using an axe instead of a chainsaw. There is always a more difficult more time consuming way to do something.
All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method.
If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete "bar").
It's similar to writing C#, AS3, or Java with a good IDE. If you have never experience any of that, maybe you should give it a try.
> It's possible to build scalable systems in JS/CS without what TS/Dart offers.
Sure. It just requires more time and money.
You can, for example, also chop down a tree by using an axe instead of a chainsaw. There is always a more difficult more time consuming way to do something.
Right, but that's about a certain IDE not the language itself, regardless of whether it's TS or JS. Sublime text does that for any JS file, as does Vim with the right plugin. I bet whatever IDE you're using will do that with bare JS. It's not "guessing" with JS completion any more than it is with TS. Again, autocompletion has nothing to do with the language.
> Sure. It just requires more time and money.
Care to back that up? I'll wait over here. Oh, unless you meant that it would take more time and money for you. Then sure, I agree.
> Sure. It just requires more time and money.
Care to back that up? I'll wait over here. Oh, unless you meant that it would take more time and money for you. Then sure, I agree.
> that's about a certain IDE not the language itself
This stuff is only possible if you can analyze the code statically.
With JS, which is running in a browser, you don't know anything. You don't know what other kinds of scripts are running on that page. You don't know which globals these introduce or which built-ins they modify.
E.g.:
For tools, this is a big problem.
In Dart, the analyzer knows about all these things. If the function is annotated, I'll get all the tooling and checks.
> Care to back that up?
No. You can't even imagine what good tooling is like. Naturally, you're blind to the friction which is caused by a lack of good tooling.
This stuff is only possible if you can analyze the code statically.
With JS, which is running in a browser, you don't know anything. You don't know what other kinds of scripts are running on that page. You don't know which globals these introduce or which built-ins they modify.
E.g.:
Math.round(5).length
For tools, this is a big problem.
In Dart, the analyzer knows about all these things. If the function is annotated, I'll get all the tooling and checks.
> Care to back that up?
No. You can't even imagine what good tooling is like. Naturally, you're blind to the friction which is caused by a lack of good tooling.
[deleted]
The language itself seems like a winner as well. Its conservative design makes it the perennial dark horse of the compiled-to-JS language family, but that's also what makes it most attractive to me. It's a thin-enough skin over the underlying language that you get the familiar Javascript syntax (as per Dart) while also retaining the ability to understand the generated code (as per Coffeescript). It's also got well-defined corporate backing, which in a professional environment gives me more peace of mind than recommending Coffeescript (does jashkenas get paid to do this?), Clojurescript, or Elm (I'm somewhat concerned about Dart here as well, at least until Google starts using it in production). These properties mean that I'd happily recommend TypeScript for client-side enterprise software development (but only once the compiler hits 1.0, of course).