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 *
TS to JSDoc Conversion
81–90 of 163 posts
Re: TS to JSDoc Conversion
#82We 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…
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
#83Re: TS to JSDoc Conversion
#84I 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
#85Earlier 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?
Re: TS to JSDoc Conversion
#86We 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?
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
#87Lordy, 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.…
Re: TS to JSDoc Conversion
#88Earlier 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.
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
#89I 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
#90A 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