JavaScript libraries should be written in TypeScript (staltz.com)

So rather unlikely?

Haskell has a JavaScript compiler as well, by the way (GHCJS).

And actually even for me.

I do know how to install and use all those. I just don't want to take the afternoon to do so.

Why ?

- Only one project out of 5 are big enough to justify it. - The stack will change in 6 months; - I will need to train anybody who gets on board, and document it, and maintain it. - All this tooling integration is terrible in JS, because they are an agglomerate of stuff we are stacking after the fact to compensate JS bad initial design. The same stack for any other language is 10 times easier to setup and maintain (the stdlib is here for you in Python, you don't need to load a deendancy to generate a uuid), or it's just here out of the box (type hints ? embded in Php) or event completly uneeded (nobody use transpilers in Ruby hence no source maps, etc).

So yes, it's annoying.

[0] https://github.com/Microsoft/TypeScriptSamples/blob/master/t...

http://stackoverflow.com/questions/29738381/how-to-publish-a...

If you're programming in a dynamic language, there are things that you do that would not easily fly in a static language. Things like tests for truthiness. On first blush, from a static background, something like "var p = x && x.y && x.y.z || w;" look terrible, but they're pretty standard ways of cascading through different options without causing null pointer exceptions in a language like JS. When you start introducing type constraints, you are committing yourself to getting rid of all those dynamic shortcuts.

Yes, shortcuts can sometimes get you in trouble, but they can sometimes get you down the road so fast that trouble doesn't have a chance to find you. That's sort of the tradeoff you make: we can be super-fast 90% of the time, at the cost of having difficult to debug problems occasionally.

On the other hand, when you have a requirement to have type constraints in your code, any other code you interact with has to also have type constraints. But in JS, that's not a lot of projects. There is the DefinitelyTyped repository, but it's incomplete and of unknown quality.

I had thought the same thing as you, "beach-heads of type safety". The problem is that dynamic code tends to infect static code. I eventually gave up on TypeScript after not being able to wrangle the combination of a few code generation and graphics tools. My project was already reasonably OO organized and not dynamic, but there was just no easy way to handle the boundaries of the APIs. To deal with it, I had to... start using the dynamic features of JS, giving up on the type safety.

For example, you can't do function overloading in JavaScript, because you don't have any information about types on which to differentiate functions. Well, it turns out that means you also can't do function overloading in TypeScript. The only reason Math.min works in TypeScript is because JS only has one number type, and it is 64-bit IEEE floats.

But some libraries in JS, and especially in DOM, do overload functions. You test the type of parameters at runtime and decide what each positioned parameter actually means. So if you want to use such a library in TypeScript, you need to have a type definition that uses Any for each of the parameters, meaning you've lost type safety and you're back to testing the type of things.

So it just leaves you in this limbo zone where you don't get to use the features of the native language that make up for it being so crappy, nor do you ever get to use the features of the transpiled language that promises to keep your code easy to modify over time. So that's what I mean about "worst of both worlds".

It's like trying to introduce rules on a group of anarchists: you're more likely to get burned at the stake than to make more productive anarchists. Or try letting a bunch of corporate lifers work without a direct boss: you're more likely to end up with a lot more donuts eaten than code written. What ES6 gets right is that it doesn't try to bolt on a type system into an ecosystem that just won't tolerate it. It has features for making it easier, less error-prone, more ergonomic to do things that people are already doing in ES5. In particular, people are already trying to make classical classes with inheritance out of the prototype-based class functions in ES5, so ES6 introduced a new syntax for just that use case that gets rid of all the repetitive and goofy "Object.create" and "MyClass.prototype.myMethod = function(){ blah blah blah blah }" stuff.

I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users. Another it is leads to better documentation, with no qualification of how that happens. It might make your intent more explicit to a reader of the source code, but that doesn't magically translate into documentation for an API user.

I personally find nothing good about trying to coercing a language into something it isn't and then transpilling it back and that article has no strong argument to make me feel any different.

MSIL and Java bytecode are not that readable but I mentally lump WebAssembly in the same group (though I know it isn't quite that). I feel like the end goal will be closer aligned to byte code than JavaScript.

We can do this all day ;)

But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent.

For after look at the v8's C++ code, I can't imagine anyone would write that with C.

But when a new language's ego system is not mature enough, the development work flow can be a nightmare. I remember trying to use GWT to compile Java into JS. The demo works and looks cool. But more often or not, I end up debug "The JAVA code" AND "The machine generated Javascript" AND "how that JS interact with different browsers" for something that is extremely trivial to do with one line of JS/JQuery code.

* Writing code is easy. * Debugging code is harder. * Make sure that code works on all the browsers are much harder.

* Debugging system with multiple languages (JS, TS, React, Angular, polymer, etc) + machine generated code is not easy.

* Integrated them all together to fixed all issues and make sure the final program will work on all browsers are > N^2, N^3, N^4 times harder?

I am old enough to admit, that is not a job for me. :-)

