Live data from Hacker News

TS to JSDoc Conversion

github.com

91–100 of 163 posts

Re: TS to JSDoc Conversion

#91
post #48

JSDoc and Typescript don't have feature parity: OOP that works across files, generics, inline types, etc.

This is a non-issue in practice — complex types can be expressed in .d.ts files and imported. SvelteKit (not Svelte) has been doing this for a long time and it's fine.

I wish this were true. I'm currently dealing with three third-party libraries whose types are out of date with the actual code because they do this.

Re: TS to JSDoc Conversion

#92
post #80
post #19

If I remember right, symfony (php framework) has comments that affect how the code runs which as far as I’m concerned means they’re not comments at all but actually code masquerading as comments. Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing. Edit: Here’s one example, you can define your routes in symfony using comments. Not only that, but it’s actually the officially rec…

Originally Symfony did use comments (docblock style ones like: /* @Route ... */) for this kind of thing, but since PHP 8 they've moved towards using attributes [1]. The syntax of the attributes #[Route(...)] might look like a comment, but they are actually just valid bits of code you can pragmatically inspect through reflection [2] and then choose to run if you want. Docblock comments can also be inspected with refle…

> might look like a comment, but they are actually just valid bits of code

So comments that are code then.

Everyone can sit around going “This is not a pipe it’s a photo of a pipe or my perception of a photo of a pipe”. But if you did not have a sentence above your photo saying “This is not a pipe” or an arts teacher to tell you “this is not a pipe” and there was just a picture of a pipe on the page and someone pointed at it and said “can you tell me what that is?” You would say “why of course, it’s a pipe”. And then all of a sudden it started spouting water out of the end (let’s assume it was a GIF) then you can say “oh it looks like a pipe but it’s actually a water pistol masquerading as a pipe”. The fact that as a dev you have to constantly be on the look out for water pistols masquerading as pipes rather than having a clear distinction between pipes and water pistols is just a piss poor and easily avoidable design decision.

https://en.m.wikipedia.org/wiki/The_Treachery_of_Images

Re: TS to JSDoc Conversion

#93
I don't care what svelte does, but I've maintained projects with jsdoc types and projects using ts directly and IMO using jsdoc tends to be more of a hassle to maintain, had worse ide guidance and in general felt just more cumbersome.

Being able to click through to the implementation in your ide is nice though, but can be solved by the ide.

Re: TS to JSDoc Conversion

#94
post #19

If I remember right, symfony (php framework) has comments that affect how the code runs which as far as I’m concerned means they’re not comments at all but actually code masquerading as comments. Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing. Edit: Here’s one example, you can define your routes in symfony using comments. Not only that, but it’s actually the officially rec…

> has comments that affect how the code runs

> Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing

The key difference with TypeScript is that even "real" TypeScript types never ever affect runtime behavior, they are purely descriptive. This is an explicit goal of the project (and they've had to make some compromises in other areas to uphold it), so I don't see it ever changing

Re: TS to JSDoc Conversion

#95
post #86
post #55

Earlier quoted context omitted.

What kind of pitfalls are you talking about?

Digs through some of my Javascript Twitter rants The latest I ran into, `Object.keys(x).length` appears to recalculate length on every call. There doesn't appear to be a fast (and idiomatic) way to get top level object size in Javascript without using a secondary incrementor.

This seems like a very odd example in many ways:

1. How on Earth would you expect a type validation library to assist with this example?

2. Looking at that example, I would expect that of course it would need to do work on every call. That is, Object.keys(x) is a function call that takes an object and returns a newly constructed array. So I'm not exactly sure what you would expect to be optimized here. I guess what you are saying is that there is no native `sizeof` operator for Objects, but this doesn't seem like some crazy decision.

Re: TS to JSDoc Conversion

#96
post #86
post #55

Earlier quoted context omitted.

What kind of pitfalls are you talking about?

Digs through some of my Javascript Twitter rants The latest I ran into, `Object.keys(x).length` appears to recalculate length on every call. There doesn't appear to be a fast (and idiomatic) way to get top level object size in Javascript without using a secondary incrementor.

If you've got enough keys that it matters you probably want to use a `Map` instead of an object? Maps are faster to write and read is approximately the same.

Re: TS to JSDoc Conversion

#98

We do this at my current company for all projects, it does not mean you don't use typescript, you will still validate all your files with TS, but there's no build step, just a check. Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler. I do this now for all my personal projects, in my opinion it's simpler, faster and closer to…

> Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler. Can with JSDoc define types? And can you define generic types? To me that is the real power of TypeScript, being able to type every object you use.

Yes you can with @typedef and @template

Re: TS to JSDoc Conversion

#99
post #86
post #55

Earlier quoted context omitted.

What kind of pitfalls are you talking about?

Digs through some of my Javascript Twitter rants The latest I ran into, `Object.keys(x).length` appears to recalculate length on every call. There doesn't appear to be a fast (and idiomatic) way to get top level object size in Javascript without using a secondary incrementor.

Of course it does. You're calling a static function that procudes an array. You want to use a Map and use its size property.

Re: TS to JSDoc Conversion

#100

Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up! If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you. If you're rabidly pro-TypeScript and think we're a bunch of luddite numpties, I'm about to disappoint you as well.…

> Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up!

Because people want to follow in the footsteps of big projects that have gained specialized knowledge through experience.

It's also a really contrarian viewpoint about typescript which is really popular.

tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes, and editors like vscode now support going to the source definition for projects that support it. To completely switch over to js and then set types that way seems regressive. Just so that people can modify the source code directly a little bit easier? There are all kinds of tools ranging from ts-node-dev that make watching typescript files easy, with options to skip type checking for better speed. Honestly seems kind of backwards.

Post reply on HN