Live data from Hacker News

TS to JSDoc Conversion

github.com

81–90 of 163 posts

Re: TS to JSDoc Conversion

#81

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…

TS compiler should have an CLI option to compile without type checks. TS features don't need types to produce output[1] and this is supported by the compiler; it just doesn't have a CLI option. Compiling without types is supported the compiler itself (this is what Babel does). [1] Except const enum and export *

It's really VERY easy to use something like esbuild or SWC though and just use TS for doing checks on the side. SWC would have ripped the TS annotations out of the top 100 TS projects on GitHub before I even finished typing this sentence.

Re: TS to JSDoc Conversion

#82

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…

What your build/deployment steps without the Typescript syntax? Do you bundle or minify at all, or do you release your source files directly? Or is this mostly for NodeJS/server side stuff?

I ask because for most of my projects there's at least some bundling going on, and in that case the added complexity of Typescript compilation is pretty minimal - with tools like Vite there is no added complexity, because JS and TS files are going down exactly the same pipeline, parsed by the same parser, etc. And I could get rid of the bundler, which would make some things simpler, but makes imports and deployment more complicated. For the scale of projects that I'm working on, bundling feels like necessary complexity.

I guess I'm trying to figure out if this is a useful form of minimalism for the sorts of projects I work on, or if this is the sort of thing that works for some projects but not others.

Re: TS to JSDoc Conversion

#83
I remember not using/trying Svelte because there was no TS support and it took quite some time before TS support emerged. With that in mind it doesn't surprise me they are not doubling down on TypeScript.

Re: TS to JSDoc Conversion

#84

I remember not using/trying Svelte because there was no TS support and it took quite some time before TS support emerged. With that in mind it doesn't surprise me they are not doubling down on TypeScript.

this has nothing to do with "TS support" at all.

Re: TS to JSDoc Conversion

#85
post #78

Earlier quoted context omitted.

You are making judgements based on a draft PR. There is a ton of work still to do.

> There is a ton of work still to do. What's the estimated ROI?

That depends on how much you value getting a bunch of developers to think about svelte, jsdoc, and typescript.

Re: TS to JSDoc Conversion

#86
post #55
post #52

We are (unfortunately) already doing just JSDoc. Typescript migration was on our road map, but when we dug into it, it didn't solve the biggest issue we had with Javascript, which forces the developer to be aware of various pitfalls. Because of that, we didn't feel that TypeScript solved enough of JavaScript's faults to warrant a migration. I still think that TypeScript is great and has some of the best tooling I've…

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.

Re: TS to JSDoc Conversion

#87

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 was skeptical at first when we made the change in SvelteKit. However, SvelteKit has a large integration test suite and being able to change the code and rerun the tests against the real final version of the code without waiting for any build step to complete has been a big improvement to productivity and I'm now a big fan of having made the change there. The tradeoff may be a bit different in Svelte core where we have more unit tests and fewer integration tests, so we're still investigating and considering the change, but we do have experience with both approaches and at the end of the day great software can be built using either approach.

Re: TS to JSDoc Conversion

#88
post #49
post #35

Earlier quoted context omitted.

I don't see any comments there, I see attributes though [1]. Is that what you meant? From the page you linked: > Routes can be configured in YAML, XML, PHP or using attributes. All formats provide the same features and performance, so choose your favorite. Symfony recommends attributes because it's convenient to put the route and controller in the same place. Attributes are not comments, they are an official structur…

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.

Re: TS to JSDoc Conversion

#89
*Svelte compiler. Users of Svelte are unaffected

I don't know the details of their situation, but I definitely can relate to the build step being a huge pain in the butt for Node projects. It's why I've stopped using Node whenever I can afford to, in favor of Deno (or maybe one day Bun). I used Deno to build a compiler for a personal language project recently, and it was an absolute delight not having to deal with any of Node's BS. Assuming they can't afford to migrate runtimes at this stage, I definitely get why they'd explore other options

Re: TS to JSDoc Conversion

#90

A bit off-topic (sorry): Is anyone using Svelte in production without SvelteKit? Hows Svelte documentation as of late?

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?
Post reply on HN