TS vs JSDoc | Prime Reacts 

There's a JS Proposal in stage 1 to add typescript type annotations to JS itself. This is probably the future of all this stuff.

hey man love your videos, they really helped me through some recent burnout

At my last company the CIO was anti-TypeScript, so we ended up using JSDoc. It's certainly was nice not having a compilation step. At other companies, I've also seen people go crazy with TypeScript, going way beyond just adding types, and instead using more advanced language features. Suddenly everything became a class, with interfaces, enums, generics, etc. I'm not the biggest fan of that kind of approach.

I love how what the Google Closure Compiler was doing 10 years ago is now the "new hotness". I can understand even as a Typescript fan why Svelte went that way though: you've got a compile-to-js language inside of another compile-to-js language. Javasception. You are spot on about the translation layer pain.

Before I convinced my team to migrate to TS, I used JSDoc typings in all of my projects. It also helped me very intuitively understand that TS was just... you know, annotations, and most of it didn't actually have any runtime effect.

Typescript refactoring is a huge thing in JetBrains IDEs. It is simply fantastic. Even for JSDoc. But for Typescript it's just better

There is a silly argument in this video. TypeScript is definitely statically typed. The only thing static typing implies is compile time type checking. Saying that TypeScript isnt statically typed because the type information doesn't survive compilation into runtime is like saying C++ isn't statically typed because the type information is lost in the resulting ASM. The presence of the any type also doesn't make it not statically typed just as the presence of dynamic in C# or void pointers in C++ doesn't make those languages not statically typed. These constructs are just exceptions to the type system.

There is a shorter syntax for JSDoc functions typing (TypeScript-like) that is more readable, for example. you can do this to type the function shown at 13:38 in one line like this: /** @type { (p1 : string, p2 : string, p3 : string, p4 : string) => string } */ Defining types in *.d.ts files using TypeScript syntax and consuming them via JSDoc is possible too.

I have hundreds of thousands of LOC in a production codebase that uses this strategy. TS was not popular at the time, but jetbrains supported these annotations out of the box. There is still a bit more typing tricks you can get with TS though in regards to interfaces and type inference/elasion (where you have markers that distinguish types automatically)

I am a C and Rust dev. Last month I had to use typescript. When I realized that there is no dedicated char type my brain exploded.

I use jsdoc types for my work, and it feels like the best decision for me - adds more safety like how I'm used to with Typescript while avoiding the transpilation step. Coworkers who just want to modify my script can do so freely without worrying about adopting a workflow. The rest of the scripts are already js, so mine are just safer!

I love jsdoc and have been using it for quite a long time, the most thing annoys me is that it does take more time in defining types in the comment than write types after the colons, but ever since I start to use copilot, that pain has gone.

I tried using JSDocs to introduce a legacy codebase to Typescript but the ergonomics of it weren't great, especially when you have to import a lot of types - I just ended up just using Typescript. Also advanced typescript syntax is a must for me - I know people keep saying application code doesn't need complex types, but I find the productivity and safety I get from encoding business rules in types to be something I really value.

Not sure what you were thinking by objecting to the author calling typescript a static typing system. It is static typing. That's what it is. If you run a command and a program goes through your code and determines the possible types of every variable mentioned in the code at every place in the code, and ensures the code never uses a variable in a way that doesn't make sense given its possible types, that is static typing. If your program is running along, and it errors out because it was asked to dereference a null, that is runtime (i.e. dynamic) type checking. Static = before runtime, i.e. before your code goes out into production. Dynamic = during runtime, i.e. while your code is running in production. Static = your compiler or type-check program yells at you before you can check in your code. Dynamic = you get paged into work on the weekend.

THIS CHANNEL IS GROWING BLAZINGLY FAST

AWWWWWW HE SAID AT THE FIRST 20 sec "Hi youtube" thats a honor

I'm fairly sure vscode highlights JSDoc type hints out of the box. So at least there is editor support in that regard.

