Svelte Broke Up With TypeScript??!
ฝัง
- เผยแพร่เมื่อ 21 พ.ค. 2023
- I'm so sorry Rich.
Svelte and SvelteKit's experimentation with JSDoc as an alternative to TypeScript is really exciting and really cool
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Mir for the awesome edit 🙏 - วิทยาศาสตร์และเทคโนโลยี
I'm going to break up with my girlfriend because she adds extra steps to my life
being single is *_B L A Z I N G L Y F A S T_*
Relationship is bloat
wow. That’s rich.
@@lian1238 I always wanted to be rich
Well at least she adds a feature to output more family units.
one thing to note is that svelte is still using jsdoc with ts-compiler for typechecking instead of only using jsdoc
It's actually sort of disingenuous to say they moved away from TypeScript. They don't write in the language anymore, but they still rely on it.
@@AnthonyBullard they're very clear about that
@@AnthonyBullard It's second hand accounts saying that. Go to the original source to avoid hearing the wrong message like a game of telephone.
@@asdfasdfasdf1218 What's a game of telephone?
@@entx8491 chinese whispers
Front-end: “it’s been a year, time to replace everything”
Svelte in no way dropped TS because the JSDoc types are typechecked with TS. They only moved the TS type definitions to JSDoc comments. They did this so they could skip the compile step. This is awesome for the dev experience of library authors, because then you can debug directly on the library source in node_modules, as it is the real actual code and not some mangled compiler output junk.
You mean type definitions,not typescript
@@greendsnow the type definitions that Svelte uses in JSDoc are Typescript. They are checked with the Typescript compiler. There is no less Typescript in Svelte after this change to JSDoc.
also you have sourcemaps to get from the compiled version to your actual code @@Sammi84
I used to write js doc at google. It was the defacto way to write js with type checking. It was a huge pain and typescript changed the entire landscape and it convinced the entire google to switch from the js doc nightmare to typescript. The example you showed is not a complex typescript type imo. I would love to see the equivalent to it in js doc. Also, relying on human being to maintain types without any compiler will eventually cause the types to fall apart and no longer match the implementation. I can’t imagine this can work well for a large codebase such as svelte. We will see what they say in 6mo to a year.
I agree with you 100 percent
As Theo mentioned in his video, sveltejs/kit has already been migrated, and is only slightly smaller than sveltejs/svelte. ~51,000 vs ~64,000 lines of code after ignoring JSON and Markdown files. I think they'll be perfectly fine
From: “Annotating JavaScript for the Closure Compiler”
> The Closure Compiler can use data type information about JavaScript variables to provide enhanced optimization and warnings. «JavaScript, however, has no way to declare types.»
The Closure Compiler JSDoc dialect has completely different objectives than the TypeScript JSDoc dialect that both the Svelte and Preact Team are using.
Preact has been using JSDoc TS since late 2018 and Rich Harris started experimenting with it in early 2021. So it's unlikely that anything will change in six months to a year.
@@PeerReynders what is typescript jsdoc exactly? Theo didn’t mention anything about it other than annotating types without compiling it. The svelte blog also didn’t mention what this jsdoc looks like either. None of the announcement recently includes any implementation details, which makes the typescript community very confused
@@OscarHermoso migrating it once is painful but feasible. Working with this special jsdoc annotation for long term is a bigger problem. As I mentioned, the entire google org web applications were written in jsdoc and we were willing to spend time migrating them to typescript because we believe it will bring better productivity for the long term.
I think he should've just brought these issues as a library author to the typescript team, they probably get less feedback about this experience
Compatibility can be like a blind date for TypeScript libraries - you hope for a perfect match, but sometimes, you need a bit of tweaking and fine-tuning to make it work! I'm happy to see the change of focus here by the Svelte team!
I trust Rich and the Svelte team.
I don't, but i like to see how it goes
me too
Just more bandaids ontop of Javasscript, its a shame, don't know when this industry will wake up.
@@ninocraft1 I don't have any skin in the game, I've only just started messing with svelte but from what I've seen it's been very refreshing but only time will tell. My understanding is that is how React was at the beginning as well
@@depafrom5277 which direction do you think would be better? I understand ramming JS into every nook and cranny isn't ideal but everything is literally JS lol
JSdoc is quite similar to Elixir's Typespec. It also allows you to define parameter types and combined with Dializer your IDE will give warnings if you input the incorrect type. And elixir's compiler can be configured to treat warnings as errors so that the compilation fails if you made a mistake somewhere. So even though Elixir is dynamically typed, because it is a functional language we don't have to worry about side effects and because it is a compiled language, a lot of bugs can be discovered during compilation.
Big proponent of using JSDoc over typescript for libraries has also been wooorm, the person who started/maintains unified.js, remark, rehype, mdx, etc. If you've ever used a Markdown to HTML converter (or the other way around) in JS 99% percent sure they made it. The unified framework is really well designed and the ecosystem is huge, and all of the mainline libraries are JSDoc'd, even though they offer insanely complicated type inference.
the typescript compiler let's you generate dts file from a js file with jsdoc, this will let you have autocomplete and type safety for your library (node_modules). For some reason, jsdoc is not directly recognized from node_modules, only from a local project, so you still need to generate dts files for your library.
Man, I spent the last 2 months converting all my jsdoc js files to typescript, lol
You are a true hero Sir!
Other discussions of this topic fail to point out that the JSDoc the Svelte Team is using is the one outlined in the «TypeScript Documentation» and that the approach they are using involves authoring types in separate .d.ts files (i.e. not generated) in «TypeScript» so that the (perhaps complex) types can be imported into JS files for annotations.
Ironically JSDoc TS requires that you have a pretty solid handle on «TypeScript the Tool» in order to move to “static type checking (only) on demand”.
So the notion of "just moving to JSDoc TS and skipping TS altogether" typically doesn't work. Svelte officially started to support TS in mid 2020 and Rich Harris started experimenting with JSDoc TS in early 2021 (Preact core started back in late 2018).
The other advantage is that it gives library maintainers full control of the production JS code rather than having to rely on whatever the TS compiler spits out which makes it a lot easier to write performance aware code.
Don't worry, that's the right move. "Look ma, no build step!" is ill-advised hype
git checkout && git push -f 😆
Interesting to see why a big group off people still agree that React is here to stay... because others don't want to talk with the GF because of one step!
When I build libraries, I always just strip the types with esbuild, rather than compiling, and inside of a monorepo, so you never have to run esbuild for anything other than the package you've changed, and packages dependant on the package you've changed; even with very big codebases, it never takes more than a few milliseconds, and any code "compiled" js code you look at in the browser is identical to the ts code, just without the types.
I didn't know there was any senior devs that still considered this a problem?
If I understand correctly the Svelte team is using jsdoc annotations instead of typescript for svelte. This way they avoid the build step which makes it easier for library devs to quickly test things out.
Who does the type checking then? jsdocs is just annotations right?
Thinking about it the typescript compiler supports jsdoc so they're probably using that. So in the end they're still reliant on typescript supporting jsdoc.
They are in fact using the Typescript Language Server to enable, power, and enforce types safety.
jsdoc is great for flow - you just write code then annotate it. with TS you can easily slide into “designing hypothetically” without actually producing anything
you’re less prone to overdesign with jsdoc
I think using purely jsdoc in library code works if you are disciplined in actually defining types and I’m not sure if there’s linting for jsdoc.
I can totally see why they would move away from Typescript in library code it’s definitely challenging and not many ppl are experts in Typescript compared to JavaScript.
Hope ppl don’t get the wrong idea and start using pure jsdoc in application code cause developers would just stop defining types if there’s no mechanism to force them to define types in jsdoc.
The Svelte team have configured their project to be type checked by the Typescript language server. The result is a native typescript-level types safety guarantee. If you don't specify a type, and typescript can't infer it from context, the IDE will yell at you and surface an error just like in the typescript language.
Far too many people have an outdated idea of what developing with JSDoc is like. I can make extremely complex projects that are 100% type safe (and are required to be that way by the IDE).
1:50 yes, not only JSDoc TS, but another way is ReScript. It also solves the problem for Library devs at 5:42 since ReScript has the absolute minimum amount of type annotations and can infer more than TypeScript.
I see the advantage of not having a build step. That's why I usually start with plain JS + jsdoc when starting a project. Once it grows in size, writing types in jsdoc just is typescript, but unergonomic.
I personally don't find it hard to use TS for a library, but I get the other people don't think so.
The consumer of the library is who expect correct typings, I don't think they care on how they provide them
i still don't get why ECMAscript doesn't embrace type safety as a priority, i wish they would at least implement the type hints thing that was proposed a year ago.
If ECMAscript had built-in tools to make your code type-safe we wouldn't need to be in this mess to begin with.
While a static type system is great, working in Elixir has open my eyes to the fact how useful just a simple example and a simple doctype is
jsdoc style is basically how we did typechecking in python before type hinting was mainstream and well implemented in IDE's
This makes me think that Microsoft pushing for Typescript in the browser is not that crazy
It really isn't. Too bad TypeScript kind of sucks. I think it would be better to have an entirely different language, similar to TypeScript, but not TypeScript.
One of the reasons why I am against pushing TS is that it supports duck typing. That is quite dangerous.
Thing is that we would need an engine to run TS directly. TS is more verbose than JS, compiling it down to JS only to interpret JS is a lot of wasted potential. Types should allow the interpreter to make smarter and more performant decisions, it should not be an overhead. We would need TS virtual machine instead of JS virtual machine - but that is a hell lot of work.
@@CottidaeSEA I just want C# in the browser
@@hugodsa89 Absolutely not. Just because something has fields with the same names does not mean it is the correct item. You're introducing a whole heap of possible bugs by allowing it.
@@disinfect777 or Dart
I don't really get how these arguments apply to svelte specifically.
Good typing for libraries *can* be hard but it results in better dx for consumers of the lib, it's objectively the right thing to do if you have a decent amount of users. And I despise build steps but svelte already adds a build step so you're not really winning anything?
The most charitable take I can come up with is that he's still writing all the types but in a slightly different way (dts files and jsdoc vs inline types with ts) and if that's the case that just seems like a subjective preference on code organization
Agree, this is a really strange debate. Using jsdoc isn't going to require you to write less type annotations, it just moves them to a different part of the code. And like you say, svelte already requires a build toolchain so I'm not really sure what the win is here. If the argument was that using jsdoc makes the code more readable since the annotations aren't required to be inline, I could understand that reasoning, but "jsdoc is easier for library maintainers" is confusing. There's also a point to be made that because types using jsdoc are optional, while types using strict-mode typescript is required, using jsdoc will result in looser and more inaccurate types over time even if the original author has the best of intentions.
If Theo or Matt actually learned Rust in depth they would be flipping tables over how nonsensical TS library type annotations are these days. I hope Theo eventually learns Rust well enough to recognize the type system diff
Yes, but Rust WASM in the browser still a pain
Having control-flow-based types is something I regularly miss when writing Rust
"YOU FORGOT TO PASS THE GENERIC" - Do I understand correctly that the intent is to force the user to provide a type that extends Record (FileRouter type)? I am a bit confused as to what the point is. FileRouter is a Record - keyof Record is string, Thus adding the generic doesn't really do anything since the type of the endpoint prop type will always be string and thus it doesn't enforce the value to be part of the custom router. Maybe I am missing something here but this looks very strange :D
If the intent was to limit the endpoint to keys of the custom router which has to have values as Uploader - then instead the correct types would be:
type EndpointHelper = TRouter[keyof TRouter] extends Uploader ? keyof TRouter : never;
This would enforce that when the user provides a generic - the only valid values for endpoint are the keys of the type and the values of the type must extend Uploader.
If you want to absolutely force the user to provide the generic then the correct type for the endpoint is - EndpointHelper.
I think the example will still be displayed on hover.
If this is what the intent was, I can make a PR :)
Hmm, i've seen this in php.
I was thinking I found the love of my life sveltekit... With these news dropping, I guess I'll crawl back to next.js.
Maintaining complex object types in JSDoc is a NIGHTMARE, prone to errors, and no one updates comments after a while.
With typescript I can decide on how lenient/strict I want my type checking to be and I can enforce it with linters in the pipeline. In ts types are first class citizens, not documentation.
P.S.
I take my words back. They're still doing actual type checking with TS, and JSDoc support in VSCode got a lot better in the last couple of years. I still think this approach won't work well in application projects with lots of hands on the code base and break neck dev speeds, but for a library/package, I can see the appeal.
how make click bait content
step1: first contradict everything (put up a bold sentence that mean nothing)
step2: then explain that your thoughts are free from contradiction and you love what people are doing
Just land the "Type Annotations" proposal so everyone can be happy.
Nice choice.
Techbro discovers comments
This is like a GF dating another guy
I mainly use java, c++ on my work. We have typings (obviously) and docs (like javadoc, doxygen).
Why is it so hard to do both with typescript?
Looks like a massive W to me
PHPDoc comments is one of the things that I think makes PHP Storms code complete so good. It's nice to see something similar coming to JS.
Moving from TS to JSdoc. What’s next? Move to html forms instead of SPA? Let’ gooo 2005!
these days I using JSdoc in my proj and I love It!
wow this is crazy and insane.
you can still have jsDoc commentsusing typescript.
This is required by the linter in a legacy codebase I work in. We can't just convert it to TS + getting all the devs to learn TS isn't perceived as practical. I've grown to like it but I thought it was weird at first.
Yeah, but if you want to improve a codebase sacrifices need to be made.
I think making developers document all with JSDocs correctly is harder than learn the basics of TS.
I still need to try it, but typing with comments looks tedious
I mostly agree but it's not really my call. We have a small in-house team and some augmenting from an outside agency and feature requests are always front and center so that type of overhaul seems farfetched. I would love to be proven wrong.
Learning ts isnt that hard... you have to understand oop concept with tight static typing and as a developer it helps you more than it makes trouble, so ye... it improves the dx, autocompletions incredibly... you can have many places depending on same thing, so it makes the integrations of your project structure really depending, which can be good for avoiding errors in the future and many more.
I can say for myself that unless I'm working with a framework that supports typescript out of the box like react or svelte, I seriously can't stand setting up typescript myself. The amount of strange esm and config settings I need to configure in ts-node just to get a basic express server running in typescript is insane. I used to avoid jsdoc but now it seems I should of been using it all along
How does using JSDoc reduce the amount of work that you need to put into type annotations? You still have to describe complex types in a way that the compiler understands, still need to run contract tests to ensure that you're backwards compatible on non-major releases, and still have issues caused by your users using different versions of the node runtime \ browser \ ts compiler...
Bottom line, if you're looking forward to provide a rich typesafe library, how does using JSDoc save you any of the work rather than just using TS as is?
Damn god, front end dev move so fast that even TypeScript considered as traditional :)
Yes, absolutely ridiculous when you consider even PHP has this basic $hit built in.
@@depafrom5277 I'm considering a move towards Laravel, I'm getting tired of this dumb ass sh!t.
Wasn’t this guy on ‘To Catch a Predator’?
just started learning typescript this year because this channel, only to breakup with it 😥
One thing i want to know about the concern of speration of types which typescript give us but not the js docs give as far as i know
Is there a good guide to jsdoc? I've found it to be infuriatingly difficult to use for anything that's not completely flat.
Yes, as a junior dev I need a resource to learn JSDoc as well!
Why is having a build step so bad?
Time, especially on big projects and companies
type definition mapping/source line mapping
@@whoknows3679 But isn't compiling a build step? I don't see C++, Go or Rust developers mad about that
(It's not unless you only know how to use starter templates and paas)
@@neociber24 I am a developing with Rust and C++ and compiling is probably the worst part of this experience.
With Sveltekit however it has never been a problem. It's hot reload is fast enough for me.
I hear Go has such quick compile times and it plays in a similar league.
I use TypeScript with everything. For my own projects, I use standard TS files, but in projects in which plain JS is used instead, I always make it a point to use JSDoc and TS definition files so that I can still use it without installing it as a dependency and without imposing it on the other devs (although I really think everyone should move away from JS)
I realize I'm in the minority here, but I mostly hate TS. The gap between "what should be" and "what is", at least in some projects, is just too great. Plus the insane overhead to use TS is just not worth it. And I know I sound like the luddite old man, especially in this crowd. Just thought I'd drop this here to remind folks that not everyone sees TS (or typed languages) as the only possible way to program well.
I sometimes feel like the goal of TS is to make a language that can be compiled through a single `code.replace(/stuff/g, "")` call with the appropriate regex (not counting some polyfill stuff, but you can just use Babel for that). Like let's look at Kotlin, it's basically Java for the modern person, it adds delegates, various class types, etc. while TS doesn't even give you operator overloading or proper function overloading syntax.
I really like the type system, but it really could've been more and if it was, we wouldn't even have this argument.
If Typescript had been "more", it would be like CoffeeScript, abandoned and forgotten, or Dart, a zombie forced to live a sad life. The entire reason why it dominates the industry is precisely the fact that it doesn't add much on top of javascript.
@@CengalLut Sorry but I do not see your point, IMO TS dominates because it's just an extension to JavaScript, you can write typescript or write code using typescript without knowing any of the extra syntax, you could add extra features on top of what we already have without disturbing this I think.
Btw, dart's a cool language, I wish people used it outside flutter.
Looking at the part in 3:50 makes me think that I made the right choice in ditching Typescript + React, and instead picking Blazor for my front end development. Just what do you guys think types are?
How's Blazor going? I've got a Razor pages app and thinking of adding some Blazor pages.
@@georgebeierberkeley It is pretty good. I'd like to say more, but the filters are eating my replies. TH-cam comments aren't a good place to have a conversation.
I was using a lot of jsdoc before switching to TypeScript, believe me when I say TypeScript is better than jsdoc
@विकास sadly that won't happen, it was going to be real in the 90s but it didn't
Man, on twitter you seem intimidating, but watching you on TH-cam, barely making eye contact with the camera, I find you cute, in a loving way!
How about sharing and extending types and interfaces in jsdoc? Do you have to change types on multiple locations when a implementation changes in jsdoc?
Angular 2 moment?
What vscode theme are you using? It's really neat
Finally we got rid of annotations in PHP with 8.0 and now we're getting them in JS. As a principal I hate that our comments are being parsed into code. While I understand the reasons why I don't like it and never will.
And as a Java/Kotlin dev I'm just thinking... wtf is wrong with the JS world??
Hi, correction: the first and only early adopter of typescript was Angular ( v2+).
Other frameworks / libs just few years later that start to support ts.
Vue and react didnt support at early days.
Svelter 3 was was release only support js, and even the creator of svelte at the time said something like:
i dont like ts but since ts is starting to be adopted in other frameworks we will supported in the future.
So after Angular, was AureliaJS, and many years later, i think was vue that start to support ts and then if not at the same time react and svelte start to support ts.
And the rise of the ts is thanks to Angular (v2+), which was a bold move at the time.
And to be honest, frameworks / libs like react, vue and svelte dont need ts, they are jus over complicate and js is just fine. In other hand frameworks like Angular, AureliasJS, emberJS make sense and maybe too nextjs, nuxtjs, etc.
Like you show, no need to install ts, just use the comment "ts-check" with js docs comments and you are good to go.
The only reason "ts-check" works is because your IDE ships with a built-in version of tsc. Also hard disagree on the need for typescript in react. Would you rather maintain a large legacy react app, written by developers of varying degrees of competency who are no longer available for questioning, written in typescript or vanilla JS? I know which I would choose.
@@parkerault2607 this why i like vs code. i would not use react in first place.
In react you have propTypes. in case of react ( with jsx) and svelte you will need a build step anyway,so if fine to typescript,
In case of vue you can use it without a build. so no need ts no need build step.
Love JSDoc.
Maybe for those who build libraries,but I don’t get why do people think this is more readable than TS. If you need more details just add comment on top of your declaration and your IDE should be able to show them (At least Jetbrsins IDEs do).
Well transpiling TS with Vite is not heavy anymore.
JSDoc looks good. Curious to see if it supports all TS features including TS 5.0 features.
My concerns are more about people coming from a React + TS background for example trying to learn Svelte. Is it changing the learning curve ?
What if all frameworks are handling type safety their own way ? Won't it create a huge mess in the JS ecosystem instead of harmonizing everything ?
We know the jokes about a JS framework being created everyday and this may be something which will not encourage people to start working in the JS ecosystem.
I've been maintaining a project using vanilla js with jsdoc for typechecking. The lack of a build step has been a huge plus. I'm still really looking forward to the JS proposal to have type-hints treated as comments to have that slightly cleaner syntax.
It will never pass stage 1, because it's a huge burden on browser vendors with runtime cost. And even if it does reach stage 3, it will just end up the same as HTML Document Outline Algorithm.
Javascript developers discover documentation, lol
Imagine documenting dynamic types
More like javascript developers refuse to sit still long enough to set and forget a sensible build config, then blame the existence of a build step instead of churn
It's funny, they're rediscovering everything they've shunned.
A well written documentation with types would solve all these library usage issues. But hey it’s easy to blame typescript. This issue is so made up.
👍
So instead the efford being done once at the libary, now the effort must be don't a million times at the application. Very bad.
Does no it just tell us that typescript type system is a mess? And somehow typescript devs should make it less obscure
main reason I hate svelte/vue etc. - these are own files - this is non-standard, my tools start to work incorrectly
Well, JSDoc + TS because why not 🤷🏽♂
Why are people relating Svelte and Turbo 8 as if they were the same thing?
Idk. Seems like building types with jsdocs seems a bit complex.
What?!?!???
King Rich 🤴🤴🤴🐺🐺
I still can't move away from the luxury of giving a npm react component a property with a custom type. And effects the other properties accordingly
I just hope that the typescript team improve somehow in the readability and ease of use with typescript.
It would be cool if they improve in the conditional types not by breaking its funtionality.
But by using a new syntax for the new implementation that is for simpler users to just conditionalize if this type then then return that.
Or it should distinguish between input types and output or rather static types. Which are the types that produce the error if you try to change them but without static. It will try to look for conditions
why the heck this causes outrages in the js community
I can't even count advantages of having ts + jsdoc over just jsdoc. And a person who denies this is either stupid or paid.
React and other libraries don't steal jsdoc, it's just so rare cases when it's needed when you have ts.
I'm a react + always typescript dev and just looking at svelte, but I don't want to use any tool without ts.
If typescript is so good for us developers but this is the result (Hacking types, lying to typescript, and then also having to right JSDocs intertwined with typescript) why do we all use it. Why cant we just propose types be added to a future version of ECMAScript?
Or a base set of types that we can extend and make generics with?
ES 4 ? the missing version :(
Type hinting is already in php.
@@ea_naseer php isn't a language that used by browser, to update php you need to update it on a server, but you can't update a browser on all machines in the world, that's the main point i think.
This is why these people are laughingstocks. Obsessed over the choice of people ditching typescript lol
Why not to invest more on making type checking better? Hire an expert or TS wizard. Is it not a smell that the types are not possible to be set correctly. In many cases you can use `any` if you can't figure the typing. I don't know, I feel off about this change... However, I do see the huge benefit of developing without types or with a more lightweight approach, let's see how this one plays out
Generics in a JSX component?!? What kind of witchcraft is this?
If there is an advantage beyond not having to have a build step, I'm not seeing it in this video. Defining types in typescript isn't so bad and, syntax-wise, it's more localized to the things you're typing than with jsdoc. I would absolutely hate to be defining types in jsdoc in one place (lib code) and typescript in another (app code), and pure dx-wise, I'd much rather write typescript. I also fail to see the issue with writing a doc block comment above a function if I want more than just a type signature to show up on hover and continue to place types next to the symbols they go with.
I agree. There are actually a few serious disadvantages:
- for complex types you still need typescript and import types (probably from a .d.ts file), because jsdoc is just not powerful enough, and the syntax of @typedef for complex types is awful.
- support in IDEs (try to get the same level of type-checking) and tooling in general. Global renames are gone, etc.
- readability.
In my experience jsdoc is extremely awkward to work with, so there would have to be a hell of an incentive to go through the hurdle of parsing and maintaining code like this:
/*
* @template T
* @param {import('myTypeIsHere.d.ts').myType} [ahItsOptionalInThisCase]
*/
function myFunction(ahItsOptionalInThisCase) {...}
Kind of a snarky comment from my side, but I think at its core there is some truth: I kind of love how the JS-world seems to insist on recreating history wrt the toolchain and language constructs that other languages settled on standards for a long time ago. JSDoc is just doxygen, right? Maybe a dialect, but well, come on JavaScript! Adopt the well-proven standards already! Otherwise, I am scared: We already have JavaScript on MicroControllers for some reason, and you will likely end up building your own virtualization hypervisors with JavaScript or inject JavaScript code into the Linux kernel somehow!
Nah
Sorry, but I can't see how writing typehints in a comment is better than in the code itself.
Love Rich's work and I even enjoyed every hot take in the latest talk... but this ain't it. You disprove one of his main arguments in this video.
I think it's reasonable to use `as any` every now and then when working in a library. It doesn't feel good, because it shouldn't feel good. To be such a perfectionist that you'd rather have an inferior & verbose syntax is such a mistake. But as for having to write a lot of types as a library dev... yeah, that's what it's all about. You want to make the most easily consumable solution, so you write very good types. They're not getting out of that here. And as for getting rid of builds... I just can't imagine caring now that most new apps are just using no-check type erasure at dev time and only actually validate the code at build time.
The response to these items of just going opposite direction of type safety is a wild anti-correction to avoid actually solving any problems.
As an addendum: I really feel that Microsoft's push to have TS type annotation syntax be valid and non operable in true JavaScript was stupid. Now I feel like it might be the only solution to protect the future of TypeScript.
You look tired. Great video though
I was looking into svelte to use in a project... This is a complete deal breaker.
hello
Use tsup for libraries and stop making a scene of a non issue
i don't understand. Please let jsdoc not be the next think.
The thing I hate in TS is that you have to implement large types with omit, pick, exculde and etc. There's no prebuilt features for that. You are on your own with it. You have to experiment a ton on it. Why I can't just map and get readonly keys? Why I have to write so much code that's even not documented and experiment a lot? TS is generally god, but if you have a complex requirements for type-safety, you'll have to write types just like its a business logic. Weird.
@Scott Page USMC Dude, I know TS at advanced level. I'm speaking about DX.
This dude is a f$&@king genius!!!! 😊
And that’s why typescript is not a real type system and sucks
This ain't it chief.
JavaScript is the new PHP
Js docs are better
Hot take:
Comments should ONLY be used to comment code. If you are using comments for anything else than that, then there's something wrong with your code/library/platform/language.
I could be wrong but I think a lot of languages use comments for docs in a similar way
bad take
@@Omar-ld9gy They are also wrong.
@@EusebioResende I think it's fine for docs, kinda like what Go does.
There is different between /// XYZ or /// abc (C# code example) and //do something - one of them are being used by IDE and enable you to generate doc from them second on are garbage in 95% of cases