It really is - writing a svelte component feels like writing something in vanilla html/js/css, but you get all the advantages that come with a framework.

This is the primary reason I love working with it. Coming from the times of jQuery, I can think in those terms like I used to and don't have to constantly translate it into React patterns.

I just can't get over the `$:` reactive label syntax.

TypeScript support can be hit or miss, and there could be more improvements around the stores API

Compared to all the weird rigamarole in other frameworks, the `$:` syntax is one of the least offensive compromises I've come across. Virtually nobody uses label syntax, the `$` is unlikely to clash with existing labels, and it means it can be easily parsed with non-specific JS AST parsers.

Haven't used Typescript much with it, though.

I am sure I am in the minority at this point, but the lack of TypeScript proliferation to me is a plus.

You're not the only one. I don't hate Typescript, but I don't think it's necessarily worth using everywhere. I like using it for libraries that I might share or reuse, that contain some complex logic, in which case it helps my code keep guarantees. But for view-layer code, I really don't get why a lot of people are dying to use Typescript that way.

Beyond that, pretty much every Typescript project I've been introduced to suffers from just as many bugs as codebases that use plain JavaScript. Strict typing at compile time doesn't replace conscientious development practices and rigorous testing.

> But for view-layer code, I really don't get why a lot of people are dying to use Typescript that way.

"view-layer code" is underselling how complex many modern webapps can get. When you've got 10+ engineers across 2+ teams running around in your 30,000+ line codebase, TypeScript offers a lot of benefits and makes overall iteration speed much much faster.

You don't need TypeScript for small/personal projects though. As long as everything fits in your memory, you're fine.

Rich and I chatted a bit about TS vs JSDoc for library authors today on the monthly dev vlog: https://www.youtube.com/live/MJHO6FSioPI?feature=share&t=95

TL;DR - Svelte's codebase will move to JSDoc types but still use TS.

To be clear - Svelte will still have full support for TS, nothing is changing for users of Svelte.

Why adopt the inferior way of declaring types?

I just don’t get the issues. TS is great, and generating good types directly from TS is easy with API extractor[0]. It makes it so easy.

The resistance to me from the community boggles me and I’m sad Rich feels this way

[0]: https://api-extractor.com/

It's not about generating types though. The reasons are laid out in the video.

Typing only eliminates a certain class of bugs. And user-defined type systems scare me. I loved ReasonML precisely because you got typing (and confident enforcement) for free through the HM type system, but TypeScript always struck me as the embodiment of "now you have two problems"

Agreed. If I'm dealing with strong static types, good inference (and TS / Rust / Whatever ain't it) is a must. ' If I'm going to invoke a bunch of ceremony every time I blink might as well write Java.

> "now you have two problems"

Interesting take. I always look at it like "now you have a better solution for your modeling needs".

Haha, yeah. I justify this decision by assuming that designer-folks wouldn't be afraid to touch the code if it were JavaScript but would it were TypeScript. :)

To me JavaScript does a great job (if you know what you are doing) and if you're working on a reasonably small project.

It almost feels like a pretty PHP in the way you can mix HTML and template code inline.