What I found increasingly annoying about TypeScript is if you are using a library written in it and can't jump to the source of a definition since it is obfuscated by the .d.ts files.

I must admit, before TS, I never spent more than a day a year on a type-related issue in JS ... so by going to TS, I have probably lost more time than I have saved.

9:55 Writing the business logic twice does look like describing your interface fully, like something like Haskell would ask of you. But I think it can depend on how far you want to go with Typescript.

The one thing TS has over JS is the *required* transpilation step that enforces you cannot run your code if you do not run the static type analysis. JSDoc is just as capable (in theory) but you can also just bypass the static type checking and run your JS files directly

I think you mentioned it or someone else, but totally agree wirh: TS for applications. Check your options for libraries.

Just bring back ActionScript 3...

Great video, have you tried Deno? It has support directly for Typescript, improved security, outputs a single executable, standard library, ES Modules, Decentralized, and more. I will browse your content you might already have something about Deno.

I know this is old but I agree on the creating a snippet for it, one thing that’s pretty cool with JSdoc is you can use typescript for complex types. Also I updated my vscode settings to but grey background on my comments with white text to stand out

I feel like if you’re writing JS for whatever reason, at the very least, you should use JSDocs for specifying what parameters your functions expect, as that can really help Intellisense and things like that

2:11 "TypeScript is not actually typing anything" here we go! XD

This video ended unexpectedly, I was waiting for "the name ..." I even played the end twice.

I've been using interfaces for React components and it's been helpful there. It's beginning to feel very much like classes though. I like that TypeScript brings us things like typed properties and public, protected, private in particular.

Started using vim motions on vscode, still slow but starting to get in the groove.

Unpopular opinion, chrome should expose directly skia api to wasm, so we finally can replace html and css ourself.

Part of me can understand if someone says that typescript slow you down but I had never experienced that. What actually slow me is when people use *any* assigning properties or calling methods do not exists anymore because they refactor some code months ago.

Been web dev since 2012, never gave in to typescript, given how much work is needed to just get things done, before you take me for a dynamic Andy, my current background is primarily golang and second PHP (with strict typing)

Couldn't the noisyness be almost completely solved by editor extension that displays JSDoc as typescript? So you can write the function in Typescript-lite (only JSDoc subset) and the actual file will contain the JSDoc syntax but you edit it as Typescript?

Typescript is static typing via type hints. Just because it is easy to subvert the type system doesn't mean it isn't statically typed. Also weak typing is orthogonal to static typing.

The ideal situation for JS would be the approach of Python. Python supports types (type hints) but ignores them in runtime. You can run type check as a separate step, like linter.

If you give your parameters clear and understandable names you won't need to constantly refer to JSDOC comments. This can help to reduce clutter in your code compared to using TypeScript types. What are your thought on this?

Would be curious to see a poll of amount of experience with the editors? I’ve been around the world on editors, and end up back at vi (and neovim for a month or so), but would be curious what this large community would say.

I'm quite excited by stc (TypeScript type checker written in Rust.). I'd love to get your opinions about it.

13:13 on the flipside - those TS function definitions with insanely long typed parameters look like swift code 🤢 to someone who’s more used to jsdoc than typescript. another thing you can do is write function templates with the annotations at the top of file and the implementation lower down like a c/pp header file with doxygen comments but the implementation is just lower down in the same js file a language server scanning a codebase for jsdoc comments and @typedefs with no build step is a beautiful thing

I use JSDoc all the time in both Typescript and Javascript files and it's great. I've used JSDoc to import types into Javascript files when it wasn't worth it converting to Typescript. At least with Typescript you can enforce rules like no "any", but with just JSDoc it can be a struggle maintaining the correct types and have it not get stale over time.

The "no-compile" thing is probably unrealistic for most JS-projects that aren't backend node only, because you're probably gonna bundle it, probably minify it, and maybe obfuscate it. At that point, do you want to write comments, or do you want to write in a syntax specifically for type annotations that is likely to eventually become part of the browser standard? It's crazy to me that Svelte of all things is moving to JSDoc, because they *definitely* have to compile their JS to other JS. Is the translation from TS to JS *really* that much of our compilation woes, and not like... obscure bugs in our minifiers and style components and gql tags and macros and and and?

