Svelte Broke Up With TypeScript??! 

I'm going to break up with my girlfriend because she adds extra steps to my life

one thing to note is that svelte is still using jsdoc with ts-compiler for typechecking instead of only using jsdoc

Front-end: “it’s been a year, time to replace everything”

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.

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.

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.

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 think he should've just brought these issues as a library author to the typescript team, they probably get less feedback about this experience

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.

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.

I trust Rich and the Svelte team.

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!

Man, I spent the last 2 months converting all my jsdoc js files to typescript, lol

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.

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.

jsdoc style is basically how we did typechecking in python before type hinting was mainstream and well implemented in IDE's

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?

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

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

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?

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.

Is there a good guide to jsdoc? I've found it to be infuriatingly difficult to use for anything that's not completely flat.

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

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

What vscode theme are you using? It's really neat

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

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.

these days I using JSdoc in my proj and I love It!

Wasn’t this guy on ‘To Catch a Predator’?

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?

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.

wow this is crazy and insane.

Looks like a massive W to me

Nice choice.

Hmm, i've seen this in php.

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

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

Why is having a build step so bad?

Moving from TS to JSdoc. What’s next? Move to html forms instead of SPA? Let’ gooo 2005!

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.

This makes me think that Microsoft pushing for Typescript in the browser is not that crazy

you can still have jsDoc commentsusing typescript.

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

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?

Techbro discovers comments

I was using a lot of jsdoc before switching to TypeScript, believe me when I say TypeScript is better than jsdoc

just started learning typescript this year because this channel, only to breakup with it 😥

Just land the "Type Annotations" proposal so everyone can be happy.

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)

This is like a GF dating another guy

Man, on twitter you seem intimidating, but watching you on RU-vid, barely making eye contact with the camera, I find you cute, in a loving way!

Angular 2 moment?

👍

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.

Why are people relating Svelte and Turbo 8 as if they were the same thing?

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.

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.

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.

Idk. Seems like building types with jsdocs seems a bit complex.

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

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.

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.

Damn god, front end dev move so fast that even TypeScript considered as traditional :)

And as a Java/Kotlin dev I'm just thinking... wtf is wrong with the JS world??

What?!?!???

This type of clickbait is really annoying. Almost all of your videos advertise something completely different with their thumbnails and titles. The content of the video has absolutely nothing to do with why i clicked on the video. You doing this every time is really annoying and frustrating

Well, JSDoc + TS because why not 🤷🏽‍♂

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.

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.

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.

Javascript developers discover documentation, lol

Generics in a JSX component?!? What kind of witchcraft is this?

Nah

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

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.

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

why the heck this causes outrages in the js community

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?

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

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!

This is why these people are laughingstocks. Obsessed over the choice of people ditching typescript lol

Wow, the amount of effort put into bandaids for Javascript to try make it work better, every month something new, try try again. Even dreaded PHP has this basics built in: protected Thing $thing or even via annotations: @var Thing $thing, @param Thing $thing etc.

King Rich 🤴🤴🤴🐺🐺

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.

hello

You look tired. Great video though

i don't understand. Please let jsdoc not be the next think.

I was looking into svelte to use in a project... This is a complete deal breaker.

Use tsup for libraries and stop making a scene of a non issue

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.

And that’s why typescript is not a real type system and sucks

This dude is a f$&@king genius!!!! 😊

This ain't it chief.

JavaScript is the new PHP