Hacker News Reader

Comment by rglover | Hacker News Reader

> personally I don't see why you'd want to use anything other than Typescript right now

A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.

View on HN

How are you conscious of types without any tooling? And if you use tooling, then what's the difference?

When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it.

For example, JavaScript default args are really helpful for avoiding type errors:

const nameString = (name = {}) => { return `${name.first} ${name.last}`; };

Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).

...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change.

Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor

> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case,

Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.

IMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.

  basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.

Yes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).

Not to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be

So you do it manually? That's exactly what Typescript was created for, to use tooling and automation to handle these and it's been repeatedly proven to reduce bugs and increase productivity because of it.

Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.

How is TypeScript a crutch for API design?

API meaning data API/structure, not a public/restful API.

Reply on news.ycombinator.com