Rich Harris is NOT Getting Rid of TS Support in Svelte
Tags: javascript, svelte, typescript, webdev
Published: 2023-05-13 16:21:23

Someone briefly quoted Rich Harris saying he wants to migrate the Svelte Core Code to use [JSDoc](https://jsdoc.app/) instead of Typescript. This shouldn't have been that controversial, at least not for the Svelte team. Why? Because it doesn't affect you...

___
⚠️ I want to preface this article by stating that I am a HUGE fan of Typescript, and I firmly believe it is best practice. My biggest worry is the quality of code that eliminating Typescript will give you, but I highly respect Rich Harris and the decision.
___
🙏 That being said, while I imagine the quality of the Svelte team developers are amazing, not all users of Svelte are. Anyone who uses Svelte without AT MINIMUM **JSDoc**, is using bad practice. So, please, I repeat, PLEASE, make the [Svelte REPL](https://svelte.dev/repl/) support Typescript. I would recommend [SvelteLab](https://www.sveltelab.dev/), but unfortunately, they also decided to make JS the default option. It is not even clear how to switch to TS (Set Default Template). Stop sharing Svelte code in JS!!!
___

## Why this Doesn't Matter...?
&nbsp;
### 1. Uh, SvelteKit is already using JSDoc

That's right! The [SvelteKit repo](https://github.com/sveltejs/kit) doesn't have any `.ts` files in it! To be clear, I am considering `.d.ts` a different extension... keep reading for clarity on that. [Sapper](https://github.com/sveltejs/sapper) used TS, but SvelteKit does not (Sapper was the precursor to SvelteKit in case you don't know).

But why would you write two related code bases (if you consider Svelte the parent of SvelteKit) in two different languages? You wouldn't. In fact, it could affect the interoperability. He decided to rebuild the [Svelte repo](https://github.com/sveltejs/svelte) so that it makes sense. No problem with that.

### 2. JSDoc is NOT Vanilla JS

JSDoc gives you primitive type support. It is support for functions and arguments. It is more closely related to the [type annotations proposal](https://github.com/tc39/proposal-type-annotations), which will probably see the day. This means [Matt Pocock](https://www.totaltypescript.com/) and all his clever Typescript tricks won't be useful, but you're still not going to be able set a string as a number. Typescript is so, sooo much more, but...dall

### 3. JSDoc is Typescript's Stripped Little Brother

This has been arguments that JSDOc IS Typescript, and for good reason. You need Typescript for JSDoc to work, or at least `.d.ts` files. Yes, you can import the files fine, and YOUR code must adhere to best practices. This means... and wait for it...

### 4. You CAN use Typescript Just Fine

I specifically asked Rich Harris when he planned on removing TS Build option, admittedly before I understood what is happening, and he replied [Never](https://twitter.com/jdgamble555/status/1639998192291835904). I think this specifically is why people are freaking out. This was not clear. Your code will use TS just fine.

### 5. No Build Step

Last but not least, the principal reason he wants to get rid of TS, is because there is no build step. This means you can have your cake and eat it too. You can write your app in TS and your builds will be smaller (seems [generally better than minified](https://twitter.com/Rich_Harris/status/1350436286948122625)); therefore your app will be more performant. This is for a library. Remember that.
___
Personally, I'm indifferent. If it really is more performant, I'm all for it. 

Do you see any performance gains? Genuinely curious...
___
See more articles at [code.build](https://code.build)...

J