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.
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.
> 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?
