Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

271–280 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#271

Earlier quoted context omitted.

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

For what it's worth, jQuery doesn't need npm. You can grab the .js or link it from the CDN as you prefer.

https://jquery.com/download/

I haven't come across any .js library that doesn't offer the same.

Re: JavaScript libraries should be written in TypeScript

#272

Earlier quoted context omitted.

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

For what it's worth, jQuery doesn't need npm. You can grab the .js or link it from the CDN as you prefer. https://jquery.com/download/ I haven't come across any .js library that doesn't offer the same.

Right, but that link won't change even if they switch to typescript, which is where my point lies. The benefit comes to package contributors, consumers looking for accurate documentation, and anyone that uses a build tool/IDE/or even a text editor with basic syntax highlighting. All of this while having no negative impact on people who only click your link.

I'm not encouraging everyone to adopt it. I just struggle to see any objectionable aspect from anyone that is solely on the consumer side. Basically, if you aren't using any tooling, the world will keep on spinning.

Re: JavaScript libraries should be written in TypeScript

#273

Earlier quoted context omitted.

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

thanks for the link. I'm partially aware of typings, but too into my own implementation right now to consider switching fro definitely typed. I'll give it a try and pray it actually can let me ship an OSS project!

Re: JavaScript libraries should be written in TypeScript

#274

Earlier quoted context omitted.

My memory could be off (on which command failed). I think I still have the repo on my home machine, so I could re-visit and file a bug report. At the time I kept pursuing elm instead. Reports of better FFI with JS is why I had explored PureScript.

Update: The bug is with pulp server https://github.com/bodil/pulp/issues/133

Cool, does it work for you now?

Re: JavaScript libraries should be written in TypeScript

#275

Earlier quoted context omitted.

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…

TypeScript has support for namespaces, and `import` gives you a lot of flexibility. If these aren't sufficient to handle the problem you describe, can you explain how? Can you post a link to the issue you are watching so we can see a better description of the problem you're running into?

Here's a scenario: You write a library that uses Promises, and use bluebird.d.ts for that definition.

For someone to use your library, they will have to download bluebird.d.ts manually and include it. if you (the lib dev) include it yourself, then any other definition of Promise (including if the user has their own bluebird.d.ts definition included) will cause typing collisions.

As someone mentioned, the Typings project might solve this, but there isn't very good communication on this project and the problems it's supposed to solve.

Re: JavaScript libraries should be written in TypeScript

#276
post #258

Earlier quoted context omitted.

> "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 bu…

Sorry for the late reply but yes you can write some Groovy that will not work on Java (I'm trying to find when and where it happened to me... that could have changed).

The issue is that there are things you can do in JVM bytecode that you just can't do in Java and as the JVM develops along with these languages I imagine further interoperability.

You are right about the languages not making promises but there are plenty of library writers who disregard this. A fine example would be Akka and Finagle. Those libraries could have been written in Java thus minimizing dependencies and maybe even overall code size since they have to have a wrapper for Java anyway (typesafe did choose Java for typesafe config). But then again maybe Scala/Clojure buys enough that the wrappers are trivial. I'm just not sure how trivial interoperable wrappers for WebAssembly will be as I imagine WebAssembly will be a superset of what Javascript can do (or maybe not?).

Re: JavaScript libraries should be written in TypeScript

#277
post #57

Earlier quoted context omitted.

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.

Have you ever tried Atom? Its interface is written in HTML5 + CoffeeScript, and it targets CoffeeScript as the primary language. Tell the GitHub guys about tooling...

But besides, judging a language based on available tooling is akin to judging a CPU based on the computer casing looks.

For a real programmer, GNU Nano with appropriate highlighting should be enough. If a language calls itself "high-level" but makes the coding process hard without tooling, it deserves no attention at all.

Re: JavaScript libraries should be written in TypeScript

#278

Earlier quoted context omitted.

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

thanks for the link. I'm partially aware of typings, but too into my own implementation right now to consider switching fro definitely typed. I'll give it a try and pray it actually can let me ship an OSS project!

For a quick and small example to see it in action:

npm init && typings init

npm install debug ms --save

typings install debug ms --save

debug is dependent on ms, so in node_modules you have:

|-ms

|-debug

| |-ms

typings/main/definitions will have

|-debug

| |-index.d.ts

|-ms

| |-index.d.ts

It makes up for this file structure by declaring modules named in a file-like structure so the entire dependency tree is self contained in one file, while only exposing it's own typings through the final export declarations "debug" and "ms". No stepping on toes. Best to see for yourself, it would take a bit to write down.

As a point of info, it only works when people start adding versioning to the typings registry itself. debug and ms are both versioned in the registry, which is the only reason their dependencies are correctly managed. DefinitelyTyped ambient declarations will still break things. Until those are gone and everything is versioned, you'll still need some hacking depending on your dependencies. That being said, I've seen the issues start to fade rather quickly given the short time period I've been using it.

Re: JavaScript libraries should be written in TypeScript

#279

Earlier quoted context omitted.

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.

I'm not saying it doesn't help. I'm saying you can't count on it the same way you can if you're working in a truly end-to-end statically typed environment. Even Scala's type system has its leaks, due to nulls.
Post reply on HN