Please, add the links to the articles when publishing videos like these.

The chat protesting about the music is kinda funny lol

It seems like it's a good step up from straight javascript, but once you need complex types and named types, JSDoc would be far more painful than typescript. That said, transpiling is a pain. I get why some folks for some projects would opt out of it.

Comming from someone who has learned early what advantages writing PHPDoc has, I don't get why moving to JSDoc is so controversial for some people. Most IDEs, even Vim have a Doc generator (the one for vim called vim-doge btw.).

As someone who just started learning to code about 5 months ago I’m going TypeScript. Just declaring a type or interface object and passing the props seems much more intuitive than using all the comments and @‘s and stuff JSDoc uses.

I use TS only for small react apps so I may be biased, but my components are accompanied by an interface for its props, and one or two interfaces for the data that is handles (that it may already be defined for another component), and that's it. Maybe a generic for some service's https response. I get that wizardy state where you think you have to define everything as a type, enum, class or interface. Generic wrappers and very complex stuff, but most of the time that's not even needed. At work we do automation of financial processes in js (the erp's scripting languaje, sorry) so there's no way we could be comfortable with transpilation, so I understand that side of the coin too

I started using JSDoc in 2016 before migrating to TS. I still use it for small JS scripts here and there. here are a few points: 1. It doesn’t actually do anything beside some LSP support. You NEED the tranpile step of TS to make sure that you are using the correct type. The transpile step, as annoying as it might be, simulates compiler that prevents you from making many mistakes. JSDoc does not prevent you from shipping a code with incorrect types. 2. It is not convenient. If you have a large project with many custom types, it becomes a huge pain to manage all the types. 3. As far as I’m aware, you cannot export or import a type, let alone modify or embed a type into a new type, pretty common things you can easily do in TS. I don’t understand why some people insist on using plain JS over TS. I still haven’t heard a single solid argument over it beside their personal preference. With TS you can prevent a large number of runtime errors that can easily be overlooked even if you use JSDoc

We have been using dynamically typed languages for decades. The whole type religion is comical. I have yet to run into a production bug that would have been caught or caused by a lack of static typing.

typecheckers are basically always compile-time

The point about comments being faint in vscode was a weird one. At least for me all my jsdoc comments are highlighted with the usual type/variable/keyword colors, only the enclosing comment syntax having the usual faint coloring.

> I don't like comments, but I don't like transpiling Can we have a big amen over here!

This. This is why I watch the channel. Its not really for the information, but its for the refresh courses. I forgot JSDoc existed. I just did a grep search of all my code for the last 23 years. JSDoc was used in my depthsense 3D infrared scanning camera that I purchased in 2014. I still use it even though the company was bought out. Infrared cameras are way more expensive now than back in the day. JSDoc was used with a in-ram javascript database called taffydb. Thanks prime for making me revisit this. I now might take a deep dive into taffydb to see if I can further use it.

I use JavaScript with JSDoc with ZERO (0) tooling for transformation. No transpilatuon, minification, packing etc. Works like a charm!

I use jsdoc a lot primarily because the projects I work on are already in javascript and I don't have the opportunity to convert them to typescript.

I love helix, the key binding are very powerful, and Helix in it self, cut through the hustle of having to install 50 things like neovim, you get the basic out of the box, it's simple to change, keybindings, create languages specific, or project specific, formatting, etc. It's only lacking a better debugger integration to be truly amazing.

I do like both of them. I have a lot of code written in plain JS and JSDoc is just saving my day. You can just put the little comment and your IDE will automagically catch this info and will gladly yell at you if you mess with types incorrectly.

This definitely has its use cases

