Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

91–100 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#92
post #70

Absolutely not. This is the opposite of what you should do in my opinion. If you're writing an API to be consumed in language X then you need to write the API itself in language X. This will help you capture and handle edge cases, language idiosyncrasies and other similar issues the way you want. Using a different language that gets transpiled into a target language also increases your surface area for bugs because n…

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.

Re: JavaScript libraries should be written in TypeScript

#93

I still run into libraries written in Coffeescript, and hate it when I do, because I don't use it and have a hard time following it. Javascript libraries should be written in Javascript. Worship the one true God!

Typescript isn't all that differentiable from ES6. While I'm generally on the vanilla train, feeling fairly compelled to use it when messing around with angular2 has made me very much appreciate it. Change your .js filename to .ts and it will still run, which makes the typing just an added bonus.

Which leaves me wondering why I'd use Typescript over sticking with ES6, especially with tools like Babel making many future features available right now and libraries like React actively making use of them.

Re: JavaScript libraries should be written in TypeScript

#96

Earlier quoted context omitted.

It's not about reading, it's about the tooling you need to set it up. JS initial strengh was ease of dev for beginers. Throw in a transpiler, a dependancy manager, a package manager, a bundler with FS watching, and source maps and what you got is wall for the very same type of dev that were producing all those fantastic jQuery plugins 10 years ago. And actually even for me. I do know how to install and use all those.…

> It's not about reading, it's about the tooling you need to set it up. npm install typescript -g This is the only addition on top of vanilla js, which is what you should be comparing with instead of the massive crap of build-tool-of-the-month. All said and done, if you're using those build tools in typescript, you'd be using them for javascript as well.

Wait, you mean I can start up a brand new Windows machine and type "npm install tsc -g" and stuff magically happens?

Re: JavaScript libraries should be written in TypeScript

#97

People make basic mistakes routinely with types. Even with very sophisticated type systems, like the one used in Haskel. There's evidence that in rare cases where people could have been "helped" by a type system, the cost of finding and fixing such a bug is far lower than using a type system to enforce correctness in the first place. You will write automated tests whether you're using a type system or not.

I am hesitant to start the whole typed vs untyped debate here, but this is exactly what your comment is highlighting. Where does all this evidence come from? I have recently started using Scala and while initially the learning curve was quite high, I have been so happy to have such a comprehensive type system.

Re: JavaScript libraries should be written in TypeScript

#98
post #67

Absolutely not. This is the opposite of what you should do in my opinion. If you're writing an API to be consumed in language X then you need to write the API itself in language X. This will help you capture and handle edge cases, language idiosyncrasies and other similar issues the way you want. Using a different language that gets transpiled into a target language also increases your surface area for bugs because n…

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…

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.

Re: JavaScript libraries should be written in TypeScript

#99
post #72

I'm not certain I agree. I agree with better type systems, but does anyone remember ECMAScript 4? Which Microsoft vetoed after Macromedia had gone ahead and adopted it as ActionScript 3 (coincidentally around the time they were trying to get everyone to adopt Silverlight). Well that's basically what TypeScript is (with slightly more advanced type support). It's a nonstandard dialect of JavaScript. Something that ever…

What does one miss out from Babel, given that TS is a superset of ES6?

I guess the point is that with Babel you can enable so called "stage 0" language features, which aren't in the spec yet but someone has created a Babel plugin for (e.g. decorators).

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)

Post reply on HN