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!!!
Why this Doesn't Matter...?
1. Uh, SvelteKit is already using JSDoc
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.
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, 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
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. 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); 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...
J
Top comments (1)
As you mentioned, there is a line between libraries and projects and seems for libraries it has more pros than cons.
Recently I've been collaborating in a cms which has 2 repos, the first one handles auth, users and the main view, but mainly depends on a second repo that has most of the functionality and I have to rebuild for every change. Sure, it's only 20/30 seconds but you have to also account for the 20/30 seconds you spend trying to see why the changes haven't made any difference until you remember that you haven't built yet or you didn't restarted vite and... well, the workflow is honestly worst. Also, since this project is also in sveltekit, I wan't to use the svelte-inspector, but wait, now the inspector open the node-modules libraries instead of the actual library code... and I know, this rant is about why isn't my project a monorepo? but I think the way Richard explained, it's pretty much the same. You loose some niche features from TS but what you get it's no compilation on change and (I think this is actually the awesome part) while debugging or tinkering you get the library as it is. You can open it and try to understand the original code. I think that part is amazing and well worth it for libraries.