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

101–110 of 163 posts

Re: TS to JSDoc Conversion

#101

Post by rcarr »

alpaca128 wrote: post #88
rcarr wrote: post #49

Earlier quoted context omitted.

I’m sorry, but if it’s using the same starting symbol as a comment, and it’s greyed out in the text editor like a comment, then you can call it whatever you want, but it is a fucking comment. There are a bunch of unused symbol combinations on the keyboard that could have been used, there is absolutely no excuse for it.

> it’s using the same starting symbol as a comment In Java the keywords "public" and "private" use the same starting symbol too, what's your point? Attributes start with "#[", comments with "//" or "#". That's clear enough. > it’s greyed out in the text editor like a comment A language isn't responsible for a specific text editor's syntax highlighting.

> A language isn't responsible for a specific text editor's syntax highlighting.

It’s even greyed out like a comment in the official symfony documentation.

Re: TS to JSDoc Conversion

#102

Post by _oyks »

skrebbel wrote: post #69
_oyks wrote: post #25

For anyone who is still confused - they're still gonna be using TypeScript in that they will have a tsconfig.json, `allowJS: true, checkJS: true` but they are just writing the files in JS with JSDoc type annotations, they'll still have `.d.ts` files to allow TS developers to use it without issues. Is it contrarian - yes - is it insane - no, not really. Edit: the motivation seems to be to simplify processes - running…

XNR looks nice! I’m impressed that it can be faster than esbuild-runner, is there a downside?

I know why it's fast (it doesn't do anything it doesn't need to), but not exactly sure why it's faster than esbuild-runner; presumably it had a higher latency when tested.

(and downsides not really, beyond it's pretty fresh so bug reports welcome)

Re: TS to JSDoc Conversion

#103

Post by javajosh »

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

Great move, Rich! It's quite enjoyable working without sourcemaps.

I'll add that IntelliJ+Copilot makes writing solid JSDoc very fast and easy.

Re: TS to JSDoc Conversion

#104

Post by TehShrike »

arzke wrote: post #90
TehShrike wrote: post #38

Earlier quoted context omitted.

I've been using Svelte in production without SvelteKit for around 5 years now. The docs have always been pretty great in my opinion

Is there any reason you wouldn't want to use SvelteKit now that is has reached version 1.0?

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.

Re: TS to JSDoc Conversion

#105

Post by myvoiceismypass »

bilalq wrote: post #58

It's immediately clear from the very first few lines of the PR that they're sacrificing safety for this. Before: import { Node } from 'acorn'; import * as code_red from 'code-red'; export const parse = (source: string): Node => code_red.parse(source, { sourceType: 'module', ecmaVersion: 13, locations: true }); After: import * as code_red from 'code-red'; /** * @param {string} source * @returns {any} */ export const p…

Maybe I am unfamiliar with jsdoc, or what the shape of Node from acorn is, but yeah if every function is returning any, that seems like a big downgrade and sacrifice.

Re: TS to JSDoc Conversion

#106

Post by capableweb »

preommr wrote: post #100
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.…

> 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 different build steps. Then it starts to add up both in bandwidth, and in storage taken.

Luckily, there are still package and library maintainers who care about making things less, instead of more, both in architectures and size.

> Just so that people can modify the source code directly a little bit easier?

This is a real thing that is useful to think about, how to make your software easier to change in the future, while just solving the current concern without over-engineering the solution.

Re: TS to JSDoc Conversion

#107

Post by maxloh »

_oyks wrote: post #25

For anyone who is still confused - they're still gonna be using TypeScript in that they will have a tsconfig.json, `allowJS: true, checkJS: true` but they are just writing the files in JS with JSDoc type annotations, they'll still have `.d.ts` files to allow TS developers to use it without issues. Is it contrarian - yes - is it insane - no, not really. Edit: the motivation seems to be to simplify processes - running…

What is the reason behind choosing sucrase over swc?

FYI, you committed the wrong license file. The license file contains license text of a standard MIT License, but your project is licensed under Apache...

Re: TS to JSDoc Conversion

#108

Post by bottlepalm »

Wow so much overhead, but I can see why if the problem is trying to step into some npm package code - landing on a type definition file is not helpful

It makes you think why can't the TS compiler produce JS code with JSDoc annotations instead of source maps. Ship the node packages with that so that debugging into the framework is seamless and easy to edit.

Re: TS to JSDoc Conversion

#109

Post by POiNTx »

Little side note, I'm always in awe of the amount of crap open source developers have to take from the community vs the crazy amount of value they offer. There's a lot of backlash on something 99% of commenters will never have to interact with. A lot of knee jerk reactions without trying to understand what's going on. And in return projects like Svelte offer an insane amount of value for people and businesses. Thankless work.

Nowadays it's expected that you get software for free, and if you don't like it you have the moral right to complain at insane lengths at the maintainers of this software. Even if you don't agree with certain decisions (which in this case shouldn't even be the case), there's a way of going about things, you're dealing with people, not faceless corporations.

Re: TS to JSDoc Conversion

#110

Post by _gruntled »

preommr wrote: post #100
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.…

> 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 completely switch over to js and then set types that way seems regressive.

"It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take.

Post reply on HN