JavaScript libraries should be written in TypeScript
91–100 of 285 posts
Re: JavaScript libraries should be written in TypeScript
#92Absolutely 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?
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
#93I 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.
Re: JavaScript libraries should be written in TypeScript
#94I rather hope that is not the case.
Re: JavaScript libraries should be written in TypeScript
#95Re: JavaScript libraries should be written in TypeScript
#96Earlier 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.
Re: JavaScript libraries should be written in TypeScript
#97People 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.
Re: JavaScript libraries should be written in TypeScript
#98Absolutely 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…
Re: JavaScript libraries should be written in TypeScript
#99I'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?
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)