Someone briefly quoted Rich Harris saying he wants to migrate the Svelte Core Code to use JSDoc 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 support Typescript. I would recommend SvelteLab, 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!!!
That's right! The SvelteKit repo 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 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 so that it makes sense. No problem with that.
JSDoc gives you primitive type support. It is support for functions and arguments. It is more closely related to the type annotations proposal, which will probably see the day. This means Matt Pocock 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
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...
I specifically asked Rich Harris when he planned on removing TS Build option, admittedly before I understood what is happening, and he replied Never. I think this specifically is why people are freaking out. This was not clear. Your code will use TS just fine.
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); 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...