TS vs JSDoc | Prime Reacts

[@echobucket]

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.

[@ΣτάθηςΣταθόπουλος-σ7ρ]

amen

[@DMWatchesYoutube]

I don't use JS ( No web dev sadly) but I might try it out if I could guarantee at least some speed or better debugging without having to set up so much tooling for TS

[@zaccanoy]

I think the idea is to have “types as comments” so that it’s not tied down to TypeScript in particular (i may be out of the loop though). Most importantly though is that your browser / node will ignore the type annotations (but like SOMEONE is definitely going to add typescript to their debugger right? Edge or Arc maybe)

[@jamievisker1952]

I really want this, but I’m not convinced it will ever get through

[@banatibor83]

@@zaccanoy Pyton used comments for type annotations, then in Python 3.4 they have added a proper typing package and type hints.

[@jaredsmith5826]

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.

[@smallfox8623]

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.

[@DeusGladiorum]

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.

[@ThePrimeTimeagen]

you can still have that with js docs, just .d.ts out complex types

[@elmalleable]

dude i had a work colleague i pair programmed with, he complained that ts was over his head, i made a few types, it helped us a few times to caught logic and basic typo errors. next day my bro took out all the jsdoc annotations because, i was dumb founded, like he just wanted to walk into all the errors from the day before all over again. i was going to make him a cheatsheet and make myself available to show him everything i knew but ..........

[@AttilaButurla]

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.

[@theairaccumulator7144]

Those people were taking the Java in JavaScript way too seriously

[@harem_lord-FFM]

@@theairaccumulator7144 lol😆

[@EIsenah]

So it's okay to use types "any" sometimes? In my company, I'm forbidden to use implicit return and must add types for everything.

[@ReviloYaj]

​@@EIsenah yea we can't use any unless you've exhausted all other routes, which is never. Everything has a type!

[@shableep]

my policy with typescript is to only directly annotate types when they can’t be inferred. and only use interfaces if absolutely necessary. every single character types into the codebase is a new part that has to be maintained. so reduce as many parts as possible. the goal of types is to make the use of your code to others and your future self so obvious that you couldn’t possibly use the modules you create incorrectly. it’s about creating an amazing developer experience for yourself in the future. which means awesome autocomplete and minimum maintenance.

[@vitiok78]

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

[@ThePrimeTimeagen]

this is what i am very curious about

[@idkidk9204]

I do agree, as someone who MUST have a statically typed language but had to write in JS I found jetbrains implementation a life saver

[@SimonBuchanNz]

​@@ThePrimeTimeagen I've found Jetbrains' stuff to be really cool but the raw quality to be all over the place. I strongly recommend it for the price, but be aware you're gonna have bugs and random performance. I blame the JVM. (Can't blame Java since they created Kotlin to avoid it)

[@jeremiedubuis5058]

@@ThePrimeTimeagen I mostly use jetbrains refactoring for renaming, it also works with stuff like React's state hooks (rename the state it will also rename the setter), rename a class it will ask if you wish to rename the file)... In my es modules projects it usually gets everything right, in my commonjs projects it oftens misses some references, I don't know if I can make a direct link to typescript vs jsdoc, I would bet on it just being better at interpreting es modules dependency graphs.

[@zaccanoy]

I don’t have any random issues with Jetbrains products anymore, idk if they’re more stable or if I’m just working in things that they’ve built the most for (server-side, mobile, and web Kotlin, React/TypeScript). I do want to note that I spend as much time as possible in IntelliJ, as android studio and webstorm feel kinda dated and don’t have the complete feature set. The kotlin and typescript inspections and refactoring are magical, we’ve likely eliminated entire classes of bugs in some of our products with it (unit testing could also find most of these tbh, but our company relies more on tooling and post-dev QA)

[@richardcesar5546]

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)

[@billy818]

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

[@ThePrimeTimeagen]

my man

[@FoodFoodMoney]

My man

[@davidem3283]

Your man

[@jaroslavhuss7813]

your man

[@Slashx92]

my man

[@nathanfranck5822]

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!

[@fennecbesixdouze1794]

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.

