Have you used TypeScript? Try it out for a month or two on a real project.

It's the best thing that has happened to web development in recent years - it improves Javascript in a completely compatible and future proof way.

The most amazing thing is that Microsoft created it. It's the polar opposite of Old Microsoft - standards are being followed (not subverted), it's simple pragmatic and has no lock-in.

I love Typescript, I do all my javascript coding via it.

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.

typings[1] does exactly that as long as people start publishing their definitions (which is kind of the point of them). Relying on un-versioned ambient declarations is what breaks things, not having dependencies.

[1] https://github.com/typings/typings/blob/master/docs/registry...

thanks for the link. I'm partially aware of typings, but too into my own implementation right now to consider switching fro definitely typed. I'll give it a try and pray it actually can let me ship an OSS project!

For a quick and small example to see it in action:

npm init && typings init

npm install debug ms --save

typings install debug ms --save

debug is dependent on ms, so in node_modules you have:

|-ms

|-debug

| |-ms

typings/main/definitions will have

|-debug

| |-index.d.ts

|-ms

| |-index.d.ts

It makes up for this file structure by declaring modules named in a file-like structure so the entire dependency tree is self contained in one file, while only exposing it's own typings through the final export declarations "debug" and "ms". No stepping on toes. Best to see for yourself, it would take a bit to write down.

As a point of info, it only works when people start adding versioning to the typings registry itself. debug and ms are both versioned in the registry, which is the only reason their dependencies are correctly managed. DefinitelyTyped ambient declarations will still break things. Until those are gone and everything is versioned, you'll still need some hacking depending on your dependencies. That being said, I've seen the issues start to fade rather quickly given the short time period I've been using it.

TypeScript has support for namespaces, and `import` gives you a lot of flexibility. If these aren't sufficient to handle the problem you describe, can you explain how? Can you post a link to the issue you are watching so we can see a better description of the problem you're running into?

Here's a scenario: You write a library that uses Promises, and use bluebird.d.ts for that definition.

For someone to use your library, they will have to download bluebird.d.ts manually and include it. if you (the lib dev) include it yourself, then any other definition of Promise (including if the user has their own bluebird.d.ts definition included) will cause typing collisions.

As someone mentioned, the Typings project might solve this, but there isn't very good communication on this project and the problems it's supposed to solve.

Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it future proof. Also how is it compatible with anything, JavaScript is compatible with TypeScript, since TypeScript is superset of JS, but it is not compatible the other way around.

Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy.

TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. That's it.

Want to switch away from TS? Compile all your .ts files, save the .js, check that into your repo and continue from there.

(As other commenters sort-of pointed out: you will need to keep Babel in your pipeline.)

Interesting, I never 'considered' that. It's basically a thin typechecker linguistic layer. A variant of gradual typing.

Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?

You mean in TS?

Yes. ∀ x: I can do x in JS → I can do x in TS

But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false.

This implies TS = JS. And that's the point: semantically, TS = JS.

OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript that gathers the same docs without repeating the type info already in the code?

http://typedoc.io/ might be what you're looking for.

Thanks. Also, some informative samples of what TypeScript itself looks like.

https://github.com/sebastian-lenz/typedoc/blob/master/src/li...

Sort of. I don't recall the details from the top of my head and can't easily seem to find details, but I think we're seeing some divergence between Typescript's classes and es6 classes, though I think it's mostly syntactic.

Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were semantic reasons not to.

The Typescript authors are involved in the ECMAScript process, so I'm pretty sure that there won't be any surprising huge rifts at least.

I don't know why you're being downvoted. You're exactly right - there are a few tiny divergences between ES6 and TypeScript. In particular, try compiling some classes with Babel's strict compatibility mode and compare the output to TypeScript's output. There are several small semantic differences.

Also, there a few constructs in TypeScript that generate JavaScript code, like enum and module.

THAT SAID, TypeScript is basically ES6 + type annotations, and can certainly be used as such.

I'm hoping that Typescript will be willing to break backward compatibility when necessary to maintain its core advantage of being an assisted version of the standard rather than just another non-standard language. If Typescript gets out ahead of the ES standard and adopts a feature that is presumably coming in ES, but ES changes course and doesn't follow, TS will no longer be annotated, standard ES.

