TS vs JSDoc | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact

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

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

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

[@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

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

[@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 :)

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

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

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

[@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

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

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

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

[@fearclan5913]

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

[@erickmoya1401]

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

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

[@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

[@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

[@bahgah]

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

[@juangiordana]

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

[@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++

[@marknefedov]

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

[@Pygmalos]

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

[@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

[@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

[@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

[@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

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

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

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

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

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

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

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

[@banwa_non]

TS is also annoying to troubleshoot

[@SantiagoRojo]

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

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

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

[@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

[@mskiptr]

typecheckers are basically always compile-time

[@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

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

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

[@WhiteDoppler]

Bread

[@ThePrimeTimeagen]

winner

[@alexeysamokhin9629]

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

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

[@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?

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

[@CapsAdmin]

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

[@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

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

[@edward8064]

The chat protesting about the music is kinda funny lol

[@begris]

This definitely has its use cases

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

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

[@jfftck]

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

[@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

[@brunoais]

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

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

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

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

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

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

[@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

[@axMf3qTI]

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

[@leonasdev]

JSDoc is like lua's annotation of type right?

[@niteshtudu6449]

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

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

[@fernandogmar]

How about rescript?

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

[@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

[@marcusrehn6915]

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

[@RandomGeometryDashStuff]

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

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

[@felipedidio4698]

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

[@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

[@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

[@mycarrysun]

You're lumping typescript in with all the webpack bundling shenanigans - or gulp from the old days - that are the real problem. Typescript transpilation is insanely easy to do. It's webpack that causes headaches.

[@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

[@kubre]

I dont like typing name twice

[@ThePrimeTimeagen]

i can buy that

[@adamwarvergeben]

JSDoc with IDEA is great btw

[@RoyaltyInTraining.]

When you gotta start putting essential functionality into comments, the language should just be put out of it's misery.

[@AlLiberali]

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

I have worked with javascript for 14+ years and 2-3 out of those years where with TS (b/c i was forced to at work), and i never grew fund of it. really didn't like it at all. hate compiling that don't always work as it should. sometimes it generates complete garbage output. like it used to convert dynamic `import()` into require calls even tough classic script or cjs it could use import() anywhere. import('x') was converted into __importStar(require('x') for instance and i don't agree with you on that typescript syntax is easier to read. i honestly think typescript syntax is "noisier" to read. all the arguments in stringsStringStrings(p1: string, ...) becomes so very "buried" and it's harder to know what arguments you have to work with. (p1, p2, p3, p4) is imo cleaner to read and it's easier for someone who only knows javascript to make changes rather than having to learn both typescript and javascript code And to learn more about the arguments then you just have to read the jsdoc, and i also agree with what Rich mention about writing jsdoc is that you also tends to document what your code actually dose by describing what things actually are and what they do. i don't find that to be the case in **most** TS project i have encounter in open source project. Most often they only type their stuff but you don't know what it dose cuz they tend to never write any jsdoc in their TS project b/c "I don't need them"- mindset Honestly use typescript in all my projects but i don't do any typescript syntax, only vanilla JS + JSdoc and i get the runs anywhere instantly wherever i past in my code. and i have learned to write code in such a way that you don't need to annotate your code with either TS syntax or JSDoc over the years, you learn some tricks along the way that works alright in both scenarios.

[@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

[@danser_theplayer01]

I just tried out jsdoc and I'm loving and hating it. I hate it because I'm new and barely understand what I need to type for it to show what I'm trying to say. And I love it because it builds an entire documentation site for my goofy ahh code.

[@unconv]

Hot take: PHP 8.2 + PHPStan = basically Rust

[@jonathancrowder3424]

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

[@rashshawn779]

I dont get it. Why typescript dont do both.

[@adambickford8720]

Isn't Rust just a linter over machine code?

[@Xerofull]

this reminds me a lot of PHP Docs

[@vivsh.1999]

The editor poll was very biased, knowing what you like and what you expect.

[@travishafsaas8309]

It can be bad always be shure.

[@tamtrinh3154]

i like vanila js, with a little bit of jquery maybe

[@tamtrinh3154]

9:00 a lot code bases are not "large"

[@tamtrinh3154]

too many tool is one of today's problems, because most problems we faces are just really simple which can be handled perfectly well with our bare hand, no tool needed, and to add to the problem, tool makers bombarded us with ads and constantly brag how "awesome" (stupid) their tools are

[@tamtrinh3154]

only use typescript when you're bored and have nothing else important to do!

[@Hmmmmmmmm320]

9:22 this this this. I’ve hated types for this very reason especially while using React. It’s ugly af and youre having to transpile jsx and ts into js which is weird

[@JLarky]

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

[@felipedidio4698]

I hate VSCode, I can feel the website limitations all the time.