Live data from Hacker News

JavaScript libraries should be written in TypeScript

staltz.com

191–200 of 285 posts

Re: JavaScript libraries should be written in TypeScript

#191

Earlier quoted context omitted.

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

You mean in TS?

Yes. ∀ x: I can do x in JS → I can do x in TS

But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false.

This implies TS = JS. And that's the point: semantically, TS = JS.

Re: JavaScript libraries should be written in TypeScript

#192

Earlier quoted context omitted.

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.

If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.

Re: JavaScript libraries should be written in TypeScript

#193

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 ;)

not sure what you're trying to say.

Re: JavaScript libraries should be written in TypeScript

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

ES6 provides solutions for #1 and #2. These will replace the fragmented existing solutions.

I'm not sure I understand #3. Closures?

1. https://babeljs.io/docs/learn-es2015/#modules

2. https://babeljs.io/docs/learn-es2015/#classes

Re: JavaScript libraries should be written in TypeScript

#195
post #170

Earlier quoted context omitted.

In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for. This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations…

You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :) Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs

That's interesting to know! Thanks

Re: JavaScript libraries should be written in TypeScript

#196

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 IS pretty damn good. My IDE does a pretty good job at analyzing the structure of scripts.

So, I guess I have not yet felt the pain that "requires" a language upgrade. Unlike Java, which has really gotten to chafe me.

But then again, I started work back in 1985 using a scripted language (dBASE), with its own version of "eval", to make cute little UIs and reports that tied into the "real computer" / software (even if data swapping was swapping nightly batches of ISAM tuples, rather than REST calls). I also enjoyed using Perl in the 90s / early 2000s.

Then as now, the Serious People want you to wallow with them in the bondage and discipline of a Real Language, so you can type until your fingers bleed :-)

That said, I do write a lot of "JSDoc" in my code, and I resent the people who refuse to write Javadoc in their Java, because of course the types all make it crystal clear - NOT!

Re: JavaScript libraries should be written in TypeScript

#197

Earlier quoted context omitted.

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

You mean in TS? Yes. ∀ x: I can do x in JS → I can do x in TS But, let's assume for a second that you couldn't: this thread is about TS being future-proof. I.e.: ∃ x: I can do x in TS & I cannot do x in JS? No, false. This implies TS = JS. And that's the point: semantically, TS = JS.

OK, that's a good start. Is there a tool analogous to JSDoc for TypeScript that gathers the same docs without repeating the type info already in the code?

Re: JavaScript libraries should be written in TypeScript

#198

Earlier quoted context omitted.

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

If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.

JavaScript makes this process optional, and it only needs to go wrong once to become a problem.

Personally I saw over a million dollars lost and an entire team laid off after a piece of code started working with a value that was expected to be a number but wasn't.

Re: JavaScript libraries should be written in TypeScript

#199
post #81

I completely agree with the sentiment that typed libraries are more stable and self-documenting. You can autogenerate documentation from typescript and it's guaranteed to be up to date, unlike JSDoc comments. I personally have converted a few of my libraries [1] [2] over to Flow. It helps me personally, catches a lot of bugs, and does a great job of self-documenting while not getting in the way. Flow has a lot of bug…

> 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 latest features or being fully TS-compatible. On the other hand, Flow's typechecking is far less complete, and it still uses its own home-rolled parser which occasionally has issues parsing certain ES2016+ features, such as decorators.

If I were starting a project from scratch, I would likely use TS as it's simply more complete. But if I were migrating an existing project, Flow starts paying off right away and is easy to integrate.

Re: JavaScript libraries should be written in TypeScript

#200

I still run into libraries written in Coffeescript, and hate it when I do, because I don't use it and have a hard time following it. Javascript libraries should be written in Javascript. Worship the one true God!

Then just compile the library and everything will read like really well-written JS.
Post reply on HN