Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

Post reply on HN
Print view View original

251–260 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#251

Post by JoeAltmaier »

acjohnson55 wrote: post #249
echelon wrote: post #155

Earlier quoted context omitted.

It's so much more pleasant to write and maintain than wild, un(type)safe javascript.

Only problem is that it's not sound. That means that while it may provide static checking that your program is validly linked together, it can't fully prevent run-time type errors. And kind of like you can't be "a little pregnant", you can't be "a little typesafe".

Of course you can. Can't catch all the bugs; but can catch some of them. Which saves time and money. It doesn't actually have to be perfect to be useful and helpful.

Re: JavaScript libraries should be written in TypeScript

#252

Post by AgentME »

bsr203 wrote: post #138

I love static typing, but prefer flowtype for js project. I used Typescript during the initial days while developing Angular 1 apps. Things might have improved now, but transpiling to JS was slow then and had non standard module system. It may make sense to use it for Angular apps as Angular 2 and related projects are written in it. but, for me, it always felt as another language farther away from JS. Once started us…

+1 for Flow. I've loved the fact that it's not a build step, so it was really easy to add Flow into my Babel+Browserify projects. I looked at Typescript before, but I didn't want to leave Browserify, and Typescript+Browserify did not look like it was a well-supported path.

Also its strictness about nulls has saved me so many times and has forced me to make better APIs that carefully consider or prohibit them, instead of treating null as a boogeyman that I don't think about until it inevitably bites me.

Re: JavaScript libraries should be written in TypeScript

#253

Post by SiVal »

Eridrus wrote: post #163
Hurtak wrote: 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.

Sort of. I don't recall the details from the top of my head and can't easily seem to find details, but I think we're seeing some divergence between Typescript's classes and es6 classes, though I think it's mostly syntactic. Your code will keep working, but it may diverge a bit from standard JS; however everything will keep working, and I'm sure the expectation would be to move over the es6's syntax unless there were…

I'm hoping that Typescript will be willing to break backward compatibility when necessary to maintain its core advantage of being an assisted version of the standard rather than just another non-standard language. If Typescript gets out ahead of the ES standard and adopts a feature that is presumably coming in ES, but ES changes course and doesn't follow, TS will no longer be annotated, standard ES.

In this case, I'm hoping TS will just make the breaking change and go back to being pure, standard ES plus optional type annotations. Developers who use it would just accept that from time to time, this could happen, but it could probably be made a non-issue if MS just wrote another transpiler: oldTS -> newTS, for people whose choice of Typescript meant they had committed from the start to a system that would ALWAYS require transpiling.

Re: JavaScript libraries should be written in TypeScript

#254

Post by dmethvin »

Matthias247 wrote: post #245
tkinom wrote: post #217

Earlier quoted context omitted.

I see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know. declare var _: { each (arr: T[], f: (elem: T) => U): U[]; delay(f: Function, wait: number, ...arguments: any[]): number; template(template: string): (model: any) => string; bindAll(object: any, ...methodNames: string[]): void; }; declare var Store: any; If there is bug in this co…

This is only a typescript definition. It only shows you the types that were already there - even before typescript was introduced. And if the JS developer was not aware that these are the accepted types for the functions then he obviously wouldn't also be able to use or debug it in pure JS.

Right, for the human there are still the English API docs to figure out the arguments and return values. These are the type annotations that TypeScript uses to let you know when you've misinterpreted the API docs, which is an incredible time saver.

Re: JavaScript libraries should be written in TypeScript

#255

Post by hokkos »

Matthias247 wrote: post #247
hokkos wrote: post #208

I would use Typescript, but its type system isn't smart enough to handle the complexity of JS ecosystem. The other day I wanted to move my project to typescript, the first module needed ambient definition that didn't exist in Definitely Typed repo, it was quite annoying to create, and I am not even sure it's correct, then I wanted to type some parsed JSon that had a TYPE_NAME property with a string giving its type, i…

I often use tagged union like interfaces in TS. It's definitly doable, but it might be a little more work than in Flow. For the definitions I do things like interface BaseInterface { TYPE_NAME: string }, interface DervicedInterface extends BaseInterface { ...content }. And to safely access the content of one or the other type I'm using user defined type guards like function isDerived(a: BaseInterface): a is DerivedIn…

Thanks, I didn't think of that, it's a little more work and error prone with functions and else/if code and less aesthetic than the switch/case that works with Flow, but I might restart my typing goal knowing that.