Personally, I prefer JSDocs. I also write C# for my job. I always ask other developers "How would you feel if you had to write something in another language and compile it to C# (or choose your language of choice)". Why not just write it in C# in the first place? I find the headache of the extra toolchain worse than using JSDocs. Both aren't perfect, but I think JSDocs, for my case, is a better option. Ultimately, you need to write code that works, which one helps you do that is the one you should pick.

Great take, great article. In the end of the day it's always just a tool with its cons and pros, and how mindful you are when using it regardless if its JS, TS or Rust. Lets use some obscure/edgy analogy and say you are with you parent trying to cross the street. In Rust your parent will never stop holding your hand and instead of being hit by a car you will be slapped by the parent (compiler) for trying stupid things. In JS you can run freely but eventually you will be hit by an *undefined* car or you will end up in Area "5"+1. TypeScript just makes that happen less often if you are using it correctly. (Un)fortunately I've never had an opportunity to work with TypeScript due to platform (Salesforce) "lack of support" I am working in, but JSDocs still provides a great way of giving a general idea of methods in/outs, properties and at least enforce you to document your code on the high level.

Bread

Moving to jsdoc is indeed the craziest move that I have heard in a long time.

I dont get it. If u truly want to enforce a type of a varriable, create a custom function to typecheck the new value before assigning.

Thank you for all the content and learnings!! Would just point out that the polls seem very biased because of your audience, on the vim motions one, I only met 1 other person that used vim in the 6 companies I worked at. Most likely you are aware of that bias, but just wanted to point out with other perspective

Couldn't the problem of readability be fixed by a plugin which parses the jsdoc comments, and then display the type in the traditional typescript way after the variable name, in the same way that rust-analyzer displays inferred types (without actually inserting them)?

I’m learning Rust right now and it makes me hate TypeScript lol

I personally use TS in frameworks but JS + JSdoc for anything that would require me to have both the TS and JS files. I find JSdoc more readable when it comes to functions but it obviously has it's quirks such as defining your own types.

To Kendriel, I don't know if this reaches you, but I have a background in 3d animation/VFX as well, and I switched to software engineering at 32. Feel free to reach out if you wanna chat.

macos default hotkeys + macbook touchpad just works. idk. i don't need any "moar speed" cuz i'm not even that fast at thinking

I can appreciate the problem JSDoc is trying to solve, but it's currently too verbose and avoidable for me to want to use it at work. Yeah TypeScript is all implicit anyway if you want it to be, and the transpiling stage can be a pain thanks to the npm ecosystem (which module system which you like to use today kids!), but for our stuff its a lot easier to spot QA problems in TypeScript than in JS. But i hate all of this and just want WASM performance to increase enough to just use Rust instead.

If you want to know how lazy humans can be, try getting used to Vim motions. You'll soon find yourself annoyed at having to move your arm all the way to the arrow keys, and the mouse will feel like it's on Mars.

I feel like in production you would have a bundle and minification step anyways so its transpiled even if it is written in js no?

I used TS for a few projects a few years ago, but just like you mention, I hated basically writing everything twice. I went back to JSDoc.

Type-enhanced is the new web-scale

I sometimes hear people say that typescript is annoying, it needs a lot of time to type everything, etc, so that's why they prefer JS But for me honestly, JSDoc is literally that. I tried it once and it was SO ANNOYING. Type'ing stuff literally felt like a horrible chore. While in TS is so seamless and fluid in comparison, it amazes me so much

I'd like to hear more about the distinction he's making here for typescript types. For the most part, aren't all type systems an abstractions striped away by the compiler at compile time? It's not like assembly uses the same type system as rust or c++.

I like suggested typing just like python. Then build from there.

Waiting for the special video at 69k subs 😂🎉

typescript is not a linter. The fact that typescript compiles to javascript does not invalidate the fact typescript is its own language. In fact one could make a typescropt compile to bytecode or even machine code. There are many languages that compile exclusively to javascript, such as Respcript, purescript, coffeescript, jscoq, ghcjs and etc... And that fact does not imply they are not their own languages. Typescript and Flowjs are fully fledged type systems for javascript.

