Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TS to JSDoc Conversion

github.com

Post reply on HN
Print view View original

141–150 of 163 posts

Re: TS to JSDoc Conversion

#141

Post by Zamicol »

hn_throwaway_99 wrote: post #95
Zamicol wrote: post #86

Earlier quoted context omitted.

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

>type validation library to assist with this example?

We don't, thus "[TypeScript] didn't solve the biggest issue[s] we had with Javascript".

Also just noticed that I used the singular "issue", I meant the plural "issues", as there are many.

If I had an option to use an alternative to JavaScript, I would in a heart beat. But it's not practical to not use Javascript

Re: TS to JSDoc Conversion

#142

Post by kwhinnery »

rich_harris wrote: post #61

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

Just jumping in here to applaud the usage of "luddite numpties" in a sentence.

Re: TS to JSDoc Conversion

#143

Post by ojr »

I still feel vindicated, you don't need Typescript to write type definitions and also type safety on the server/api can be done with Graphql and writing gql

Re: TS to JSDoc Conversion

#144

Post by dannyfritz07 »

rich_harris wrote: post #61

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

[dead]

Re: TS to JSDoc Conversion

#145

Post by TehShrike »

nerdywordy wrote: post #127
TehShrike wrote: post #104

Earlier quoted context omitted.

The business apps I work on don't benefit from SSR (having to write components that can render server-side is friction without payoff), and I already have a client-side router that supports nesting.

What router are you using? One in the svelte ecosystem or a vanilla js router? Also in the process of writing an app that has no ssr needs. There are some minor annoyances with SvelteKit and interested in other options.

I'm still using https://github.com/TehShrike/abstract-state-router which I wrote years ago after thinking "ui-router is great, but I need a version that can keep using no matter what component library I want to use in the future"

Re: TS to JSDoc Conversion

#146

Post by MaxArt2501 »

_gruntled wrote: post #110
preommr wrote: post #100

Earlier quoted context omitted.

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

> It's also a really contrarian viewpoint about typescript which is really popular. I really, really don't get the controversy here. JSDoc _is_ TypeScript, just with a syntax that's valid JavaScript (on account of it living in comments). This means it doesn't have to be built to run, but still gets all of the typing goodies regular TypeScript does. The end-user code authoring experience is the same or better. > To co…

> JSDoc _is_ TypeScript

No. At least, it didn't used to be. JSDoc had its own syntax, but now you can piggyback its format and put TypeScript inside. So now you can write `@type {Record}` instead of the "classic" `@type {Object.}`, and use some more TypeScript goodies.

You can even kind of use generics with JSDoc, still thanks to TypeScript, but then again... you're not really leaving TypeScript, you'll still have to deal with TS versions, and probably with some of the not-clearly-explained "papercuts" from above.

And finally, I'm not sure that JSDoc+TypeScript is perfectly equivalent to TypeScript. I have a hunch that some of the advanced strategies, e.g. involving `infer` or `extends`, aren't really replicable in JSDoc - or at least I have no clue how to do that in JSDoc - so we'll have to settle for weaker definitions in some cases. So, I'll have to see if it's actually "the same outcome".

I admit I'm no JSDoc guru, so maybe if somebody is compelled to try harder they might actually find a solution for a transition from TypeScript to a completely equivalent alternative. I'm all ears... but surely, if you try too hard the point will be lost.

All of this just to help the Svelte community to contribute - I'll have to take Rich' word for it. For now, it's the only community I've heard that switched from TypeScript in favor of JSDoc. They'll have to deal with a more verbose and less readable codebase for sure, I think there's no doubt about it. Is it really helping the contributors?

It may work for an open source project with a strong governance, maybe. I have a very different experience with projects that decided to use JS instead of TS. Unless we're talking about a very small project, it always turned out to be an ungodly mess.

> it doesn't have to be built to run

If this is a problem, then you have other problems...

Re: TS to JSDoc Conversion

#147

Post by MaxArt2501 »

capableweb wrote: post #106
preommr wrote: post #100

Earlier quoted context omitted.

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

> tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes Sure, by themselves, but replicate that across everyone repeatedly downloading the library in various build processess, in various projects and with different versions. Sure, by itself a sourcemap might not add up to much. But then there is various projects with different versions, who download the library repeatedly in…

> it starts to add up both in bandwidth, and in storage taken

Are we really talking about disk space in 2023? Seriously?

And bandwidth? Like we don't have several cache systems - including npm's - that can help?

> how to make your software easier to change in the future

Ok, is there someone who can explain in details how would that help?

Re: TS to JSDoc Conversion

#148

Post by FractalHQ »

kwhinnery wrote: post #142
rich_harris wrote: post #61

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

Just jumping in here to applaud the usage of "luddite numpties" in a sentence.

When I try to google this, the top (and only relevant) result is this hn post… mind throwing a bone?

Re: TS to JSDoc Conversion

#149

Post by hn_throwaway_99 »

Zamicol wrote: post #141
hn_throwaway_99 wrote: post #95

Earlier quoted context omitted.

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

>type validation library to assist with this example? We don't, thus "[TypeScript] didn't solve the biggest issue[s] we had with Javascript". Also just noticed that I used the singular "issue", I meant the plural "issues", as there are many. If I had an option to use an alternative to JavaScript, I would in a heart beat. But it's not practical to not use Javascript

I am honestly curious what issues you hit with JavaScript that you find difficult for developers to avoid. I do think JS has a lot of weirdness and pitfalls, but I feel like the things you are actually ever reasonably likely to hit are easy to enumerate and learn:

1. Understanding truthy/falsey

2. The difference between null and undefined (but this is an area where Typescript helps).

3. == vs ===, but this one feels pretty easy to avoid, e.g. just set up eslint to forbid == if so desired.

4. Understand the details of how JS treats 'this' in different contexts. I think this (pun intended) is probably the most important thing to understand.

5. The bizarreness that typeof null === 'object'.

There are of course other issues, but I honestly feel like I rarely if ever hit them, and I've been coding in JS/Node for many years now. I mean everyone loves to point out some of the insane implicit casting rules of JS (e.g. the JSFuck language), but I don't ever hit those in my day-to-day.

I just feel Typescript plus some strongly opinionated eslint rules take 99% of the "gotchas" out of JS.

Re: TS to JSDoc Conversion

#150

Post by superjose »

rich_harris wrote: post #61

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

I think this outlines a bigger problem.

JavaScript Ecosystem itself.

It's incredible we do transpiration, minification, bundling to the same language the interpreter is going to read.

Post reply on HN