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.

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.

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

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

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 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)

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 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.

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

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 think you mentioned it or someone else, but totally agree wirh: TS for applications. Check your options for libraries.

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.

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

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.

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.

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

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.

THIS CHANNEL IS GROWING BLAZINGLY FAST

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

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

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

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.

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.

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.

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?

Hey man I think you've addressed this already, but where can I find the full VODs (raw, unedited)? I like to re-watch you streams, because i'm busy with baby care, can't tune in live usually

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.

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

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

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?

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

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

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

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.

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.

The chat protesting about the music is kinda funny lol

This definitely has its use cases

Just bring back ActionScript 3...

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.

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

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

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

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

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.

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 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.

quick question, can anyone please tell me what font does prime use?

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

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.

typecheckers are basically always compile-time

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.

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.

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++.

this reminds me a lot of PHP Docs

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.

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.

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.

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

I used to have phpdocs hint types in Eclipse PDT. It looks pretty normal to me

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.

Waiting for the special video at 69k subs 😂🎉

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?

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

Bread

I'm right now watching videos on how to use JSDocs so I don't have to add TypeScript to JavaScript code that is already difficult to understand. 😅😢

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)

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.

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

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 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.

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.

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.

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

I vastly prefer Kakoune motions, but unfortunately everything else that's keyboard-driven uses vim bindings, so I have to keep both in mind. It can get a bit irritating.

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.

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

JSDoc with IDEA is great btw

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?

Browsers just need to read TS natively, just ignoring the types

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.).

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.

i think typescript and rust showed what types can do in a language and i think we are gonna get a new language that leverages that in a more elegant way in near future

Just do both, you should add a comment anyways explaining what a function does so you might as well add the input types and stuff

he's always going on about music but I never hear music.

Isn't Rust just a linter over machine code?

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)

I dont get it. Why typescript dont do both.

JSDoc is like lua's annotation of type right?

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

How about rescript?

Hi, Prime

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.

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.

I try it every year and it doesn't work enough for me yet :) but I agree, the best use case is shebanged scripts

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

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

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.