JavaScript libraries should be written in TypeScript
101–110 of 285 posts
Re: JavaScript libraries should be written in TypeScript
#102I'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?
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.
Re: JavaScript libraries should be written in TypeScript
#103Re: JavaScript libraries should be written in TypeScript
#104I struggle with the issue of type safety because while I really enjoy using Haskell on side projects, I find Ruby a giant mound of non-type safe glue that collects my ideas together into code. I use Ruby a lot.
I imagine that many JavaScript programmers like the lightness and malleability of their language also.
Re: JavaScript libraries should be written in TypeScript
#105I'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…
I haven't tried Babel, though. It easily could be a better path forward. Does it have some equivalent of the typescript type descriptor files?
Re: JavaScript libraries should be written in TypeScript
#106Re: JavaScript libraries should be written in TypeScript
#107I'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…
Types often end up a part of the documentation, and internal typing is often needed in libraries to keep track of model state, so having it at the foundational level in the library itself adds tremendous benefit.
Re: JavaScript libraries should be written in TypeScript
#108Absolutely 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…
Couldn't agree with this more. Specifically, the lost hours due to CoffeeScript.
Re: JavaScript libraries should be written in TypeScript
#109Earlier quoted context omitted.
> 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?
I understand what you're saying, but it's completely contextual. The title of this article is "All javascript libraries...". Maybe it's just that I'm not a front-end-only developer. I have no clue about the development process for exclusively front end libraries, but I don't see many people develop them without node/npm. Hell, JQuery has a package.json, and:
"In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later"
Re: JavaScript libraries should be written in TypeScript
#110Earlier quoted context omitted.
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.
WebAssembly is primarily useful from a performance standpoint.