Re: JavaScript libraries should be written in TypeScript

#256

Post by olmo »

moron4hire wrote: post #140
danielmason wrote: post #128

Earlier quoted context omitted.

I'm sympathetic to the worst-of-both-worlds problem, but can this actually be true? In the case of types, constraints actually are the benefit, right? Do you mean that if you don't have compile-time assurance for 100% of the code, the value of whatever % type coverage you have isn't very useful? As someone who's evaluating Typescript and Flow for a team of JS devs, my intuition is that having some typed code would gi…

When in Rome, do as the Romans do. If you're programming in a dynamic language, there are things that you do that would not easily fly in a static language. Things like tests for truthiness. On first blush, from a static background, something like "var p = x && x.y && x.y.z || w;" look terrible, but they're pretty standard ways of cascading through different options without causing null pointer exceptions in a langua…

Sorry moron4hire but you are underestimating TS types system.

You can write quite crazy expressions abusing Boolean operators and he successfully keeps the static type.

You can also have different method overloads signatures as long as you have a more general implementation that does the dynamic checks at run-time manually. Most of the time you can use Union types anyway.

The big collection of definition files for almos any JS library out there is a living proof of how is possible to describe statically almost any JS API.

Let's face it, dynamic languages are about laziness, not about 'unconstraibed creativity'

Re: JavaScript libraries should be written in TypeScript

#257

Post by lloyd-christmas »

jasonkester wrote: post #167
lloyd-christmas wrote: post #71

Earlier 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.

I love the irony in this comment (and a couple of its siblings). It's as though crazy javascript tooling is so deep into the bones of javascript developers that they can't even tell when they're using a tool. I expect you were genuinely sincere in your suggestion.

You're criticizing a comment making an assumption about javascript tooling, on a thread specifically ABOUT javascript tooling? If you aren't using javascript tooling, wouldn't a change in that tooling have no impact on you? Seems like an odd criticism to me.

Regardless, the only thing I mentioned was npm. I don't consider node/npm to be "crazy javascript tooling". So yes, I was genuinely sincere.

"In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later. Earlier versions might work, but are not supported."

Welcome to [1]2011, where the most prevalent front-end codebase requires node and it's package manager to contribute. Feel free to peruse the countless other commonly used libraries. Maybe you can point out a widely used front-end codebase that doesn't use node/npm/git? The only one I could find was BabylonJS, which uses bower. Conveniently to my point, bower is dependent on node/npm/git.

Writing code in a text editor and saving it with the extension .js makes for a javascript file. We know that. Using that file in the browser means using some a tag. Whether its from the server or through a cdn, that script tag contents/url will still have to be in javascript, even if you used typescript to develop it. No negative impact on text-editor user-land.

[1] https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7...

Re: JavaScript libraries should be written in TypeScript

#258

Post by vorg »

agentgt wrote: post #248
BinaryIdiot wrote: post #48

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…

> "API to be consumed in language X then you need to write the API itself in language X" I have to agree with the OP's point if your writing a library you should write it in the base language (common denominator). I work on JVM stuff and nothing is more annoying then dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java. Plain Java on the other hand works fine in Scal…

> nothing is more annoying than dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java

I don't think the backers of Scala and Clojure make the claim that libraries written in their language will work seamlessly in Java, only that libraries written in Java will work in their language. The marketers of Apache Groovy, otoh, do claim code written in it will work in Java but from what you say that claim is false.

Re: JavaScript libraries should be written in TypeScript

#259

Post by je42 »

Types are nice, but in the end a type doesn't convey all the semantics.

Types also add overhead. They can be also superfluous and unnecessary.

Getting your types in a application right and to gain the optimum from them is quite some work.

Over the years, i learned to appreciate more unittests over more types.

Re: JavaScript libraries should be written in TypeScript

#260

Post by theptip »

Does TypeScript suffer from the same performance issues that Gradual Typing systems share [1], or does it sidestep these by virtue of being transpiled? Naively I'd guess not, which would mean that converting a library to Typescript would often impose a severe performance impact on JS users, but potentially afford significant gains for TypeScript users.

In TypedRacket, for example, using types in some (but not all) of your code can result in up to 100x slowdowns, until eventually breaking through into performance gains once most or all code is converted.

[1]: http://blog.acolyer.org/2016/02/05/is-sound-gradual-typing-d...

Post reply on HN