The typescript playground[1], which lets you try TypeScript in your browser, looks so professional and finished when compared to CoffeeScript[2] or Dart[3]. As someone who attempted a half-baked Rust to JavaScript transpiler[4], I am floored with the packaging of TypeScript (tutorials, specs, editor integrations, npm, playground). At the moment, the only missing feature that my jealousy could point out is autoscrolling (see lexer example in my demo)!
I don't think any of them are very polished or professional.
The CoffeeScript site reports errors unintuitively yet visibly in the top-right corner. The TypeScript site requires that you scroll right to the error and then realize it's not just your browser complaining about a misspelling. But both are better than the Dart sandbox, which basically only says "error".
None of them get page layout right. Dart and TypeScript have obvious input/output boxes, but both get demerits for their handling of overflow. Dart just grows the box which is acceptable, but TypeScript thinks their customized scroll bars are better than native. CoffeeScript handles overflow reasonably, but it's a big translucent overlay causing all sorts of moire on my screen.
I suppose if you're on a Windows computer you might be tricked into thinking the TypeScript page looks reasonable, since it probably fits in. For me, though, I'm having a hell of a time figuring out what's a button and what's not.
I hope the respective developers are listening. It should be noted that most of these 'try X' editors are not marketed as a product, but I do agree that calling it 'professional' was mistake. The warts show up during heavy usage of a tool (the overflow example) and I was quick to reach conclusions based on the first impressions. But all the features like completion, line numbers, syntax highlighting do deserve respect (I couldn't find a better executed alternative!).
Also, confirming that I am on a Windows computer :)
The Try it for CoffeeScript was meant to be extremely simple, not to replace JSFiddle and such. The errors will be moved to the output area in next release. Someone might get around to implementing proper editor into it (say CodeMirror). That said, MS has people they pay for developing TypeScript, CoffeeScript is just of bunch of folks who enjoy working on the compiler and helping others. You certainly shouldn't expect the same level of secondary effort as in Dart or TypeScript - yet I think CoffeeScript is doing great on this front.
I’m glad to hear that compile errors will finally be displayed in the output area in the next release (https://github.com/jashkenas/coffee-script/pull/3425). If anyone feels like improving that interface even further, they could try implementing the mockup in this issue:
I am huge believer in typescript. This has made me consider html5 seriously for the first time.
There are still many dark spots (hello js scope, bs standards), but with Typescript I've already built stuff I could have only done AIR in the past.
I find it ironic that MSFT tried to compete with Flash with Silverlight (and failed I think), and to me, Typescript means end of the line for Flash/AS3.
The language is dead easy to pick up, and IntelliJ has been a really good IDE with it.
We've been using TypeScript for 9 months now on a large project. It's fantastic. There's now way I'll go back to pure JavaScript again.
The type system just catches so many defects, and they're of the kind that are hard and boring to find (typos).
Plus IntelliSense integration (including jsdoc) is great.
On the downside, our project takes some time to compile so we had to build a tool to do it incrementally. Plus it doesn't play well with one-class-per-file structures (but I expect that to be fixed).
Agreed, TypeScript is great, but the compiler is excruciatingly slow. I have to segment my app into multiple sub-build areas and only build a subset at a time, which is annoying because I frequently end up making small changes outside of that subset of code. My app is only around 25000 lines of code and a full compilation still takes around 50-60 seconds which, in a JavaScript workflow, is a lot of friction.
I was expecting something in the order of minutes. Seeing as I work at a place where full build used to took about three hours on a server. I see how it's not ideal though.
In a typical Javascript workflow, near-instant feedback is the baseline.
I really like how Facebook's Hack has a local file system monitor which incrementally compiles on file changes. I haven't used it yet, but it sounds like a nearly ideal compromise.
Typescript has a command line option for this as well.
As far as I can tell, the language would also support a non-validating mode that would be more or less instantaneous (the transformations it performs are all local, and none of them involve knowledge of the types involved).
I've never actually used TypeScript until today, but just the tutorial code takes forever to compile, this snippet took 2 seconds for example, whaaat??
interface Person {
firstname: string;
lastname: string;
}
function greeter(person: Person) {
return 'Hello, ' + person.firstname + ' ' + person.lastname;
}
var user = {firstname: 'John', lastname: 'Doe'}
document.body.innerHTML = greeter(user);
It's a shame really, because it looks like a really cool project.
Visual Studio uses the same compiler written in TypeScript/JavaScript. The Visual Studio integration is done in C# but only for interop with the Visual Studio APIs, there is only one version of the TypeScript compiler.
I know when Palantir was developing Eclipse tools for TypeScript they posted to the Codeplex project regarding performance issues and the team from MS responded with suggestions about caching and only recompiling the minimal targets necessary.
Strange, I'm able to compile 12k lines of code (that's output) in 5.2 seconds. Running this on a watch + autoreload process, so 6 seconds after I hit save, the results show up in my web browser. I do remember 0.9.1 being excruciatingly slow though. Edit: forgot to mention, I'm using the NPM package
It takes under 5 seconds for me to compile my project of about 5000 lines. So it's not really a problem for me yet, though I agree it would be if the waitingtime where to become any longer. Besides that, I've also been really enjoying developing in Typescript!
Same here for a project three times this size. Still I find it extremely slow compared to CoffeeScript I was using before. I'm used to saving the file and instantly refreshing the browser/rebooting node.js.
Typos account for a significant amount of my javascript debugging. To have both intellisense and compile time checking for this would be a huge time saver.
Alternatively, make less typos. Get something basic set up like jshint in your editor of choice (will warn for unused and undeclared variables), that kinda thing.
Although it's more of a patch. A proper IDE for JS would be neat, but it'd need to support popular DI frameworks and the like.
Can you give an example of a defect that the type system catched? You said typos but that's something JSLint would catch as well so not sure if it's a strong argument.
Misspelled magic strings, which were replaced with enumerations.
We also had a number of bugs with unexpected type use - like a function which expected a boolean but was given a string, or even more common number/string failures.
It is very close. If you used lambda expressions they will be replaced with function syntax and _this references, but other than that it is almost the same.
Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure JS is bit hard to maintain and it does occasionally pisses me off but at the same time it is liberating.
Not having to constantly keep adding types all over, not having to constantly refactor things because I now accept object instead of an int etc is refreshing. And best of all, not having compile at all is fast and simple. I'm only using JS frameworks that doesn't force me do build before testing the page and retains purity of JavaScript (that means no simulations of traditional OOP). Yes, sometime I do make bad mistakes and spend some time chasing down bugs that would have been caught in typed languages. However overall I find cost of adding types all over and maintaining them over the evolution of code is actually higher. It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.
Just because JS doesn't have type checking I'm now set in to mindset of doing quick tests of small changes, write more elaborate tests and so on. Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages.
But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?
I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all.
With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase.
Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.
> But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't?
No, it is because:
- Unit tests have zero value over new features
- Project development tends to be outsourced to teams with high attrition rates
- Most of the time cheaper developers are what matter
- No one cares about quality, because there are no options to get the software from somewhere else
> Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine
>Not having to constantly keep adding types all over
You don't have to if you don't want to.
>not having to constantly refactor things because I now accept object instead of an int etc is refreshing
Again this is your choice, you can omit types if you want
TS gives you the option to add typing if you want it. And that is huge in my book, try refactoring a large enterprise app written in JS vs. written in TS.
Okay so if you don't use types, wouldn't you would just be writing vanilla javascript and would have no reason to use typescript in the first place though?
It has a somewhat nicer syntax for functions and better scoping rules, but you could certainly get that from a more lightweight js extension like coffeescript yeah.
Not exactly, there is still type inference mechanism at work which, combined with DefinitelyTyped (https://github.com/borisyankov/DefinitelyTyped) declarations will get you quite a lot type safety even if you won't write any type declaration by yourself.
"cool algorithms that could have inferred types as much as possible" - like Hindley-Milner type system? Like OCAML/Haskell/F#? There is only one reason JS could be chosen. Because it's everywhere. Almost any other modern language is realistically better. But unfortunately Web is Closed to JS/HTML/CSS.
I don't know very much about TypeScript, yet, but I'm doing some research and I'm going to advocate it on my next project. From what I already know:
> Not having to constantly keep adding types all over,
TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost.
> and retains purity of JavaScript
That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead.
Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript.
> adding types all over and maintaining them over the evolution of code is actually higher
I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example.
> It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension.
Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone?
> Just because JS doesn't have type checking
As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.
I have performed QA tasks on both, and find that either JS developers are better or going pure vanilla makes a much stabler product. The TypeScript projects I have seen had some major flaws and requests (vs bugs) always turned into low priority because of the inability to perform the task.
I think it's easy to explain: TypeScript is a new technology and programmers will have very little experience in using it. It's completely impossible to find "TypeScript programmer with 5 years of experience" for example. On the other hand, JS is stable and much older and you can easily assemble a team of highly experienced people.
Relative strengths and weaknesses of TypeScript will be only visible after it's around long enough to get its own best practices and experienced programmers. I see the same process with CoffeeScript - in the beginning average CS code was much worse than average JS, but now they are comparable and the advantages of CS are starting to be visible.
That's of course on average. It's still possible to get a few people with enough knowledge to be able to use TS effectively, but I think it's hard enough to make it very rare. It's unfortunate, but technologies - and especially languages - take very long time to mature. In short, your impression is probably correct, but it's not because of TypeScript features; we need to wait a few years before we can compare TS and JS products success rates.
TypeScript is something I'm still trying to get more buy-in from my team, but the issue is the lack of decent autocomplete/static analysis in anything other than Visual Studio. I'm working on that problem myself, actually.
From past experience, their support is good, but one significant thing I missed was type inference:
// function signature
getNumber(context: any, callback: (result: Number) => void);
// calling that function
// unfortunately, here the type of num is any
// unless I specify it manually
getNumber(..., (num) => { ... });
+1 for IntelliJ. Their support for typescript is pretty good. I actually tried Visual Studio and IntelliJ's webstorm, and descided to go with Webstorm. Also the support has improved over time, though I'm still hoping for some nice code generation support for Typescript
It'd be great if there was a compiler that would compile TypeScript to asm.js [0]. Adding type-safety in TypeScript is only for the programmer -- when you compile it to Javascript, you don't get any performance increase. But, if you could compile it to asm.js, you'd actually get some performance increase out of it. (Note: I don't know much about TypeScript or asm.js, so if what I just said is completely untrue, I'd love to know why.)
A well-typed subset of JavaScript (such as that produced by the TypeScript compiler) follows some very simple rules. Modern JS engines will recover 95+% of that performance automatically thanks to optimizations such as "hidden classes". This is also true of code that conforms to the Google Closure compiler's "type system", and by extension to idiomatic code produced by all of the more advanced compile-to-JS languages.
To my understanding asm.js is a restricted subset of JS that allows for optimisations to be performed that would not otherwise be possible. In a similar way to how Java bytecode can be interpreted more efficiently compared to a non-compiled language, like Python.
With that in mind, sure you could target asm.js with a high level language that requires memory management, but why couldn't you also target it with a language that assumes GC. JS interpreters have this GC component built in already. Essentially I don't see how it is different from Java + Java bytecode + the JVM, which does perform GC.
asm.js is a subset of JavaScript, and to be easy to optimize, it removes most of the dynamic stuff from JS and leaves a simple, low-level dialect that is basically equivalent to LLVM IR or to C.
You can compile many things to C and LLVM IR, like C++, C#, and so forth. You can compile the VMs of dynamic languages like Python, Lua and Ruby, but compiling them directly would be inefficient - you'd need type checks all over the place. You need a custom VM to be fast on those.
asm.js can run Lua at close to the speed of the normal Lua VM running natively, so this approach is very feasible. But, for JavaScript itself, it probably doesn't make sense, the current VMs are the best that can be done.
However, a subset of TypeScript - without classes, without weird prototype things, just arrays and numbers and computation on those - could be compiled to asm.js. That might be an interesting project to try out.
OK, so are you saying that compiling the language's runtime environment, including the GC, to asm.js would not be efficient enough? That makes sense.
I guess I was hoping that there may be some way to compile the runtime such that the GC wouldn't need to be compiled, and the GC of whatever is interpreting the asm.js code (e.g. SpiderMonkey) could be used instead.
That's roughly what happens when TypeScript gets compiled to JavaScript, it can use the browser's GC. asm.js is used to avoid the browser's GC, either when the original code doesn't need a GC since it uses manual memory management, or it uses a different type of GC from the browser and wants to use that instead (which is effectively the same thing).
The default python implementation(cpython) compiles to bytecode before interpreting(the default c implementation of ruby also does this as of 1.9, before that it did straight interpretation). The difference between compiling to bytecode ahead of time vs at run time is more of a packaging difference and probably not the biggest cause of the speed gap between the languages, although I suppose the python import mechanism doing strange stuff and hitting filesystem too often could slow things down. The reason the most common java implementation(oracle hotspot/openjdk) is fairly fast(there are other fast implementations) is that it includes a fast interpreter written in assembly(although a c++ backup version exists for non-x86 ports) and a good just in time compiler. It also has a much more advanced gc then python. Another thing that makes a difference is that python has a global interpreter lock that only allows one python thread(c extensions can run several of their own threads) to run at a time(despite the number of cpu cores/max native threads) because python's refcounting gc would cause significantly worse single threaded performance if multiple threads were to be run at the same time.
Thanks for the explanation. I am fairly familiar with the Java internals, but I haven't used Python much, and was just using it as an example. I didn't realise that it was compiled to bytecode before interpreting. I suppose it doesn' make sense for any production-ready language to not have at list a JIT compilation system now that I acually think about it.
This is just a temporary limitation of asm.js because it has no access to garbage-collected data. In the future it should have support for managed languages.
> Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?
A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages. [1]
You wouldn't be able to compile it to asm.js because of the very different memory models, which means you wouldn't be able to take advantage of any alternative runtime paths the js runtime has for asm.js.
You could, however, use the type annotations part of the asm.js spec to take advantage of the fact most js runtimes are going to be attempting to optimise the heck out of them.
Could someone be so kind as to explain why I should consider Typescript over Coffeescript in future projects?
I've been using CS for the past year or two, but I'm hearing a lot of buzz around TS for the past few months. It would be really nice to have a better idea as to why it should be best to move now - is it really that much better?
(I love the CS tools available on PyCharm; they really made my life easier. That said, I think that there are similar TS tools available as well)
One reason (as I see it) is that TypeScript is implementing ES6 features along with the type-specifc stuff, so it's going to end up in a place where it's very compatible with the 'future' of JavaScript.
CoffeeScript will always be something quite different. I love it, but that difference makes me nervous. ES6 ought to bring a lot of the features I like about CoffeeScript into JavaScript.
It is notable that TypeScript chose not to track the ES6 modules standard for the last half a year: https://typescript.codeplex.com/discussions/446695 The modules you are writing in TypeScript are not compatible with ES6.
The TypeScript language team has yet to prove that they will track the specs and implement features as spec'd. I think claiming that they will "implement ES6 features" is a bit pre-mature. So far, they have implemented a few drafts and ignored a few others. A mixed bag.
I don't want to troll here but "very compatible" sounds like MS best days of EEE - Typescript still IS a different lang. Question is what if future Javascript will go in a different direction than todays Typescript ?
Typescript main feature is tooling but I would rather go with lang where I'm not second class citizen on non-windows (eg. Dart's editor works on Windows/OSX/Linux)
Do you really feel JavaScript has that luxury? Seeing as how widely deployed and used it is I feel that it can't go in a completely different direction anytime soon.
I contribute to the Doppio JVM project (https://github.com/int3/doppio), which we initially wrote in Coffeescript. About 9 months ago, we decided to port the whole thing (~10kloc) to Typescript, and it proved really useful:
- Typescript is a superset of Javascript (mostly), so we ported by converting all the Coffeescript sources to Javascript and renaming them with .ts extensions. There was a bit of cleanup involved in getting modules to play nice together, but most of the code ran without modification.
- The JS that the Typescript compiler generates is much easier to read, in part due to less "magic" in the language.
- It also makes performance much easier to reason about, for the same reasons. One issue that bit us several times was Coffeescript's auto-return feature, which was invisibly accumulating large arrays of values from our interpreter's bytecode loop! This is no longer a concern with the current Typescript codebase.
- The inner workings of the JVM are fairly complex, so enforcing types at compile-time actually does catch bugs before they happen.
It's a compile-to-JavaScript language, like CoffeeScript. Differentiating features:
- Strict superset of JS. All(?) JS is valid TS, making it easier to migrate to TS.
- Many of the added features are from EcmaScript 6, i.e. JavaScript Of The Future. TS lets you use those today, instead of waiting for browsers to implement.
- (Optional) type system, which some people are fans of.
- Much stronger tooling & IDE support, in part due to the typing.
Also, compiling down to human-readable and well formatted JS has always been a priority. So it's never difficult to migrate away from typescript, since the typescript can simply be replaced by the compiler's javascript output.
IIRC, this is actually one of the main reasons they're holding off on implementing async/await, since that would require the compiler to convert functions into unreadable state machines.
Another feature that's not talked about much is its support for AMD and CommonJS modules. So you can easily just add an "import moduleName = require('my/module/path');" to the top of your typescript file. And you'll get full intellisense and type-checking on the referenced module in Visual Studio. This alone has made it worth using for me.
Anders is a really good language designer. Everything this dude touches turns to gold. He was also behind C# and as far as enterprise languages go C# is a joy to work with. TypeScript is the same way. It's all really well thought out and instead of getting in the way the type system actually helps because you can leverage the dynamic aspects of JavaScript during the prototyping phase and then gradually add types as the design is fleshed out. Typed Racket I think is the other language that gives you similar capabilities but I haven't played enough with that one to have an opinion yet.
I assume you mean Delphi. Other than being now a little bit old school (not surprising for language with roots in Pascal), Delphi was and is an excellent language. Delphi was composed of a language (an ObjectPascal) along with the IDE, application framework, and Visual Component Library (VCL). These conceptual parts were all further developed in C#/Visual Studio, but they were already damn good in Delphi over 20 years ago, ahead of their time.
The language is nice, but the compiler uses its own lib.d.ts which has all sorts of definitions for browsers and even proprietary MSIE ones. This doesn't make any sense when using TypeScript in any other context (like Gjs, NodeJS, Rhino, Seed, etc.). TypeScript shouldn't assume a browser by default, or at least provide an option for compiling without lib.d.ts.
This project really is the greatest thing that could happen in computer science : a great mind trying to solve a problem in the most pragmatic yet elegant way to achieve the greatest possible benefit for developper with th minimal amount of time and work.
Less Flair version - Happy to see a well know and respected computer scientist trying to solve a problem faced by lots of developers and doing it in a simple and easy to understand way.
Agree. I wanted to put some emphasis on the fact that technologies with modest goals, but well executed, may in fact achieve more than grand masterplans.
After more than 15 years of coding I came to realize that focusing very strongly to your true needs and nothing more, is really a quality met only by the very advanced.
I always get voted down for this, but I still feel that typescript is an answer to a question that nobody is asking. (I'm also very suspect of all of the positive comments. Is HN really this pro-MS for JavaScript?) In my company, we literally have a typescript counterpart team doing the same projects. Our code is cleaner, better architected, and our team is able to consistently produce 2 to 3 times more features. In my experience, the teams that choose typescript are usually windows devs that cannot wean themselves off of visual studio due to their dependence upon auto completion and IDE tools. I'm not hating, I just don't understand why any js dev would add code to their code.
> In my experience, the teams that choose typescript are usually windows devs that cannot wean themselves off of visual studio due to their dependence upon auto completion and IDE tools.
Well, since VS does auto-completion with JavaScript too, so maybe you're not understanding the whole situation. Some people like TypeScript for its ability to facilitate creation of large projects via addition types, classes, and namespaces, while retaining much of the basic JavaScript syntax.
Yep, voted down for no reason. I have actual real world experience with teams trying to use this technology. Is there an actual MS army trying to keep these threads pro MS?
By the way, is playground using v1.0?
[1] http://www.typescriptlang.org/Playground/
[2] http://coffeescript.org/ (Try CoffeeScript tab)
[3] http://try.dartlang.org/
[4] http://bilalhusain.com/rust-lexer/syntax.html