[@MaryTheTankGirl]

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.

[@Sergeeeek]

That's JavaScript for ya. Though I'm sure v8 and other engines have some crazy optimizations for single char strings.

[@robertluong3024]

Keep going. It's important to open your mind to other languages and things. Even if they horrify you :)

[@abdelazizmokhnache766]

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.

[@elmalleable]

its cool till you have to import then you see something like function someFunction( /** @type { import('../../../../.../fromTheRoadLeastTravel').SomeVarLeastUsed} a) { ....} but jsdoc is amazing for old js projects

[@abdelazizmokhnache766]

You can import that on the top of the file and assign it to a new type using @typedef, then use that type name elsewhere in the file. It doesn't need to be that ugly. ex: /** @typedef { import('../../../../.../Types').SomeType} SomeType*/ down in the file /** @type {(a: string) => SomeType} function doSomething(a) {...}

[@elmalleable]

@@abdelazizmokhnache766 i like this. Amazing

[@kiwik2945]

​@@abdelazizmokhnache766 you can also import it like this : import * as T from ../../../../.../types /** @typedef { T.SomeType} SomeType */

[@thewalrusdragon9579]

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.

[@pseudoc]

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.

[@moodynoob]

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.

[@elmalleable]

a tool that helps you avoid small gotchas is a good too any bloody day but to each their headache

[@TinBryn]

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

[@raphaeld9270]

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.

[@crashingflamingo3028]

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.

[@DesTr069]

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

[@fearclan5913]

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

[@rban123]

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

[@rban123]

This also comes with the downside of needing a transpilation step, but it does more strictly enforce the static type analysis

[@erickmoya1401]

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

[@cloudpuncher4615]

Just bring back ActionScript 3...

[@dragenn]

Back when programming was fun as hell!!

[@Caboose2563]

Heresy

[@ayangd1436]

Bro we got WebAssembly now.

[@cloudpuncher4615]

​@@ayangd1436 But who wants to learn Rust or C++.....

[@crides0]

@@cloudpuncher4615 just Google.. of course you don't have to write rust/c/c++

[@BlazeShomida]

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

[@marknefedov]

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

[@VudrokWolf]

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.

[@Ihsnetad]

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.

[@petrmotejlek1427]

Re the two codebases problem. I even find myself sometimes reusing some patterns when writing types. So, it's really a big issue that you have to think in two worlds all the time. There is the runtime (JS world) and the static (typing world).

[@zebraforceone]

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.

[@neociber24]

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.

[@NathanHedglin]

Weaker devs get slowed down because they barely understand code

[@SemiMono]

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.

[@zactron1997]

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.

[@ThePrimeTimeagen]

real tlak

[@edward8064]

The chat protesting about the music is kinda funny lol

[@complexity5545]

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.

[@zirize]

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.

[@Slashx92]

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

[@stbuchok]

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.

[@bahgah]

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

[@arcanernz]

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.

[@exegeteio]

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.

[@lcarv20]

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

[@0marble8]

it got transpiled out of the video

[@nescafezos4265]

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

[@Pygmalos]

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

[@Davidlavieri]

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)

[@harem_lord-FFM]

TS is also annoying to troubleshoot

[@pierreollivier1]

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.

[@3ventic]

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.

[@AllanSavolainen]

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?

[@senge1337]

Yup, literally would be a build step from JSDoc to TypeScripr

[@JakeJJKs]

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.

[@KnThSelf2ThSelfBTrue]

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?

[@ichizos9615]

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.

[@AScribblingTurtle]

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

[@hfspace]

well, the thing people are questioning is not about moving to jsdoc but rather replacing typescript with jsdoc, since typescript allows for more type security than jsdoc but at a cost of more transpilation hassle

[@AScribblingTurtle]

@@hfspace My problem with TS is honestly, that it is at times to "strict" and confusing. Here is a problem I encountered recently. " if(document.setAppBadge) ... " TS did not stop yelling at me, that "setAppBadge does not exist in Document". Even though the whole point of this damn line is to check if the damn thing exists in the first place. How am I supposed to check if something exists, If TS yells at me, that the check is checking a property that possibly does not exist?