In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.

It is, you just need to define a d.ts file. I was able to use plain jquery with typescript. Check out DefinitelyTyped. It's a project that makes it easy.

I have not used TypeScript personally, just read and try some demo of it.

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. :-)

That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger.

You're never debugging TypeScript separately from JavaScript.

I see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know.

  declare var _: {

    each<T, U>(arr: T[], f: (elem: T) => U): U[];

    delay(f: Function, wait: number, ...arguments: any[]): number;

    template(template: string): (model: any) => string;

    bindAll(object: any, ...methodNames: string[]): void;

  };

  declare var Store: any;

If there is bug in this code, I won't know how to debug it.

I have no clue on what the JS generated by it looks like.

If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers.

If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery.

But that's me, like I said, I am too old... :-)

Just wanted to point out that that isn't the JS you know because that's just typing information -- it isn't generating any code at all, it's telling TS what the types look like for Underscore's external methods. This would be stripped out completely in the compiled code. The actual code that results in JS just below that is much more typical.

This is only a typescript definition. It only shows you the types that were already there - even before typescript was introduced. And if the JS developer was not aware that these are the accepted types for the functions then he obviously wouldn't also be able to use or debug it in pure JS.

Right, for the human there are still the English API docs to figure out the arguments and return values. These are the type annotations that TypeScript uses to let you know when you've misinterpreted the API docs, which is an incredible time saver.

I cannot vote this up enough. It really is such a different experience to developing in "plain" JavaScript.

It's so much more pleasant to write and maintain than wild, un(type)safe javascript.

Only problem is that it's not sound. That means that while it may provide static checking that your program is validly linked together, it can't fully prevent run-time type errors. And kind of like you can't be "a little pregnant", you can't be "a little typesafe".

Of course you can. Can't catch all the bugs; but can catch some of them. Which saves time and money. It doesn't actually have to be perfect to be useful and helpful.

I'm not saying it doesn't help. I'm saying you can't count on it the same way you can if you're working in a truly end-to-end statically typed environment. Even Scala's type system has its leaks, due to nulls.

Have you used ClojureScript? Try it out for a month or two on a real project.

We can do this all day ;)

You've basically ignored the OPs point entirely. Typescript is backwards compatible to JavaScript, ClojureScript most definitely is not.

Not that I'm agreeing with the post in question, but ClojureScript and TypeScript are very different beasts.

not sure what you're trying to say.

There are a lot of good JavaScript alternatives out there. This article sort of misses the point in what's good about alternatives existing - you can use any of them and expect decent interop with javascipt. A library in one is more exclusionary for all the other interests out there.

If Elm didn't also exist, I'd almost agree with you.

In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for.

This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations (e.g. as I understand it, the JS interop story with Elm isn't amazing, so you can't just use JS libraries with it).

