Why is compilation an issue? And why did your issue with developers become an issue with the language? If I said my main issue with JSDocs is that most people half-ass them does that make the case against JSDocs?
I really debated on this issue. I love Ts and have no problem reading/writing complex types. However I know they're a pain to debug (to all devs) and read (for most devs). But for a project with crazy complex business rules, I made the call to write complex types (like 3 files worth of utility types to derive a type). I don't know if I made the right call for long term maintainability, but the DX it's unlocked given the tight deadlines and some of the large structural changes we needed to make due to last minute business requirements updates has so far made it worth it.
We don't use TS where I work thus I heavily rely on JSDocs. Great to know there's a repo I can borrow ideas from. But given the choice, TS all the way.
The declarationMap: true ts compiler config generates maps for the d.ts files, so if you have an npm package with the dist folder, and the src folder, you can have direct mapping to the ts files for ctrl/cmd+click. (see RXJS)
Rich seems like a great guy, but he’s said before that he’s only been a full time dev for 2 years. He’s obviously fantastic, but I really worry about his inexperience leading to rough design decisions. Wish him and the svelte team only the best, but I think his experience should be brought up more.
@@Antonio-fo4fl in his last interview with Prime, he said he only became a full time dev 2 years ago. Prior, he coded on the side and worked for a news papers. Again, he’s obviously talented, but there are many lessons you only learn through experience.
Yup. So much bad info out there on this. Even TSUP says you never need those. But the package should send the transpiled js, the source TS, source maps and declaration maps. Then all these tools work. But people are stupid as hell
from a library development perspective it makes perfect sense. im not sure if people will understand this nuance before making the switch to jsdoc though LOL
Guy makes some good arguments. As a security focused individual, I do like the idea of cleaner code to audit; encouraging function descriptions may result in identifying logic issues, not just typing issues.
The more I learn about Rich, the bigger the fan I become. He's just smart and pragmatic, so I'm just going to learn Svelte and know that my tech stack is in good hands.
And in the meantime, I'm going to learn Rust and hope that it becomes widely adopted on the web. It sounds like Rust is just a better designed language instead of the bolted on mess we have in JS land.
Please god no rust in frontend. I’m all the way there to use it for the backend but don’t make the same mistake as JS and use a language for stuff it’s not made
The reasoning sounds solid, but I really like TS as an extra layer for "classic" products, if you work in a non Netflix company (sorry for the shade) you will see how much issues it prevents, if you get strict with it, all the "of undefined" and "of null" issues, plus, it is a nice safeguard and doc when working with people having different levels. It is true though, that devs who don't have sufficient knowledge tend to spend a huge amount of time trying to fix types, but most of those are actual issues that would need solving anyway. Inferred types do a lot of heavy lifting too and I like them. Now what I don't like about TS is the false sense of security when dealing with REST api results per example, or when people use any or as unknown as T. But, overall in product teams, I find it really benificial.
Rich's argument is the reason why I use Deno exclusively for the last 5-6 months for my personal projects. When you go to definitions Deno actually shows you the typescript code that's running. No bs .d.ts . Still today I have not found a solid reason not to go with Deno when doing TS/JS work.
Deno doesn’t allow imports without the .ts extension. So it’s not possible to simply drop in an existing ts project into deno. But for scripts and new projects I definitely enjoy using deno
The d.ts issue is from many libraries not providing declaration maps and the source code. If they did VScode would handle it with no issues directly to the source.
Yeah same, was ready to disagree and dudes actually making good points I didnt consider. I mean not surprising the guy is a 1000 times better at programming than me, but still
The biggest reason for people needing to go to source is mainly not to change stuff, but to figure out what the hack is going on because very rarely anything is documented properly.
I love the callout about "Typescript wizards"! So much of what I've seen from RUclips's Typescript wizard seem to suggest we should actually use a bunch of rather complicated types filled with tons of logic which honestly no one can read without really sitting down and thinking about it for a while. That nonsense helps no one, types are there to help write and read code correctly and ideally save some time but all that goes away if I'm writing and reading types endlessly instead of writing more meaningful code. Keep types but keep them as simple and straightforward as possible, no need to keep them DRY if it's gonna cause headaches!
those complex types are often for incredible autocomplete. you build in the logic of your function into the type, so if something complicated is happening to the values you send into a function, the full structure of data you should expect at runtime comes through. and if you use the function outside what is intended, it immediately tells you in your IDE. the type is there to tell your IDE if what you’re doing with the code is expected. luckily, GPT-4 is incredible at creating and describing types.
What a dumpster fire. The whole ecosystem is so disorganized. JavaScript vs TypeScript vs JSDoc. npm vs yarn vs pnpm. require syntax vs import syntax. node vs deno. The list goes on.
I don't get how JSDoc is better than TS. In ancient days of PHP reign we were told to avoid programming in comments, yet here we are again. I hope to live to see type annotation proposal flourish.
From the point of view of a library user nothing really changes, because you can still use typescript with jsdoc and lsp will work just fine. But it's still interesting to know the reasoning behind this change.
If this came from an avid TypeScript aficionado I would look deep into the reasoning and thoughts behind it. But Svelte has always dragged their feet when it comes to TS support. So I don't think this decision bears much weight in the grand scheme of things.
All this is really a valid point, but actually we wouldn't even have these issues in the first place if TS was first-class in node like in Deno. Then you could write un-minified typescript libraries without needing transpile, retain all your types alongside the actual source files without a separate d.ts file, and be able to edit the TS directly without having re-transpile everything. Basically the best of both worlds. The only reason why we're having this conversation is because Node doesn't have native support for typescript.
Finally someone is speaking facts. TS is garbage it's a dependency that you have to maintain up to date, you don't fully control the JS generated. If you need TS because of your backend you're doing it wrong. JS/TS DOES NOT BELONG TO THE BACKEND.
if JS doesn’t belong to a place then TS doesn’t belong to that same place… if JavaScript is used in any place where it belongs or not then TypeScript should be considered… your argument of JavaScript not belonging is not an argument against TS and given you seem pretty convince I have the feeling that you do have better argument than that… what would it be??? because of course any valid argument against JavaScript in this context should be also valid against TypeScript except for exotic edge cases… Or maybe I misunderstood your point???
Whenever I write TypeScript I feel like I'm always forced to start over-engineering with the type system. With JSDoc you can get type-checking and everything you need, and the code pretty much always ends up more readable and easier to maintain. But since nobody likes writing docs it seems like TypeScript ends up winning anyways, lol.
Jsdoc does not have everything that typescript can do. When you have a large frontend codebase it just does not work well enough. Typescript all the way.
@@mycarrysun JSDoc Types is created by the Typescript team and is 1:1 feature complete and uses typescript under the hood for tooling and introspection support.
@@joshuacooks might want to do some research before spreading misinfo. en.m.wikipedia.org/wiki/JSDoc it was created in 1999 well before typescript was even imagined.
TLDR: TS is still the standard unless you're developing a hardcore library / framework or working in enterprise where they review all external code and won't let ship node_modules into production.
You don't have to be an enterprise to block the flaming garbage heap of potential vulnerabilities and over-complicated dependencies that is node_modules
I think that jsdoc can greatly benefit from some type of type hint where your editor adds the types next to your function arguments for example, like what happens in rust when you have an implicitly typed variable. That would basically solve the readability problem.
You can actually enable inlay hints with tsserver right now in vscode settings, however it does not appear to show hints for variables that are explicitly typed in either TS (which make sense as it would just show the same text twice), or JSDoc(which is not always what you want, like in function declarations inlay hints would be helpful regardless) Maybe someone can make an extension or add a setting to the regular vscode to enable that
4:55 you can still do that with TS libs. TS doesn't become a big ball of mud unless you target super old versions of include aggressive minifying or obfuscation
4:00 i usually go to definition of a liberay code to figure out how to use it in csharp. I tend not to do it in rust. There i just look at examples from the liberay documentaion.
I've always been 100% against transpiling. Just try it: next time you need to add a module to your js app - forget about webpack, vite, ts, babel and all of that. Just add a (m)js file and load it from source. Its beautyful! Makes coding fun again!
@@Oscar08814 Why would you need an example? They are saying to simply write regular JS, as is being said and done by the Svelte Kit team now. It's as simple as that.
I do it all the time. It's... Ok I guess? I generally don't bother above simple scripts, since it's so easy to drop in ts-node or whatever. There's still a bunch of sharp edges, sure, but so does every other option, including bare js and jsdoc typing.
@@therealestsnake just write regular js and you will eventually hate yourself, your team, your job after several 8 hours debug sessions trying to figure out what the fuck is going on in the codebase
@@Oscar08814 For what reason would you need that? There is nothing about it and thats the thing. Create the .js file, import the module and work with it.
I think there's no right or wrong. If JSDoc works for you, then use it. I'll stick with TS personally, but if there's a better option for me and my team, I'll use that.
@@Spidhey yeah I know it, although I was referring to other really cool options that end up transpiled to js, for e.g purescript, elm for FE apps, and a lot more. 😂 TBH elm should be the mainstream tech for FE applications, the ecosystem would be gigantic, keeping a delightful DX.
also i got completely blindsided by rich's argument about changing vendor code. i didn't dive too deep into js before jumping into js and coming from the c world where that is a daydream I didn't even think typescript sucked at that. I would give up that for proper types any day though. when rich said why wouldn't you want to write your library in js, I had so many points. lmao.
@@AR7editing I literally wrote bubble sort using types just for fun. It's a comment in jsdoc vs ts video on this channel. Typescript makes JavaScript fun even though there are quirks to it. Js is also getting better. Also I am the guy who always keeps babbling about how great typescript is if you are ever there. I don't know if it's Turing complete or not though. Also you can understand your typescript code after some years and it'll still be good enough. "Js is getting better"- you gonna have to rewrite your thingy again when that happens. Fun for someone like rich who has to modify vendor libraries he uses that he writes. Not for me who literally downloads bazillion packages from Conan or npm. Gotta get shit done. Again I don't hate JavaScript. I like types. That's it. I wish she had a type system like this. If you've ever had to do generics in c you'll understand, you can't. Void pointers are a nightmare. That's like claiming Frankenstein's monster was a real person. CPP is not a real language. I rest my case.
If you are already using a bundler and other code transforms, why is adding typescript the hard part? Bad excuses all around. Also I guess he doesn't know about d.ts maps
Tbh he seems like a great guy, but I just think he’s an inexperienced dev that happened to hit it off with a great library but not the expertise behind him to effectively manage a project as big as svelte. Not trying to throw any shade at him, but just looking at his background, he only became a full time dev 2 years ago. He doesn’t have enough time to understand from experience how to navigate something like this. Wish him all the best.
Having done just enough (one module) of TypeScript with JSDocs, I have to say that you write the JSDoc anyway if you want the docs. So... there's redundancy. But, JSDoc could be more elegant. The TypeScript to Rust transition seemed fairly straight forward. So, if you went from JS to Rust with just JSDoc, you might have to create a tool to get the Rust forms. Similarly, TypeScript to V. So, I did not go too deep in the TS reachable types. I just wanted some JS code to be thought about more carefully than it had been. And, it was simple code, but I was making distinctions between say a transition token and a session token, which are basically the same but there are a few methods separating them. But, this did not have to do with Svelte. Happy that Svelte mostly works without reducing more years from my life like those given to other packages.
I think this problem can be solved if we had some sort of TS JIT compiler/interpreter in both node and browser (atleast in dev mode) via some extension.
Lol, minimizing and bundling has nothing to do with typescript. You can do that with JS files too. TS can compile to modules just fine. Just configure it accordingly. I find jsdoc the wrong place for types. Back to php times. If you want to document or comment a function that’s great but I’d like to read prose not types. Transpilation sucks indeed and the whole move to ESM was also quite a pita. But people do this without typescript too :)
I feel like it's a net wash switching from TS -> JSDoc. If the biggest issue is the build steps, newer runtimes like deno and bunjs support TS right out of the box
I have no real opinion on TS, but I'm not surprised that the type system is turing complete. Java's generics are. C++'s templates are. Hell HTML+CSS is turing complete IIRC.
I do like comments, I do like things being unambiguous but I do have the perk of only working with myself and so I have descriptive names for everything, I use short functions so it's easy to just read what is going on and comments are only needed for the why, although I might comment a what if a lot is happening because while it is still readable it can still save dozens of seconds. I think the usecase for JSDoc is that it's good for when you can afford to scrutinise over every detail, you will have dozens or even hundreds of people looking at the same bit of code, it's worth putting in the extra time. While with most other projects the efficiency of TypeScript is good, I do wish people would name things better because yes people shouldn't use `a` to name anything, but at least I know what the type is. I think they both work. I'm going to continue to use TypeScript but I guess if I do make something that turns into something big then JSDoc is probably the way forward, it also means that when things do take off everything is going to need to be rewritten anyway and it means that no existing code can slip under the radar.
I think the bigger question is, why are you using TS just to get to TS Docs, when JSDocs skips an entire tooling system and handles types and docs for you. ESLint + eslint-plugin-jsdocs is a one-to-one replacement for TypeScript without all the downsides that come with TS.
@@thejaredwilcurt i usually use bun. Or in the frontend vite. So working with ts is minimal overhead for me. I also prefer the syntax of ts strongly over jsdocs, jsdocs feels like its slowing me down
I don’t know what my misunderstanding about TS is but I don’t understand the concept of turning a dynamic language into a pseudo-static type when I can just use a static language when I need to and a dynamic language when it’s necessary. What am I missing??
What is A? When using TypeScript, it's essential to define the type and function. Just add in a comment if you dont remember, Svelte undergoes frequent changes with each update, the next upgrades on your project will just crash. Cant keep up with this framework
Am I missing something? I am listening this whole time thinking "why not use npm link or yalc and a watch build command?" I have to maintain tonnes of internal packages where I work and this is what I do when I need to develop the package and verify its changes in our main apps. JSDocs seems like a huge step backwards compared to Typescript (but I could be wrong / misunderstanding something)
Im really not a typescript fan, the overhead doesnt make the experience more enjoyable or productive for me just because it helps an IDE autocomplete/reference code or warns me about errors iv got used to not making from experience. When i want strongly typed language which is seldom in the JavaScript world, then i just go with c++ and wasm but my JavaScript experience is about rapid development with minimal type overhead. It's overly complex to achieve most tasks needed in js. Complexity that advanced TS brings can cause more problems then it solves for people who have to understand your code and collaborate with you or onboard people into a project.
I'm very confused why they didn't just enable declarationMaps and even more so why they didn't have linting rules that enforce proper documentation. It genuinely sounds like they solved a problem that didn't exist
God damn it. And so the wheel of frontend devs reviving a practice we moved away from for a reason turns. I kinda had hope that TS was here to stay but now all of the NPM wannabe devs are gunna follow suit. It’s exhausting lol.
@@ThePrimeTimeagen i understand that but I’m never going back to the day where we program in comments. My concern isn’t to do with svelte or Rich’s team, you do you and live your life. My concern is the waterfall effect of devs trying to bring back this practice. Not a world I want to program in again. What’s next, we’re gunna add intellisense to comments so that we can check that out JSDocs are syntacticly correct? Comments are for two things: blaming a previous design decision that your code base can’t go back from, and telling jokes. :)
@@Sergeeeek Because when you develop a function or a class method that takes in an instance of class A, you don't want to accidentally pass it an instance of class B. TS allows it if A and B have the same shape.
But the JSDoc gets typechecked by the Typescript compiler. So JSDoc _is_ Typescript. Why are people presenting this as a move away from TS. This is just moving the TS types to comments, so you don't have to do a compile step. It's still TS!!
The distribution source code argument is a huge red herring. Either you have transpiled typescript or some minified unreadable code... or you have access to the dev source code.
My biggest issues with TypeScript, aside from having a compilation step, is that some devs tend to go nuts with the TypeScript.
There are 2 types of devs and nothing in between
type DevType = 'go nuts with the TypeScript' | 'any everywhere'
Why is compilation an issue? And why did your issue with developers become an issue with the language?
If I said my main issue with JSDocs is that most people half-ass them does that make the case against JSDocs?
@@baldcoder_ it takes more time to compile
I really debated on this issue. I love Ts and have no problem reading/writing complex types. However I know they're a pain to debug (to all devs) and read (for most devs).
But for a project with crazy complex business rules, I made the call to write complex types (like 3 files worth of utility types to derive a type). I don't know if I made the right call for long term maintainability, but the DX it's unlocked given the tight deadlines and some of the large structural changes we needed to make due to last minute business requirements updates has so far made it worth it.
the java infection spreads to other languages
We don't use TS where I work thus I heavily rely on JSDocs. Great to know there's a repo I can borrow ideas from. But given the choice, TS all the way.
The declarationMap: true ts compiler config generates maps for the d.ts files, so if you have an npm package with the dist folder, and the src folder, you can have direct mapping to the ts files for ctrl/cmd+click. (see RXJS)
Email rich and save his time 🤣
Rich seems like a great guy, but he’s said before that he’s only been a full time dev for 2 years. He’s obviously fantastic, but I really worry about his inexperience leading to rough design decisions.
Wish him and the svelte team only the best, but I think his experience should be brought up more.
@@hamm8934 The guy created rollup....I think he has lots of experience lol
@@Antonio-fo4fl in his last interview with Prime, he said he only became a full time dev 2 years ago. Prior, he coded on the side and worked for a news papers.
Again, he’s obviously talented, but there are many lessons you only learn through experience.
Yup.
So much bad info out there on this. Even TSUP says you never need those.
But the package should send the transpiled js, the source TS, source maps and declaration maps.
Then all these tools work.
But people are stupid as hell
from a library development perspective it makes perfect sense. im not sure if people will understand this nuance before making the switch to jsdoc though LOL
agreed
@@Spidhey sveltekit has been using jsdoc for 2+ years now and it's more productive for them. I doubt they will miss ts files. They still use TS
@@Spidhey by then another framework will be trendy, we're good
Guy makes some good arguments. As a security focused individual, I do like the idea of cleaner code to audit; encouraging function descriptions may result in identifying logic issues, not just typing issues.
Primeagen is my favorite Linux person
The more I learn about Rich, the bigger the fan I become. He's just smart and pragmatic, so I'm just going to learn Svelte and know that my tech stack is in good hands.
And in the meantime, I'm going to learn Rust and hope that it becomes widely adopted on the web. It sounds like Rust is just a better designed language instead of the bolted on mess we have in JS land.
I feel the opposite but hey, that's just me.
@@NiclasGleesborg what's your favorite tech stack?
Please god no rust in frontend. I’m all the way there to use it for the backend but don’t make the same mistake as JS and use a language for stuff it’s not made
@@nowayicommented1314 revenge time
things are going to shake up again once the types as comments proposal gets added to JS.
If it gets added
The reasoning sounds solid, but I really like TS as an extra layer for "classic" products, if you work in a non Netflix company (sorry for the shade) you will see how much issues it prevents, if you get strict with it, all the "of undefined" and "of null" issues, plus, it is a nice safeguard and doc when working with people having different levels. It is true though, that devs who don't have sufficient knowledge tend to spend a huge amount of time trying to fix types, but most of those are actual issues that would need solving anyway. Inferred types do a lot of heavy lifting too and I like them. Now what I don't like about TS is the false sense of security when dealing with REST api results per example, or when people use any or as unknown as T. But, overall in product teams, I find it really benificial.
The solution seems to be compiling to js + jsdoc instead of d.ts, or native TS support in browsers/node
Microsoft intentionally doesn't do that to make JS incompatible with TS so that people are forced to use TS. It's called "extend".
@@NatoBoram No sure. As i know Chrome which is under another company still own more user share of browser....
Rich's argument is the reason why I use Deno exclusively for the last 5-6 months for my personal projects. When you go to definitions Deno actually shows you the typescript code that's running. No bs .d.ts . Still today I have not found a solid reason not to go with Deno when doing TS/JS work.
I went looking for this comment immediately after hearing Rich's first reason
if only Deno was completely compatible with all the npm and Node stuff, and didn't have some questionable decisions, like package urls in code
Deno doesn’t allow imports without the .ts extension. So it’s not possible to simply drop in an existing ts project into deno. But for scripts and new projects I definitely enjoy using deno
@@vikingthedude existing projects it tough yea. After all it's a runtime. Not a framework.
The d.ts issue is from many libraries not providing declaration maps and the source code. If they did VScode would handle it with no issues directly to the source.
Me as a laravel developer always hopping into vendor code
Yeah, that is invaluable, I always end up stealing stuff.
Thanks for the bluesky link.
This sounds like some solid reasoning on why to use JSDoc for library code. Never really thought about it this way.
makes me want to try it, at least once
Yeah same, was ready to disagree and dudes actually making good points I didnt consider. I mean not surprising the guy is a 1000 times better at programming than me, but still
Thanks for the bluesky link, it must have been tough to find.
The biggest reason for people needing to go to source is mainly not to change stuff, but to figure out what the hack is going on because very rarely anything is documented properly.
His Blue Sky account is amazing. Thanks for the link!
I love the callout about "Typescript wizards"!
So much of what I've seen from RUclips's Typescript wizard seem to suggest we should actually use a bunch of rather complicated types filled with tons of logic which honestly no one can read without really sitting down and thinking about it for a while. That nonsense helps no one, types are there to help write and read code correctly and ideally save some time but all that goes away if I'm writing and reading types endlessly instead of writing more meaningful code. Keep types but keep them as simple and straightforward as possible, no need to keep them DRY if it's gonna cause headaches!
those complex types are often for incredible autocomplete. you build in the logic of your function into the type, so if something complicated is happening to the values you send into a function, the full structure of data you should expect at runtime comes through. and if you use the function outside what is intended, it immediately tells you in your IDE.
the type is there to tell your IDE if what you’re doing with the code is expected. luckily, GPT-4 is incredible at creating and describing types.
damn you prime, fell for it 😂
Am I the only one to get Rick Rolled after clicking on Rich's "Blue Sky" link 😭
What a dumpster fire. The whole ecosystem is so disorganized. JavaScript vs TypeScript vs JSDoc. npm vs yarn vs pnpm. require syntax vs import syntax. node vs deno. The list goes on.
Oh and you have to setup your own linter and formatter
This makes me love Rust even more
Writing TS code is still a lot faster. That's the biggest difference. Rust still remains to be a low level system level programming language
There is no JavaScript Vs Typescript. It's an illusion from the way I see it.
@@catmaxi2599 for some people, sure. I can build things a lot faster with Rust.
I don't get how JSDoc is better than TS.
In ancient days of PHP reign we were told to avoid programming in comments, yet here we are again.
I hope to live to see type annotation proposal flourish.
wait what did you put in rich's bluesky link 🤣
From the point of view of a library user nothing really changes, because you can still use typescript with jsdoc and lsp will work just fine. But it's still interesting to know the reasoning behind this change.
If this came from an avid TypeScript aficionado I would look deep into the reasoning and thoughts behind it. But Svelte has always dragged their feet when it comes to TS support. So I don't think this decision bears much weight in the grand scheme of things.
@@jurycould4275 Good catch
Yeah...he's talking about using ts-node...
And doesn't have declaration maps set up
All this is really a valid point, but actually we wouldn't even have these issues in the first place if TS was first-class in node like in Deno. Then you could write un-minified typescript libraries without needing transpile, retain all your types alongside the actual source files without a separate d.ts file, and be able to edit the TS directly without having re-transpile everything. Basically the best of both worlds. The only reason why we're having this conversation is because Node doesn't have native support for typescript.
Problems of js/ts devs are so weird from C/C++ dev perspective.
Like "oh no it's a so frustrating to have compiled libs" wdym it's not convenient ?
I used to work with C++ a lot too so i know what you mean lol
It’s a case study of the blind leading the blind
Yea this is a terrible reason to move away from ts...
This cleared a lot of things I didn't know, will definitely give it a try.
one thing i dont like about TS is it makes some sacrifices on what it can be, so JS can import and use compiled TS code
Finally someone is speaking facts. TS is garbage it's a dependency that you have to maintain up to date, you don't fully control the JS generated.
If you need TS because of your backend you're doing it wrong. JS/TS DOES NOT BELONG TO THE BACKEND.
The benefits of having a single language for the full stack and end to end typesafety is quite major.
if JS doesn’t belong to a place then TS doesn’t belong to that same place… if JavaScript is used in any place where it belongs or not then TypeScript should be considered… your argument of JavaScript not belonging is not an argument against TS and given you seem pretty convince I have the feeling that you do have better argument than that… what would it be??? because of course any valid argument against JavaScript in this context should be also valid against TypeScript except for exotic edge cases… Or maybe I misunderstood your point???
Its more verbose but it makes more sense (9:00). You are more likely to document your code when using JSDocs than with TS.. I am all in for JSDocs.
Wouldn’t the best solution be if they generated js had corresponding js doc?
Whenever I write TypeScript I feel like I'm always forced to start over-engineering with the type system. With JSDoc you can get type-checking and everything you need, and the code pretty much always ends up more readable and easier to maintain.
But since nobody likes writing docs it seems like TypeScript ends up winning anyways, lol.
Jsdoc does not have everything that typescript can do. When you have a large frontend codebase it just does not work well enough. Typescript all the way.
@@mycarrysun JSDoc Types is created by the Typescript team and is 1:1 feature complete and uses typescript under the hood for tooling and introspection support.
@@joshuacooks might want to do some research before spreading misinfo. en.m.wikipedia.org/wiki/JSDoc it was created in 1999 well before typescript was even imagined.
@@mycarrysun He's talking about JSDoc **Types** and not JSDoc itself
Ok, this is very interesting when doing pair programming
TLDR: TS is still the standard unless you're developing a hardcore library / framework or working in enterprise where they review all external code and won't let ship node_modules into production.
You don't have to be an enterprise to block the flaming garbage heap of potential vulnerabilities and over-complicated dependencies that is node_modules
Is that a thing? They just write everything themselves?
@@erkeliwood6037 military and financial institution is like these
they write everything themselves
@@tonyhart2744or copypasta!
3:10 why bundle libs, just ship ts and use "tsx" npm package to run it
let js die
who needs .d.ts while you can just use .ts
when publishing packages
@@fish1r1 "just ship the ts"
@@nomadshiba alongside js files?
I think that jsdoc can greatly benefit from some type of type hint where your editor adds the types next to your function arguments for example, like what happens in rust when you have an implicitly typed variable. That would basically solve the readability problem.
You can actually enable inlay hints with tsserver right now in vscode settings, however it does not appear to show hints for variables that are explicitly typed in either TS (which make sense as it would just show the same text twice), or JSDoc(which is not always what you want, like in function declarations inlay hints would be helpful regardless)
Maybe someone can make an extension or add a setting to the regular vscode to enable that
@@lolotronop I think the main benefit would be if it would use the jsdoc comment and then inlay from that.
The jetbrains IDEs does that
4:55 you can still do that with TS libs. TS doesn't become a big ball of mud unless you target super old versions of include aggressive minifying or obfuscation
4:00 i usually go to definition of a liberay code to figure out how to use it in csharp. I tend not to do it in rust. There i just look at examples from the liberay documentaion.
because of type gymnastics in rust?
I've always been 100% against transpiling. Just try it: next time you need to add a module to your js app - forget about webpack, vite, ts, babel and all of that. Just add a (m)js file and load it from source. Its beautyful! Makes coding fun again!
Hello, hope you're good, is there a repo with an example of this? or a video I can watch about it? Thank you!
@@Oscar08814 Why would you need an example? They are saying to simply write regular JS, as is being said and done by the Svelte Kit team now. It's as simple as that.
I do it all the time. It's... Ok I guess? I generally don't bother above simple scripts, since it's so easy to drop in ts-node or whatever.
There's still a bunch of sharp edges, sure, but so does every other option, including bare js and jsdoc typing.
@@therealestsnake just write regular js and you will eventually hate yourself, your team, your job after several 8 hours debug sessions trying to figure out what the fuck is going on in the codebase
@@Oscar08814 For what reason would you need that? There is nothing about it and thats the thing. Create the .js file, import the module and work with it.
I think there's no right or wrong. If JSDoc works for you, then use it. I'll stick with TS personally, but if there's a better option for me and my team, I'll use that.
There are plenty of better options than TS, this includes js ecosystem at the end of day, you do need to solve a problem, don't you? 🎉
@@Spidhey yeah I know it, although I was referring to other really cool options that end up transpiled to js, for e.g purescript, elm for FE apps, and a lot more. 😂
TBH elm should be the mainstream tech for FE applications, the ecosystem would be gigantic, keeping a delightful DX.
@@Spidhey you have a point, at the end of the day, it's just a matter o preferences
also i got completely blindsided by rich's argument about changing vendor code. i didn't dive too deep into js before jumping into js and coming from the c world where that is a daydream I didn't even think typescript sucked at that. I would give up that for proper types any day though. when rich said why wouldn't you want to write your library in js, I had so many points. lmao.
can you write the points here?
@@AR7editing I literally wrote bubble sort using types just for fun. It's a comment in jsdoc vs ts video on this channel. Typescript makes JavaScript fun even though there are quirks to it. Js is also getting better. Also I am the guy who always keeps babbling about how great typescript is if you are ever there. I don't know if it's Turing complete or not though. Also you can understand your typescript code after some years and it'll still be good enough. "Js is getting better"- you gonna have to rewrite your thingy again when that happens. Fun for someone like rich who has to modify vendor libraries he uses that he writes. Not for me who literally downloads bazillion packages from Conan or npm. Gotta get shit done. Again I don't hate JavaScript. I like types. That's it. I wish she had a type system like this. If you've ever had to do generics in c you'll understand, you can't. Void pointers are a nightmare. That's like claiming Frankenstein's monster was a real person. CPP is not a real language. I rest my case.
If you are already using a bundler and other code transforms, why is adding typescript the hard part? Bad excuses all around.
Also I guess he doesn't know about d.ts maps
Tbh he seems like a great guy, but I just think he’s an inexperienced dev that happened to hit it off with a great library but not the expertise behind him to effectively manage a project as big as svelte.
Not trying to throw any shade at him, but just looking at his background, he only became a full time dev 2 years ago. He doesn’t have enough time to understand from experience how to navigate something like this.
Wish him all the best.
Especially when they are making exactly that... A compiler...
Having done just enough (one module) of TypeScript with JSDocs, I have to say that you write the JSDoc anyway if you want the docs. So... there's redundancy. But, JSDoc could be more elegant. The TypeScript to Rust transition seemed fairly straight forward. So, if you went from JS to Rust with just JSDoc, you might have to create a tool to get the Rust forms. Similarly, TypeScript to V. So, I did not go too deep in the TS reachable types. I just wanted some JS code to be thought about more carefully than it had been. And, it was simple code, but I was making distinctions between say a transition token and a session token, which are basically the same but there are a few methods separating them. But, this did not have to do with Svelte. Happy that Svelte mostly works without reducing more years from my life like those given to other packages.
I think this problem can be solved if we had some sort of TS JIT compiler/interpreter in both node and browser (atleast in dev mode) via some extension.
deno uses typescript, you don't need to compile it; maybe node is part of the problem
Yup so does bun
More specifically: Deno handles the TS -> JS compilation for us so that ES modules written in either language can be used.
Technically Deno and bun just do the transpilation in the runtime, and handles things like maps for you
Lol, minimizing and bundling has nothing to do with typescript. You can do that with JS files too.
TS can compile to modules just fine. Just configure it accordingly.
I find jsdoc the wrong place for types. Back to php times. If you want to document or comment a function that’s great but I’d like to read prose not types.
Transpilation sucks indeed and the whole move to ESM was also quite a pita. But people do this without typescript too :)
Wow, I just checked out this guy's Blue Sky (linked in the description), and just wow
finally a video moving away from ts, time to gear up using jsdoc
I feel like it's a net wash switching from TS -> JSDoc. If the biggest issue is the build steps, newer runtimes like deno and bunjs support TS right out of the box
Tell that to frontend devs
Other than the cumbersome syntax, I don't dislike JSDoc, I used it before I ever tried typescript.
I have no real opinion on TS, but I'm not surprised that the type system is turing complete. Java's generics are. C++'s templates are. Hell HTML+CSS is turing complete IIRC.
19:48 i heard that capcom vs snk 2 soundbyte... You play, Prime?
I don't know why but I feel like Primeagen loves Rich Harris awkawkawka
Love sveltekit, attempting TS but really don't want to know it.
I do like comments, I do like things being unambiguous but I do have the perk of only working with myself and so I have descriptive names for everything, I use short functions so it's easy to just read what is going on and comments are only needed for the why, although I might comment a what if a lot is happening because while it is still readable it can still save dozens of seconds.
I think the usecase for JSDoc is that it's good for when you can afford to scrutinise over every detail, you will have dozens or even hundreds of people looking at the same bit of code, it's worth putting in the extra time. While with most other projects the efficiency of TypeScript is good, I do wish people would name things better because yes people shouldn't use `a` to name anything, but at least I know what the type is.
I think they both work. I'm going to continue to use TypeScript but I guess if I do make something that turns into something big then JSDoc is probably the way forward, it also means that when things do take off everything is going to need to be rewritten anyway and it means that no existing code can slip under the radar.
That's the same thing with langs that compile to lua
For somebody with PHP background, I love this trend!
So what am i doing wrong when i use Tsdoc @-@ (doc for documentation of the code itself and ts for types)
I think the bigger question is, why are you using TS just to get to TS Docs, when JSDocs skips an entire tooling system and handles types and docs for you. ESLint + eslint-plugin-jsdocs is a one-to-one replacement for TypeScript without all the downsides that come with TS.
@@thejaredwilcurt i usually use bun. Or in the frontend vite. So working with ts is minimal overhead for me. I also prefer the syntax of ts strongly over jsdocs, jsdocs feels like its slowing me down
I don’t know what my misunderstanding about TS is but I don’t understand the concept of turning a dynamic language into a pseudo-static type when I can just use a static language when I need to and a dynamic language when it’s necessary. What am I missing??
Prime - the weird linux person
Nice blue sky link 😂
idk you still gotta like bundle and minify your frontend code, usually. Compilation is gonna happen even if you don't use TypeScript.
agree with 'Go to definetion'
Well played Prime. Well played. Never gonna give you up bae.
What is A? When using TypeScript, it's essential to define the type and function. Just add in a comment if you dont remember, Svelte undergoes frequent changes with each update, the next upgrades on your project will just crash. Cant keep up with this framework
Am I missing something? I am listening this whole time thinking "why not use npm link or yalc and a watch build command?" I have to maintain tonnes of internal packages where I work and this is what I do when I need to develop the package and verify its changes in our main apps. JSDocs seems like a huge step backwards compared to Typescript (but I could be wrong / misunderstanding something)
Nope. You’re correct.
Or use tools that work with TS from the get go.
Use declaration maps, use vitest not ts-node, etc.
Thank you for bluesky link much appreciated
;)
But how else am I supposed to feel like a real programmer if I don’t have a compilation step?
Im really not a typescript fan, the overhead doesnt make the experience more enjoyable or productive for me just because it helps an IDE autocomplete/reference code or warns me about errors iv got used to not making from experience.
When i want strongly typed language which is seldom in the JavaScript world, then i just go with c++ and wasm but my JavaScript experience is about rapid development with minimal type overhead. It's overly complex to achieve most tasks needed in js. Complexity that advanced TS brings can cause more problems then it solves for people who have to understand your code and collaborate with you or onboard people into a project.
I'm very confused why they didn't just enable declarationMaps and even more so why they didn't have linting rules that enforce proper documentation. It genuinely sounds like they solved a problem that didn't exist
Most packages don't do declaration maps :(
But yeah that's maintainer error.
And why would anyone want to use ts-node?
I love this exchange 2:37 😂
dang this blue sky website is a true classic 😂
Optional types decalarions need to be added to JS, change my mind!
Ok covered it at the end, good times!
The Primagen fits perfectly as a new band member of Midland 😁
that blue sky link is savage
God damn it. And so the wheel of frontend devs reviving a practice we moved away from for a reason turns. I kinda had hope that TS was here to stay but now all of the NPM wannabe devs are gunna follow suit.
It’s exhausting lol.
Nah this guy is just crazy...I think he just destroyed his library unfortunately. I will never move away from types now.
i swear you people don't realize you get the same type safety and the same auto complete (it literally runs from tsserver)
@@ThePrimeTimeagen i understand that but I’m never going back to the day where we program in comments. My concern isn’t to do with svelte or Rich’s team, you do you and live your life. My concern is the waterfall effect of devs trying to bring back this practice. Not a world I want to program in again. What’s next, we’re gunna add intellisense to comments so that we can check that out JSDocs are syntacticly correct?
Comments are for two things: blaming a previous design decision that your code base can’t go back from, and telling jokes. :)
what about using bun and not having any build or transpilation step?
For every library the blot grows there nothing to prevent. Few years js doc will also be bloated
Typescript is just an unnecessary barrier of entry so that newcomers would think things are harder than they really are, certainly with TS they are.
TLDR; they're both different techonologies with different trade offs, use what ever you like. SHOCKING!
Exactly my feeling from a month ago.
Just followed him on blue sky!
i've been hopping into my dependencies my entire life - in java (including java.base/java.util), in js/ts, in rust, so on
TS encourages type complexity. JSDocs discourages it.
TS is more expressive than whatever JSdoc wants to be.
In the rust world you jump into third part code constantly though
I don't understand how do you import "d.ts" files without going through a build step that removes your "d.ts" imports from the file
very good point
By importing the d.ts file in the jsdoc comment.
/**
* @type {import('./index.d.ts').lang}
*/
export function lang(value)
{
return value;
}
@@supqerior26 Not very ergonomic since you have to "import" it every time, but yeah this works, that's true.
Honestly, what I like to see is a nominal type system version of TypeScript.
Why?
Use classes then
@@Sergeeeek Because when you develop a function or a class method that takes in an instance of class A, you don't want to accidentally pass it an instance of class B. TS allows it if A and B have the same shape.
@@majorhumbert676 What will that change?
@@parlor3115 yeah, it's called structural typing. I'm just curious why someone would need it
Control+click is the most important concept when I use a third party package in Go and Python, I hate js and C# for lack of it
Js doesn’t lack it
What's a mouse and what's clicking
But the JSDoc gets typechecked by the Typescript compiler. So JSDoc _is_ Typescript.
Why are people presenting this as a move away from TS. This is just moving the TS types to comments, so you don't have to do a compile step. It's still TS!!
His blue sky account is great
Thanks for the bluesky link
I took the same path for similar reasons a few years ago.
Types are great, typescript isn't.
Dude never heard about deno 😂like all of these problems got addressed
The distribution source code argument is a huge red herring. Either you have transpiled typescript or some minified unreadable code... or you have access to the dev source code.
It's mainly just that many maintainers have their packages set up completely wrong.
god i love the creator of svelte
but what if you changed the function logic, will you remember to fix the comment(JSDoc) later? for most developers, I don't think so.
That Blue Sky link though 😂
Doesnt svelte also come with it's own build step, contriuteing to the problem?
They said most of the issue had to do with debugging their compiler, yes.