If you're writing C# then Typescript feels more natural, especially in Visual Studio it removes much of the painful context switching between a typed intellisense driven development and a javascript free for all.
i) Wrapper libraries - Sure you can download them from definitelytyped but in practice I quickly found all sort of incompatibilities and things not working when used on real versions of the wrapped libraries. I had to edit them based on suggestions from forums. They are unversioned community efforts - poor versioning and no package manager is just a nightmare given the dozens of libraries we have to use for modern JS.
ii) Tooling - I thought this was the benefit and tried using it from WebStorm which claimed Typescript support. I found no meaningful intellisense only that it shelled out to the TS compiler in the background with some flakey syntax highlighting. The worst issue was that the compiler could regularly produce totally opaque error messages that were poorly located to the code issue and probably in the wrapper somewhere.
iii) Arbitrary apis - this is what I thought I wouldn't face but it was. Just a single line of code trying to the most basic task of creating an express server took hours of googling for the magic incantation. Most advice referred to the wrong version. It appears there are javascript patterns that typescript wrappers struggle to represent so the authors have to invent new ways of offering an interface. Wrappers don't come with documentation... even if they did, you now have to read both the original and the wrapper documentation. Not cool.
I hope some of this is now fixed but to have unreliable wrappers, no versioning and bad error messages means I am not hurrying back anytime soon.
There are some pain points to be sure (modules, generics that don't quite work), but:
- Emits known good javascript patterns, preventing javascript's typical '50 ways of doing something'.
- Interacts cleanly and nicely with the existing javascript ecosystem.
- The emitted javascript runs on old browsers, and is only marginally bigger than the source code, smaller sometimes, if you use interfaces
- Clean module system (a little irritating to use perhaps, but still) supporting AMD and CommonJS (this is absolutely the future for JS dependencies).
- Open source, installable compiler using npm.
What's the alternative?
- native JS <-- Not a bad choice, needs discipline to maintain code quality
- coffee script <-- Interacts poorly with existing js ecosystem
- dart <-- Doesn't run on old browsers, poor interop
- emscripten <-- Massive output, poor interop
Why do you think that ? Coffeescript is basically javascript without the bad parts.
Embedded JavaScript
Hopefully, you'll never need to use it, but if you ever need to intersperse
snippets of JavaScript within your CoffeeScript, you can use backticks to pass
it straight through.
Not so?
Why are there so many SO questions about 'how do I use coffee script with XXX'?
(where XXX is some existing javascript library, eg. jquery)
Coffeescript is a 100% compatible with javascript , the fact that you can embed javascript in coffeescript is a feature of the language,not a problem.
> I saw this from the homepage:
So what ?
> Why are there so many SO questions about 'how do I use coffee script with XXX'?
How does it mean coffeescript has compatibility issues with javascript ? You are just bashing coffeescript without any real argument against it. There are arguments against coffeescript , compatibily with javascript is not one of them. You dont know coffeescript. If you knew CS you would not have these bogus arguments against it.
Coffeescript fixes Javascript bad parts , Typescript doesnt,it just add a few keywords and compile time type checking to the language, which is unecessary.
Typescript on the other has compatibility issues with javascript libraries since one needs ambient declarations to use 3rd party libraries, some extra work not needed with Coffeescript.