5 ms·
> type WorkerCallback = (err: any, result?: any) => any; export function runWorker(path: string, cb: WorkerCallback, workerData: object | null = null) { const
by crabasa 8y ago
> type WorkerCallback = (err: any, result?: any) => any;
export function runWorker(path: string, cb: WorkerCallback, workerData: object | null = null) {
const worker = new Worker(path, { workerData });
worker.on('message', cb.bind(null, null));
worker.on('error', cb);
worker.on('exit', (exitCode) => {
if (exitCode === 0) {
return null;
}
return cb(new Error(`Worker has stopped with code ${exitCode}`));
});
return worker;
}
For an article titled "A Guide to Threads in Node.js", I really wish the first example of writing a thread wasn't in TypeScript.
- danenania 8y agoWhy? Just think of it as inline documentation. It in no way changes the semantics of the javascript and efficiently communicates how the API works.
- kbenson 8y agoProbably because it adds extra cognitive overhead for anyone that doesn't know TypeScript as they interpret and translate TypeScript into JavaScript in their head? Or perhaps because it's slightly misleading?
- GordonS 8y agoAs a staunch supporter of static typing, I agree with you - the target audience is very obviously those from a JavaScript background, so it makes sense for the code snippets to be in JavaScript, not Typescript. If the author wanted to add additional info for context, IMO in this instance they should have used a JSDoc comment.
- danenania 8y agoTypeScript is a more expressive, concise, intuitive, and popular version of jsdoc that can be statically enforced by a compiler, provide autocompletion, and will never get out of date. I just don’t see the downside of using TS in place of jsdoc—the syntax is even pretty comparable.
- hombre_fatal 8y agoEh, I'd see your point if it was written with ReasonML, but these comments seem ridiculous to me. For example, did you really grapple with the example code? Or are you just assuming everyone is too stupid to understand some inline, ignorable annotations in what remains to be Javascript?
- crabasa 8y agoWhen writing a developer guide, especially to something as fundamental as "threads in Node.js", it pays to: 1) Make as few assumptions as possible regarding what the reader knows or has experience with 2) Make code samples as complete and "copy-and-pastable" as possible. You're assuming that all developers reading this guide will effortlessly translate that TS code to JS. Using TS creates a possible barrier to understanding, which I'm sure isn't the intent of someone publishing such a guide. Better to simply write some comments or augment the prose in the guide.
- danenania 8y agoOk, fair enough. But for anyone who has some familiarity with type systems, the lack of type signatures (or needing to mentally parse them in some other non-standard format) also acts as a barrier to understanding. Perhaps either a side-by-side view or a tab switcher would be ideal.
- crabasa 8y agoExcept this is a guide for Node.js (JavaScript). The one assumption the author can make is that the reader knows and is comfortable with JavsScript.
- danenania 8y agoYeah I'm not trying to disagree with you there, just pointing out that TS types are an efficient way to add important context that many (like me) will appreciate, and as a popular well-defined standard I think they are superior to some other kind of ad hoc spec that is included in comments or prose or whatever. I think it would be great if more JS code examples started including type signatures, since they are useful whether or not you program in TS. But yes, there should probably also be a JS-only example in that case and/or a way to toggle them off.
- hackerbob 8y agoWe've been throw this game before: CoffeeScript Until TS becomes an official standard supported by ECMAScript out of the box. Were just going along with what feels or looks good and the javascript community has proven that can change from year to year.