Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

221–230 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#221
post #152

Earlier quoted context omitted.

This is a biased and uninformative opinion. You haven't seriously tried it, yet you're already strongly against it and your biases suggest there are obscure transpiling bugs when I've yet to see any in practice. Had you used it for any length of time you would've noticed it catches several bugs which you otherwise wouldn't discover until runtime. You're also waiting for the "magical" WebAssembly target that makes eve…

> This is a biased and uninformative opinion. You haven't seriously tried it Correct. I wasn't asked for anything deep here and I already told everyone I haven't seriously used it... > yet you're already strongly against it and your biases suggest there are obscure transpiling bugs when I've yet to see any in practice. I'm against any tranpiling languages. I'm glad you've never seen any in practice. I have with Coffe…

> I'm curious, why would you think it would run slower.

Because every browser already has an integrated highly-tuned JS VM containing several years of advanced compiler research, including JIT's with runtime type profiling, type inference, type-specialized code generation that's highly optimized around JavaScript semantics in order to get today's JavaScript performance. That doesn't exist in WebAssembly which is a low-level statically-typed language that's effectively a compact binary form of asm.js for non-GC statically typed languages like C/C++.

> WebAssembly is still a ways off but I'm excited at the possibilities.

There is for C/C++ but none for running JavaScript which is worse in every way. WebAssembly is thrown around as some intangible moniker that will magically make everything better without understanding what it is and what it would take to implement a dynamic language with it, esp. JS which already has access to the best VM's the world's best compiler engineers can create.

Re: JavaScript libraries should be written in TypeScript

#222
post #199

Earlier quoted context omitted.

> Flow has a lot of bugs and a lot of growth ahead of it, but it is far easier to get started with than TS. I know this was definitely the case when I started using TS a few years ago, but they recently added support for compiling .js files in your typescript projects, so you only need to deal with the compiler one file at a time. Admittedly I haven't used it, but I think it should have made the migration easier. Pro…

That does help a lot and was a long time coming. TS is a little harder to get started with for a few reasons. For one, it simply does more, with features like interfaces (which "sort of" exist in Flow), and public/private accessors. One distinct advantage of Flow is that it is not a build step, but is more like a linter. I like this - it doesn't re-invent the wheel, so you don't have to choose between having the late…

As you mentioned, Flow not being a build step seems to be a big win to me. A lot of different tools use or encourage you to use babel and babel is ahead of TypeScript in ES6/ES7, http://kangax.github.io/compat-table/es6/. If you use TypeScript your chain suddenly becomes much slower/more complex.

Re: JavaScript libraries should be written in TypeScript

#223
post #217

Earlier quoted context omitted.

That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.

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…

Just wanted to point out that that isn't the JS you know because that's just typing information -- it isn't generating any code at all, it's telling TS what the types look like for Underscore's external methods. This would be stripped out completely in the compiled code. The actual code that results in JS just below that is much more typical.

Re: JavaScript libraries should be written in TypeScript

#224

Earlier quoted context omitted.

Have you used TypeScript? Try it out for a month or two on a real project. It's the best thing that has happened to web development in recent years - it improves Javascript in a completely compatible and future proof way. The most amazing thing is that Microsoft created it. It's the polar opposite of Old Microsoft - standards are being followed (not subverted), it's simple pragmatic and has no lock-in.

I love Typescript, I do all my javascript coding via it. However, Though I wish it were, Typescript is NOT currently suitable for defining modules for external consumption. The problem comes down to no effective means of publishing the typings of your project and your project's dependencies. For example, if your project uses Promises, you might choose to include a definition of those promises, or (worse) reference a…

typings[1] does exactly that as long as people start publishing their definitions (which is kind of the point of them). Relying on un-versioned ambient declarations is what breaks things, not having dependencies.

[1] https://github.com/typings/typings/blob/master/docs/registry...

Re: JavaScript libraries should be written in TypeScript

#225
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…

Flow is being ported to work on windows and there are now builds out there for it https://github.com/OCamlPro/flow & the binary downloads http://www.ocamlpro.com/pub/ocpwin/flow-builds/

Re: JavaScript libraries should be written in TypeScript

#226
post #23

Earlier quoted context omitted.

Except this really isn't an issue for TypeScript, it reads that close to JavaScript.

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

WRT Ruby, there's actually Crystal and InfraRuby (off the top of my head) that both seek to add typing to Ruby. For Python there is mypy.

> Only one project out of 5 are big enough to justify it.

No, any library author could benefit (strong set of features, added type safety, additional usability for TS users from proper .d.ts files). Key point here, TFA is about libraries not projects.

>The stack will change in 6 months;

TypeScript has been around longer than 6 months and has only gained traction.

> I will need to train anybody who gets on board, and document it, and maintain it.

Learning TypeScript takes a day at most. And if you really need to justify that lost time, just remember that outside of types, everything else is just ES6/ES7 features.

Document it? Ever heard of self-documenting code?

Maintain it? It sounds like you really don't know what TypeScript is about.

Re: JavaScript libraries should be written in TypeScript

#227
post #10

Earlier quoted context omitted.

It already appeared, and is called Purescript. It's great, and it's about as likely to gain traction as Haskell.

>it's about as likely to gain traction as Haskell So rather unlikely? Haskell has a JavaScript compiler as well, by the way (GHCJS).

> So rather unlikely?

He means it already exists and hasn't overtaken TypeScript's popularity.

Re: JavaScript libraries should be written in TypeScript

#228
post #5

And then new transpiler language appears, with "real" type system, not java-grade. And everyone stops using typescript, treating it as outdated technology.

> not java-grade

If people hate TypeScript like they hate Java, then it's probably going to become the standard.

Re: JavaScript libraries should be written in TypeScript

#229

Earlier quoted context omitted.

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)?…

> 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. Absolutely. Why wouldn't it? Converting to a very explicit byte code type environment versus a language meant to be used by humans? > I have no idea how these things are relevant. Why would adding type annotations to your code affect your ability to wri…

> Why wouldn't it?

Whereas TypeScript/Babel/etc perform relatively simple source code transformations, you'd have to implement an entire JavaScript engine in WebAssembly. It would almost certainly be slower and buggier than all of the big 4 JS engines.

> Check out the code it generates to support those annotations.

Ok, let's do that:

http://www.typescriptlang.org/Playground#src=interface%20Per...

Re: JavaScript libraries should be written in TypeScript

#230
post #70

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

RELIABLE, not READABLE.
Post reply on HN