Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

181–190 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#181
post #63

Earlier quoted context omitted.

This reads like knee-jerk reaction from someone who's never tried TypeScript.

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, re…

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?

Re: JavaScript libraries should be written in TypeScript

#182
I think this is a bit of a hasty claim with a bit of truth to it, sort of like if someone said "All JavaScript libraries should be authored in CoffeeScript" in 2010. A cambrian explosion occurred, then the community eventually coalesced. Coffeescript itself isn't (and wasn't) perfect, but it pioneered an approach that led to a whole lot of progress in JS.

A better framing of this is: "Type systems are good. The JS community should sort this out in the next couple of years and will probably a standard approach, but it's worth diving into the assorted tools that exist -- TypeScript, Flow, and any others -- to understand the ecosystem and find pain points."

Re: JavaScript libraries should be written in TypeScript

#183

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…

JavaScript, IMO, forces the developer to do a lot more defensive coding. All API's have contracts. An add() method that computers two numbers shouldn't expect a JSON object. For that matter, your method's contract shouldn't return an "any" for the same reason that you shouldn't expect "any" as its input.

What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in some big enterprise wide JS projects, TypeScript answers the question "Wtf is this returning?" which lessens my debugging time because I know exactly the type of the object being returned.

Your arguments are actually kind of moot. When you write in Java, you're really just boiling it down to an intermediary language. Should you write it in IL? Why not C/C++? Why not assembly? Shoot, just handout punch cards again and let's get to working. Abstraction isn't the enemy here, it's the value of the abstraction that gives value to it. TypeScript isn't so much an abstraction as a superset but it's static typing alone is worth 1000x over.

Re: JavaScript libraries should be written in TypeScript

#184
Nope, in fact you should not use JSDoc, and you should not follow Google's JavaScript standard, despite the fact they authored V8. Instead, you should follow a self-proclaimed "standard", that adopts unsafe practices such as not using semicolons, something that Google itself factually demonstrated as being unsafe. But even that doesn't matter.

Let's let humans do the job that computers can do faster and more reliably, like validating the types of variables and function signatures. Let's do everything by hand. Let's give control of our programming future to people that don't care at all about programming.

Re: JavaScript libraries should be written in TypeScript

#185
In my limited experience working with JavaScript, I've found the lack of the following to cause more problems when writing modular, reusable code than the lack of type annotations:

* a single, definitive method for creating namespaces without using a framework or library

* a single, definitive method for defining classes and using inheritance without using a framework or library

* a single, definitive method of allowing async functions to modify the state of an object without having to declare that object in the global scope, without using a framework or library

If these problems are already solved, please let me know!

Re: JavaScript libraries should be written in TypeScript

#186
post #57

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…

Couldn't agree with this more. Specifically, the lost hours due to CoffeeScript.

CoffeeScript has the worst tooling ever. QBasic in the 90s had better tooling than CoffeeScript: an integrated editor, debugger, compiler, type validation... let's give it all up to code in vomitscript.

Re: JavaScript libraries should be written in TypeScript

#187
post #142

Earlier quoted context omitted.

Is TypeScript really future proof? I mean unless types, exactly implemented as they are in TypeScript, will become part of the spec, we can't really call it future proof. Also how is it compatible with anything, JavaScript is compatible with TypeScript, since TypeScript is superset of JS, but it is not compatible the other way around.

Yes, it is. Compiling TS just removes type annotations; the compilation output (.js) is as readable as your original .ts. It has the same structure, same indentation, same variable names, same whitespace, same comments, same everything. This also makes debugging the code in the browser very easy. TS does not add any semantic features, it only adds type annotations. Which it checks at compile time, and then removes. T…

Thanks for the concrete description. Can I still use dynamic constructs such as string subscripts to associative arrays and code generation via eval()?

Re: JavaScript libraries should be written in TypeScript

#188

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…

JavaScript, IMO, forces the developer to do a lot more defensive coding. All API's have contracts. An add() method that computers two numbers shouldn't expect a JSON object. For that matter, your method's contract shouldn't return an "any" for the same reason that you shouldn't expect "any" as its input. What TypeScript does is remove the ambiguity of API development for front-end work. Considering I've worked in som…

Defensive coding in JavaScript? That's absolutely not how most libraries are implemented.

Re: JavaScript libraries should be written in TypeScript

#189
post #185

In my limited experience working with JavaScript, I've found the lack of the following to cause more problems when writing modular, reusable code than the lack of type annotations: * a single, definitive method for creating namespaces without using a framework or library * a single, definitive method for defining classes and using inheritance without using a framework or library * a single, definitive method of allow…

The one about classes is solved by not using classes. Prototypal inheritance works well (and besides, most implementations of 'class-like' behaviour are using prototypes underneath anyway)

I'm playing a bit of a devil's advocate here ;)

Re: JavaScript libraries should be written in TypeScript

#190
post #93

Earlier quoted context omitted.

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.

People told above, think of TS as a strong linter over normal ES6. Static typecheck is often very nice.
Post reply on HN