Typescript is close enough to plain Javascript to not scare people off (I'd be willing to bet any JS developer could pick it up in a few hours) and can almost be considered in the same light as vanilla JS in such a decision, yet brings with it the advantages of a fairly decent type system.

As I've said elsewhere, it's definitely not perfect, but for developers in a position where other, more "esoteric" compile-to-JS languages aren't likely to be accepted, Typescript probably represents the best choice of bringing a decent amount of sanity and predictability to codebases.

(This isn't meant to be having a go at the parent BTW, it's just something I've been thinking about a bit and the comment jogged my memory!)

You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :)

Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs

Just for the obligatory record: Purescript is basically "Elm evolved". Everything Elm does, Purescript does better (FFI for example is such a chore in Elm). Drawback: the learning curve is basically as steep as Haskell's.

My experience with Purescript/pulp was rather negative. Basic commands were throwing errors (pulp init IIRC) so I decided to not even consider it for anything serious.

The tooling is not perfect, that's absolutely true. I have to say though that any imperfections (which are going to get fixed anyway) are well worth it if you want a pure strongly typed language for the web. There's simply nothing better (except the full-blown Haskell-to-js compilers, like GHCJS and Haste of course).

I recommend you try again and file a bug or look for help in irc if something breaks again (although I've never seen pulp init throw an error).

My memory could be off (on which command failed). I think I still have the repo on my home machine, so I could re-visit and file a bug report. At the time I kept pursuing elm instead. Reports of better FFI with JS is why I had explored PureScript.

Update: The bug is with pulp server https://github.com/bodil/pulp/issues/133

Cool, does it work for you now?

That's interesting to know! Thanks

Being backed by Microsoft is another strong point of TS for some.

I can absolutely understand that coming from coffeescript (optional parentheses resolution... yikes).

But TypeScript is basically "Javascript + types + ES6". They call it an "erasing compiler" because it's not meant to do much but remove types/make ES6 code work with ES5.

There is one gotcha in name resolution when you're working in modules (if you are in a module a.b, and a.c exists, then c will automatically refer to a.c, even if a global c exists). But that usually gets caught by the type system. Lot less issues than coffeescript IMO

With `--target=es6` I'm not sure if the TypeScript compiler does any code transformation other than removing type annotations. So the chance of a 'transpiler error' is basically zero.

There are a few small things that still require conversion. But that is because Typescript also includes capabilities from ES7 (ES2016).

For example - currently in Typescript but only planned for ES7: https://github.com/jeffmo/es-class-fields-and-static-propert...

or Support ES7: exponentiation operator https://github.com/Microsoft/TypeScript/issues/4812

Typescript seems to be more like ECMAScript.next + types rather than ES6 + types.

My favourite thing they brought over from ES7 is async/await support via ES6 generators.

FYI, those are not ES2016 features. ES2016 only includes two small feature enhancements. They might make it into 2017, but if TC39 decides they're not ready, they'll just keep not including the feature in the annual spec revision.

Well the classes are converted into functions and it adds members to the prototypes, right? Or is that ES5 only?

What you mean is indeed ES5 only. ES6 has classes so it doesn't need to convert anything.

Oh. Cool. I didn't know that.

This reads like knee-jerk reaction from someone who's never tried TypeScript.

Criticism of that statement kind of hinges on the source material being solid enough to be taken seriously.

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.

> I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users.

I agree, that wasn't a good point.

> Another it is leads to better documentation, with no qualification of how that happens

The type annotations make the source self documenting in a way that doesn't go out of sync. There's also http://typedoc.io/

Typedoc doesn't keep up with TS versions. It's not really solid enough.

I've used it but never in a serious project. Like I said when it can be compiled into WebAssembly then count me in I'll certainly give it another shot. But until then I just don't want to deal with an, albiet probably rare but possible, transpiling bug. Plus there is huge value, in my opinion, in writing an API in the same language it's going to be consumed in. It lets me dogfood more effectively and write better, real world unit tests.

This is a biased and uninformative opinion. You haven't seriously tried it, yet you're already strongly against it and your biases suggest there are obscure transpiling bugs when I've yet to see any in practice. Had you used it for any length of time you would've noticed it catches several bugs which you otherwise wouldn't discover until runtime.

You're also waiting for the "magical" WebAssembly target that makes everything better, but instead WebAssembly would end up generating much more unreadable code that runs much slower for JavaScript which already benefits from highly optimized JS VM's in Browsers. It would also much larger in size as it would require embedding its own GC and be littered with numerous type-checks in order to support a highly dynamic language like JavaScript.

> This is a biased and uninformative opinion. You haven't seriously tried it

Correct. I wasn't asked for anything deep here and I already told everyone I haven't seriously used it...

> yet you're already strongly against it and your biases suggest there are obscure transpiling bugs when I've yet to see any in practice.

I'm against any tranpiling languages. I'm glad you've never seen any in practice. I have with CoffeeScript and it cost me a huge amount of time. But like I've mentioned in multiple threads here I understand that's an extremely rare edge case at this point in time.

That's not the only reason I've cited though. Transpiling adds in an extra level of complexity. I hate complexity. In order to test changes you have to transpile the code after your changes before you can test them. Yeah you can automate it but now I'm adding extra packages to my application only so I can run slightly different code than before.

No thanks. I like simplification. As simple as I can make something the better.

> Had you used it for any length of time you would've noticed it catches several bugs which you otherwise wouldn't discover until runtime.

Maybe? Since I've been using dynamic languages without runtime checking for over a decade I'd like to imagine I'm pretty good at finding most of these issues ahead of time. Still, it gets compiled into a less strict language so it's not a silver bullet by any means.

> You're also waiting for the "magical" WebAssembly target that makes everything better, but instead WebAssembly would end up generating much more unreadable code that runs much slower for JavaScript which already benefits from highly optimized JS VM's in Browsers.

I'm curious, why would you think it would run slower. According to the V8 team its start-up is faster and it uses the same engine so the speeds so be equivalent.

Regardless the code being "unreadable" for WebAssembly doesn't matter. Do you care that bytecode is "unreadable" or MSIL? I highly doubt you do. Same thing here. WebAssembly is going to exist inside and outside of web browsers. But we're also a long way off.

> It would also much larger in size as it would require embedding its own GC and be littered with numerous type-checks in order to support a highly dynamic language like JavaScript.

Wait, why? The V8's team's announcement said they still have to implement GC, etc for the DOM but that stuff would exist in the WebAssembly implementation itself and has nothing to do with your code.

WebAssembly is still a ways off but I'm excited at the possibilities.

> I'm curious, why would you think it would run slower.

Because every browser already has an integrated highly-tuned JS VM containing several years of advanced compiler research, including JIT's with runtime type profiling, type inference, type-specialized code generation that's highly optimized around JavaScript semantics in order to get today's JavaScript performance. That doesn't exist in WebAssembly which is a low-level statically-typed language that's effectively a compact binary form of asm.js for non-GC statically typed languages like C/C++.

> WebAssembly is still a ways off but I'm excited at the possibilities.

There is for C/C++ but none for running JavaScript which is worse in every way. WebAssembly is thrown around as some intangible moniker that will magically make everything better without understanding what it is and what it would take to implement a dynamic language with it, esp. JS which already has access to the best VM's the world's best compiler engineers can create.

I don't even use TypeScript but I don't buy your arguments at all.

> when it can be compiled into WebAssembly then count me in I'll certainly give it another shot. But until then I just don't want to deal with an, albiet probably rare but possible, transpiling bug

You really think a TS->WebAssembly compiler is less likely to have bugs than a TS->JS transpiler (which essentially just strips out the type annotations)? Yeah, no.

> It lets me dogfood more effectively and write better, real world unit tests.

I have no idea how these things are relevant. Why would adding type annotations to your code affect your ability to write unit tests. What does dogfooding have to do with anything?

> You really think a TS->WebAssembly compiler is less likely to have bugs than a TS->JS transpiler (which essentially just strips out the type annotations)? Yeah, no.

Absolutely. Why wouldn't it? Converting to a very explicit byte code type environment versus a language meant to be used by humans?

> I have no idea how these things are relevant. Why would adding type annotations to your code affect your ability to write unit tests. What does dogfooding have to do with anything?

The context of the discussion was around creating libraries for everyone to consume. If you're not testing your code as if it's being run from just JavaScript then you have a blindspot.

TypeScript is not only annotations. Check out the code it generates to support those annotations.

> Why wouldn't it?

Whereas TypeScript/Babel/etc perform relatively simple source code transformations, you'd have to implement an entire JavaScript engine in WebAssembly. It would almost certainly be slower and buggier than all of the big 4 JS engines.

> Check out the code it generates to support those annotations.

Ok, let's do that:

http://www.typescriptlang.org/Playground#src=interface%20Per...

Can you describe an example of a better, real-world unit test you have in mind?

Do you also advocate against writing ES6 and using Babel?

> Can you describe an example of a better, real-world unit test you have in mind?

Considering the output is a JavaScript library people will be using it in that context more than with TypeScript and many of the others. So I don't have a specific real-world unit test example but in general your unit tests have to test the various ways people are going to use your API from the target language. So you'll need to make sure it behaves in the expected ways with valid and invalid input.

At the very least I'd expect unit tests to be written in JavaScript to hit a TypeScript library to help eliminate any weirdness that could have been missed.

> Do you also advocate against writing ES6 and using Babel?

Yup. ECMAScript 6 is great but the support is still not entirely there (especially in older browsers) and many of the transpilings are not quite equivalent. Granted Babel is pretty high quality (minus their whole decided not to ship any transpilers in the default package anymore) and I would expect it to be close enough. But after being bit by CoffeeScript so many years ago I'd rather not deal with transpilers and use the real thing when I can.

Coding in ECMAScript 5 is guaranteed compatible with ECMAScript 6, most web browsers and most versions of node. So I look at it like this: why add the extra complexity just for a few extra, nice, syntax improvements?

> Plus there is huge value, in my opinion, in writing an API in the same language it's going to be consumed in.

Making APIs so that they are only accessible from a single language should be outlawed.

Do you ever minify your JavaScript before deploying? How do you know there are no bugs in your minified?

JavaScript, IMO, forces the developer to do a lot more defensive coding. All API's have contracts. An add() method that computers two numbers shouldn't expect a JSON object. For that matter, your method's contract shouldn't return an "any" for the same reason that you shouldn't expect "any" as its input.

What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in some big enterprise wide JS projects, TypeScript answers the question "Wtf is this returning?" which lessens my debugging time because I know exactly the type of the object being returned.

Your arguments are actually kind of moot. When you write in Java, you're really just boiling it down to an intermediary language. Should you write it in IL? Why not C/C++? Why not assembly? Shoot, just handout punch cards again and let's get to working. Abstraction isn't the enemy here, it's the value of the abstraction that gives value to it. TypeScript isn't so much an abstraction as a superset but it's static typing alone is worth 1000x over.

Defensive coding in JavaScript? That's absolutely not how most libraries are implemented.

If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.

JavaScript makes this process optional, and it only needs to go wrong once to become a problem.

Personally I saw over a million dollars lost and an entire team laid off after a piece of code started working with a value that was expected to be a number but wasn't.

> If you're expecting one type and get another, you have to handle it, right?

Depends. You could debate the same philosophy wrt C and null pointers. Should you check all your arguments to see if they're null, if the documentation/specification says they should never be null, or accept undefined behaviour and segfault?

In practice, most code assumes everything is checked, sanitized and used correctly at the outer most API boundary.

I disagree. The last letter of the API stands for "interface", which by the definition (a point where two systems, subjects, organizations, etc. meet and interact.) means you don't always have the ability to put a "same language" constraint on. By presuming the API will be consumed by something you have no control over makes you think about all the implications and types act as a guard of sorts.

At work our entire front end is TypeScript, and thanks to source mapping I've never had to look at JavaScript even when debugging problems. Typescript simply adds type annotations so you can get error underlining when you misuse a variable, and even more importantly (productivity wise) you get auto-complete members as you type.

Don't want types? Fine don't use them, and you have JavaScript code again.

What an odd argument. If you were writing a DLL for Windows would you expect the binary executable that's using it to be written in the same language?

Do you have an example of how writing something without types is supposed to help you capture edge cases? What are the idiosyncrasies of Javascript that can easily be caught in Javascript but NOT in Typescript?

WebAssembly adds massive layers of complexity that Typescript doesn't. You argue going from Typescript to Javascript is bad because, but Typescript to WebAssembly is good. One of this is vastly more complex and complicated, and it isn't TS to JS.

I do quite a bit of library development in TypeScript and one of the biggest wins is with new developers doing their first non-trivial bug fix or refactoring. The compiler has saved us from introducing all sorts of edge-case bugs because it catches downstream impacts that developers who are not intimately familiar with all of the code can introduce. A nice bonus feature is single line jsDoc comments replacing giant blocks of descriptive text.

Sounds like you've been tainted by your bad experience with CoffeeScript (which is very understandable).

Typescript is a whole different beast and I think the article makes great points for libraries. The more types the better.

APIs written in C seem to do just fine.

TypeScript is ES6 with types, so it is not a different language at all.

Not true at all. TypeSript has ES6 modules and its own module syntax. I don't know if it has improved recently, but using ES6 modules in our TS was nearly impossible if using type definitions using the old module syntax.

Couldn't agree with this more. Specifically, the lost hours due to CoffeeScript.

Typescript really isn't comparable to coffeescript

CoffeeScript has the worst tooling ever. QBasic in the 90s had better tooling than CoffeeScript: an integrated editor, debugger, compiler, type validation... let's give it all up to code in vomitscript.

Have you ever tried Atom? Its interface is written in HTML5 + CoffeeScript, and it targets CoffeeScript as the primary language. Tell the GitHub guys about tooling...

But besides, judging a language based on available tooling is akin to judging a CPU based on the computer casing looks.

For a real programmer, GNU Nano with appropriate highlighting should be enough. If a language calls itself "high-level" but makes the coding process hard without tooling, it deserves no attention at all.

A real programmer makes mistakes, and a real programmer automates tasks. That's what programmers are for.

Javascript IS pretty damn good. My IDE does a pretty good job at analyzing the structure of scripts.

So, I guess I have not yet felt the pain that "requires" a language upgrade. Unlike Java, which has really gotten to chafe me.

But then again, I started work back in 1985 using a scripted language (dBASE), with its own version of "eval", to make cute little UIs and reports that tied into the "real computer" / software (even if data swapping was swapping nightly batches of ISAM tuples, rather than REST calls). I also enjoyed using Perl in the 90s / early 2000s.

Then as now, the Serious People want you to wallow with them in the bondage and discipline of a Real Language, so you can type until your fingers bleed :-)

That said, I do write a lot of "JSDoc" in my code, and I resent the people who refuse to write Javadoc in their Java, because of course the types all make it crystal clear - NOT!

If it can't be compiled to JavaScript reliably then how do you expect it to be compiled to WebAssembly reliably?

Doesn't really need to be readable when compiled into WebAssembly though that I'd a goal. In that scenario it should work like any language in that you can debug in its native form.

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.

I still don't really see the argument. It can already be debugged in its native form. I'm not sure how making the final product less readable helps with that.

WebAssembly is primarily useful from a performance standpoint.

RELIABLE, not READABLE.

This was my reaction upon reading the title of the post, having not used TypeScript. Mostly based on my experience and frustration with CoffeScript, mainly frustration at its existence.

But if TypeScript is an abstraction of Javascript that adds type security, then I'm pretty much all for it, even having been burned pretty often by unnecessary abstraction. I would say that the lion's share of my own javascript bugs spring from type uncertainty.

> "API to be consumed in language X then you need to write the API itself in language X"

I have to agree with the OP's point if your writing a library you should write it in the base language (common denominator). I work on JVM stuff and nothing is more annoying then dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java. Plain Java on the other hand works fine in Scala,Clojure, and Groovy.

The above JVM languages compile to byte code (which I guess would be analogous to WebAssembly).

Thus I'm not sure if transpiling is as bad since Xtend (which is more analogous since its a Java transpiler) is very interoperable AND does not compile to bytecode directly.

So WebAssembly might end up being just as bad as the plethora of JVM languages that are sort of interoperable.

> nothing is more annoying than dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java

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.

Sorry for the late reply but yes you can write some Groovy that will not work on Java (I'm trying to find when and where it happened to me... that could have changed).

The issue is that there are things you can do in JVM bytecode that you just can't do in Java and as the JVM develops along with these languages I imagine further interoperability.

You are right about the languages not making promises but there are plenty of library writers who disregard this. A fine example would be Akka and Finagle. Those libraries could have been written in Java thus minimizing dependencies and maybe even overall code size since they have to have a wrapper for Java anyway (typesafe did choose Java for typesafe config). But then again maybe Scala/Clojure buys enough that the wrappers are trivial. I'm just not sure how trivial interoperable wrappers for WebAssembly will be as I imagine WebAssembly will be a superset of what Javascript can do (or maybe not?).

Specifically regarding this discussion of typescript/javascript what are some edge cases and language idiosyncrasies problems you'd run into writing libraries in typescript?