[@hfspace]

@@AScribblingTurtle for that problem you normally should be able to implement a type guard that checks for the inclusion of this method and then the type checker should be able to realize that your code is fine. Just google typeguard + ts, you'll find it

[@TimothyWhiteheadzm]

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.

[@juangiordana]

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

[@koloml2]

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.

[@SantiagoRojo]

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

[@drekforder2952]

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.

[@marcomonsanto]

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

[@JeSus-hl6zj]

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.

[@mskiptr]

typecheckers are basically always compile-time

[@BosonCollider]

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.

[@Sergeeeek]

You still know exactly what JavaScript you write with type script. Except for some features like enums, all the type annotations get erased.

[@LongJourneys]

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.

[@cbaesemanai]

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.

[@alpsavasdev]

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?

[@davidlanda2324]

This is a strategy what Go programmers follow. I thing you are right.

[@ramtinabadi]

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

[@rafinha-1112]

This definitely has its use cases

[@nerdError0XF]

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

[@elmalleable]

there is a skill using typscript in a lazy way by putting it in the right places to get the most effect without typing everything everywhere

[@Oskar1000]

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?

[@alexeysamokhin9629]

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

[@karixening]

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

[@MaxHaydenChiz]

In a language with a real type checker, the types do a sort of "worst case" approximation of what your code could do and thus rule out a lot of behavior as a result. The semantics of the language will depend on this and compilers will use that information when making decisions about how to put your code into effect. I don't use TypeScript, but I don't recall hearing about it using the type information to do an optimization pass. So it's more like a very thorough linter that uses a lot of the same constraint logic that a type checker would.

[@karixening]

@@MaxHaydenChiz No optimization pass makes sense. TypeScript does often feel more like a linter at times since its built on top of and not into the language, but it ends up being the same developer experience imo, so it's a fine line.

[@dimaorols8143]

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.

[@ssshenkie]

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

[@ThePrimeTimeagen]

react / reading stuff lands here coding lands on @TheVimeagen

[@wwjdtd1]

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

[@joshuacooks]

Deno still converts to javascript that runs on the V8 engine under the hood, no? google says yes, that is what it does. has that changed?

[@wwjdtd1]

@@joshuacooks yes it does, but that doesn't change the fact that you can run TS scripts without needing to manually transpire before running. Whereas node needs said extra step.

[@adambright5416]

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

[@o_corisco]

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.

[@allalphazerobeta8643]

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.

[@joshuacooks]

VSCode has excellent syntax highlighting and copiolot can write most the JSDoc type definition for you, letting you just tweak the details. It provides warnings and all they typescript tooling features 1:1

[@niteshtudu6449]

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

[@SeRoShadow]

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.

[@jfftck]

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

[@adamtillou2689]

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

[@ThePrimeTimeagen]

inlay hints is what that is called i think tsserver has to implement that

[@jorgerojas4402]

@@ThePrimeTimeagen i think tsserver already support inlay hints, but i may be wrong.

[@MrOnePieceRuffy]

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)

[@raiguard]

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.

[@felipedidio4698]

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

[@thomassynths]

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.

[@elmalleable]

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

[@RandomGeometryDashStuff]

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

[@yeahaddigirl]

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

[@MaxHaydenChiz]

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.

[@richardflosi]

Type-enhanced is the new web-scale

[@marcusrehn6915]

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

[@Tony-dp1rl]

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.

[@anon-fz2bo]

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

[@khai96x]

Go provides the facade of simplicity. Rust exposes complexity. String types is one such example.

[@nomadshiba]

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

[@AlLiberali]

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

[@quintencabo]

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

[@BigEyesLuigi1]

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

[@BenRangel]

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.

[@CapsAdmin]

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

[@Xerofull]

this reminds me a lot of PHP Docs

[@KhanFus1on]

It's really unfortunate that JS doesn't have ergonomic syntax for comments. I think not using backticks for this is a missed opportunity. Flow-style "types in comments" are a lot less verbose than JSDoc but still less than ideal.

[@brunoais]

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