I feel that the other big advantage of this is if you have a build step that conflicts with typescript. Svelte did not have typescript support for a long time for example, while JSDoc would still have worked. Other examples include codebases like the preact source code, which are incredibly codegolfed for performance reasons so that they minify to the least amount of code. In those cases, you do not want typescript since you want to know exactly what javascript code you write.

If all you're using jsdoc for is type info it's messy to have it as a comment! TS is more readable. However if you already use jsdoc for descriptions of all your functions - adding type info to jsdoc is a minor change. For a public lib jsdoc might be the way to go. But for an application codebase only used by your team of 4 devs, and you only need types, I think TS is more suited.

Have any of the web devs here used Rescript extensively? Its type system is sound, unlike Typescript's; and it too compiles to normal Javascript. But I don't do webdev, so haven't had the opportunity to give it a try.

Meanwhile Deno is happy running TS scripts with no extra work.

There's nothing wrong with "Typescript has static typing" as you say. It's literally what it is, static typing. The fact that it doesn't enforce any typechecking at runtime is irrelevant. Also, TS isn't just type hints nor a linter. It enforces types at compile-time, which I consider exceeds both type hints and linters.

Would comment type Node app run faster than Webpack's bundle? Used to avoid Babel for Node services and instead relied on require rather than sugar syntax.

00:51 aren't these things mutually exclusive (typescript is javascript with extra steps)?

Syntax highlighting can be adapted to coloring the comments for typing.

about the polls, it could also be that your audience is biased towards thinking about programming the same way you do

JSDoc with IDEA is great btw

this works and it is increble for old maintained projects but it is clunky in away and i would say dont do it unless you have to or you want to , the most painful parts are dealing with imports, i love the inline version of jsdocs but it adds extra to the code, typescript is minimal compares to jsdoc //ts const someVar: SomeType = someValue //jsdoc const /** @type {SomeType} = someValue or const someVar = someValue as SomType vs const someVar = /** @type {SomeType} */ (someValue) in most places you sure could use typescript in the anotations and it would work but the most challeging place is genericTypes say you are in react with .js const [someState] = useState(someValue) vs const [someState] = useState( /** @type {someType} */ (someValue) ) choose your headache, its all your pain

Rust is good & easy, i wrote a script to parse image links from a response body firstly in Go then Rust & the rust implementation was +- 50 LOC, where as the go one was +- 100 LOC. The go one was done purely with the std lib, & for the rust one the only xtern crates i used were tokio, reqwest and regex. Rust had way more abstractions than the Go one even for primitives like strings, also the go one didnt work for every site 😂 still love em both tho.. damn this vids about typescript

I used to use JetBrains motions and I could do most things without using the mouse. I was converted to vim tho.

With a good Code Editor, you could just hover over the symbol and you know the type defintions displayed in typescript. No need to read the comments (which are AI autogenerated) at any point. I code since 5 years professionally in Angular on the Frontend side, so it's TypeScript and I'm still not convinced to use it in private projects. And the biggest downside is that even `require` get's replaced and you are forced to use the ES import and get my JS modules from an "default" symbol out of another object for no reason. And another huge downside is, to even have access in my "playgrround scripts" to basic features like "Promise" I already need to have a package.json with an targeted ecmascript defined (or remembering an additional cl argument)

You're going to be documenting anyway, and a lot of it will be in comments. There's no need to introduce the overhead of transpiling and code complexity and litter that TypeScript introduces, and minification will be removing comments anyway.

I feel blessed in having avoided Javascript since its inception :)

Hi, Prime

is there really any good reason to avoid transpilation? tooling has improved, we have esbuild, and swc. what's the special scenario in which transpiling the code from ts to js is such a burnen nowadays that it would be more agreeable to not use it? also jsdoc is ugly af, my 2 cents

JSDoc annotations are much easier to use than typescript

If I were to use JSDoc, I'd want a syntax highlighter that highlighted the JSDoc "comments" differently than standard comments. And it be even better if it provided errors when I don't use them or screw them up.