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

201–210 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#201

Post by dceddia »

ungzd wrote: 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.

I don't see the point made often, but I think that "Java-grade" is what a lot of developers (the backend ones) actually want. Or, rather, they'd prefer if JavaScript morphed into something closer to Java. I suspect many of the strong supporters of TypeScript come from Java/C# and just want plain JavaScript to be abstracted away.

I've gotta say that one of my main fears with TypeScript is the potential proliferation of code written in heavy OO-style where everything is a Factory or Service or Interface or Impl. And that scares the hell out of me.

I know that TypeScript does not mandate code be written that way. Neither does Java. But TypeScript makes it easier for the Java devs to carry over their heavy-OO habits rather than learning a lighter way of writing code, and that's my worry with it.

Re: JavaScript libraries should be written in TypeScript

#202

Post by klodolph »

tkinom wrote: post #176
radicalbyte wrote: post #130

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 have not used TypeScript personally, just read and try some demo of it. But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent. For after look at the v8's C++ code, I can't imagine anyone would write that with C. But when a new language's ego sys…

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.

Re: JavaScript libraries should be written in TypeScript

#203

Post by bpicolo »

hnbroseph wrote: post #193
bpicolo wrote: post #159

Earlier quoted context omitted.

Have you used ClojureScript? Try it out for a month or two on a real project. We can do this all day ;)

not sure what you're trying to say.

There are a lot of good JavaScript alternatives out there. This article sort of misses the point in what's good about alternatives existing - you can use any of them and expect decent interop with javascipt. A library in one is more exclusionary for all the other interests out there.

Re: JavaScript libraries should be written in TypeScript

#204

Post by untog »

bpicolo wrote: post #159
radicalbyte wrote: post #130

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.

Have you used ClojureScript? Try it out for a month or two on a real project. We can do this all day ;)

You've basically ignored the OPs point entirely. Typescript is backwards compatible to JavaScript, ClojureScript most definitely is not.

Not that I'm agreeing with the post in question, but ClojureScript and TypeScript are very different beasts.

Re: JavaScript libraries should be written in TypeScript

#205

Post by betageek »

jowiar wrote: post #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 co…

Unfortunately a few of the more visible members of the JS community seem intent on writing blog posts like this, I'm super tired of 'I have seen the light, this is the 1 true way, anybody who doesn't do this is an idiot' ragebait. I guess it's a sound content strategy (296 points!) but makes me think a lot less of the people who do it.

Re: JavaScript libraries should be written in TypeScript

#206

Post by BinaryIdiot »

mythz wrote: post #152
BinaryIdiot wrote: post #90

Earlier quoted context omitted.

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…

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 CoffeeScript and it cost me a huge amount of time. But like I've mentioned in multiple threads here I understand that's an extremely rare edge case at this point in time.

That's not the only reason I've cited though. Transpiling adds in an extra level of complexity. I hate complexity. In order to test changes you have to transpile the code after your changes before you can test them. Yeah you can automate it but now I'm adding extra packages to my application only so I can run slightly different code than before.

No thanks. I like simplification. As simple as I can make something the better.

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

Maybe? Since I've been using dynamic languages without runtime checking for over a decade I'd like to imagine I'm pretty good at finding most of these issues ahead of time. Still, it gets compiled into a less strict language so it's not a silver bullet by any means.

> You're also waiting for the "magical" WebAssembly target that makes everything better, but instead WebAssembly would end up generating much more unreadable code that runs much slower for JavaScript which already benefits from highly optimized JS VM's in Browsers.

I'm curious, why would you think it would run slower. According to the V8 team its start-up is faster and it uses the same engine so the speeds so be equivalent.

Regardless the code being "unreadable" for WebAssembly doesn't matter. Do you care that bytecode is "unreadable" or MSIL? I highly doubt you do. Same thing here. WebAssembly is going to exist inside and outside of web browsers. But we're also a long way off.

> It would also much larger in size as it would require embedding its own GC and be littered with numerous type-checks in order to support a highly dynamic language like JavaScript.

Wait, why? The V8's team's announcement said they still have to implement GC, etc for the DOM but that stuff would exist in the WebAssembly implementation itself and has nothing to do with your code.

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

Re: JavaScript libraries should be written in TypeScript

#207

Post by novaleaf »

radicalbyte wrote: post #130
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…

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 Promise typing you found on DefinitelyTyped. This will work fine for you, the publisher. But any consumer of your project will be rudely greeted with typing collisions: Things like "The interface 'Promise' already exists in es6.d.ts"

There needs to be a solution to this module publishing problem before people can seriously publish modules (using NPM) using Typescript. Unfortunately, I have been tracking this issue and there is no timeline for resolving it, mostly due to too many different module systems, and handling module publishing being outside the design-scope of Typescript.

Re: JavaScript libraries should be written in TypeScript

#208

Post by hokkos »

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, it's basically tagged union and it doesn't exist in Typescript but only in Flow ... but flow doesn't work on Windows. http://flowtype.org/docs/dynamic-type-tests.html#tagged-unio...

So I completely abandoned my typing adventure.

Re: JavaScript libraries should be written in TypeScript

#209

Post by BinaryIdiot »

tlrobinson wrote: post #181
BinaryIdiot wrote: post #90

Earlier quoted context omitted.

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

> 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 write unit tests. What does dogfooding have to do with anything?

The context of the discussion was around creating libraries for everyone to consume. If you're not testing your code as if it's being run from just JavaScript then you have a blindspot.

TypeScript is not only annotations. Check out the code it generates to support those annotations.

Re: JavaScript libraries should be written in TypeScript

#210

Post by flatline »

tantalor wrote: post #65

Or not, and add type annotations instead. https://developers.google.com/closure/compiler/docs/js-for-c...

I don't understand the lack of love for - or at least general community attention to - the Closure toolchain. Type annotations make a lot of sense for JS - they are native JS, they are optional, and generally conform to the jsdoc standards that people are used to. The Closure type system is pretty decent, as well. I have yet to see a really compelling implementation of a JS-like language that cross-compiles to JavaScript.
Post reply on HN