However, Though I wish it were, Typescript is NOT currently suitable for defining modules for external consumption. The problem comes down to no effective means of publishing the typings of your project and your project's dependencies. For example, if your project uses Promises, you might choose to include a definition of those promises, or (worse) reference a Promise typing you found on DefinitelyTyped. This will work fine for you, the publisher. But any consumer of your project will be rudely greeted with typing collisions: Things like "The interface 'Promise' already exists in es6.d.ts"

There needs to be a solution to this module publishing problem before people can seriously publish modules (using NPM) using Typescript. Unfortunately, I have been tracking this issue and there is no timeline for resolving it, mostly due to too many different module systems, and handling module publishing being outside the design-scope of Typescript.

I don't think the backers of Scala and Clojure make the claim that libraries written in their language will work seamlessly in Java, only that libraries written in Java will work in their language. The marketers of Apache Groovy, otoh, do claim code written in it will work in Java but from what you say that claim is false.

With Typescript, you can't do this, because the code has to pass through the Typescript compiler first, which doesn't support (most of) these features (e.g. it does support decorators IIRC) so will throw an error when it finds an unfamiliar language construct, and it doesn't have a plugin architecture like Babel, so you can't add them in that way.

One example is the spread/rest syntax which is sometimes used in React projects isn't fully supported in TS: https://github.com/Microsoft/TypeScript/issues/2103.

I should point out you can use Babel and Typescript, so the Babel processes the output from tsc (needed for using e.g. async/await at present, as tsc can't compile these down to ES5), but tsc has to run first to make the code into valid JS (on this note, I was surprised how easy it was to remove TS from a project - Babel will ignore most of the TS specific stuff such as interface and type declarations, as it already strips them out for Flow compatibility and the syntax is largely the same)

The most obvious Babel plugins are JSX and Flow. If your library is using TypeScript then it cannot go through the same build process* as any downstream project that is using any Babel plugin. That means you need to publish your library as ES5 and the client loses most the advantages of your library being in TypeScript in the first place.

Also, Babel appears to be doing a slightly better job of keeping up with the draft ES standards, so if you want to use cutting-edge JS features (like async/await) that are on the standards track, you may need to wait a bit longer for TS adoption to get there.

I also think it's unlikely TypeScript is going to win out in the long run, so if you commit to TS now you're probably going to be rewriting in a few years. It's better to stick to standard JS where possible. The history of ES4 strongly suggests that TS is never going to become an ECMA standard.

* You can, at least in theory, do a two-stage transpile that goes through both Babel and TS, but IMO, nothing good is likely to come from such a setup.

The biggest problems in any modern, large-scale JavaScript project are the build process and dependency management. If you are publishing a TypeScript library then it can be consumed either natively as TypeScript, or as ES5.

If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler.

That doesn't negate the internal benefits to your library, but Flow is another option that is a better fit if you are mostly interested in going with the prevailing wind. After all, that was the author's central argument as to why you should choose TS over Flow, and IMO it is quite wrong.