[cyberax]

Well, yep. People underappreciate the Typescript/JS ecosystem.

Typescript is pretty type-safe, and it's perfectly integrated with hot code reload, debuggers, and all the usual tools. Adding transpilation in that flow only creates friction.

That's also why things like Blazor are going nowhere. C# is nicer than Typescript, but the additional friction of WASM roundtrips just eats all the advantage.

[throw-the-towel]

IDK, I still miss Rust's strictness and exhaustive enum matching.

[socalgal2]

I don't know about what other strictness you're referring to but exhaustive enum matching is common check in most TS stacks via eslint. Yea, it's not builtin, just saying there's a solution and it's super common.

[rtpg]

The thing you gotta make sure to do is basically return inside of switch statements. Typescript will gladly propagate a type that you think is never but is actually ThatOneCaseYouForgot if it's not ever used or referred to.

Every TS project I've worked on has an assertNever(val) thing specifically to check for this kinda stuff

[cyberax]

You can actually have it built-in (via default case in 'switch' statements having a 'never()' statement). But it's less powerful than Rust's.

[nikeee]

Or you don't use the defualt case and rely on definite assignment analysis or checks for returns in every code path.

I find the never type in TS actually being a proper bottom type + having control-flow based types vastly superior to what rust offers.

[tcfhgj]

last time I researched enums in TS for a project, they were a mess such that it was better not to use enums in the first place

[ceteia]

Enum matching is one of the better aspects of Rust.

[mdasen]

I think the big thing keeping Blazor back is that C# doesn't work well with WASM. It was built at a time when JIT-optimized languages with a larger runtime were in-vogue. That's fine in a lot of cases, but it means that C# isn't well suited for shipping a small amount of code over the wire to browsers. A Blazor payload is going to end up being over 4MB. If you use ahead of time compilation, that can balloon to 3x more. The fact that C# offers internal pointers makes it incompatible with the current WASM GC implementation.

Blazor performance is around 3x slower than React, it'll use 15-20x more RAM, and it's 20x larger over the wire. I think if Blazor could match React performance, it'd be quite popular. As it stands, it's hard to seriously consider it for something where users have other options.

Microsoft has been working to make C#/.NET better for AOT compilation, but it's tough. Java has been going through this too. I don't really know what state it's at, but (for example) when you have a lot of libraries doing runtime code generation, that's fine when you have a JIT compiler running the program. Any new code generated at runtime can be run and optimized like any other code that it's running.

People do underappreciate the JS/TS ecosystem, but I think there are other reasons holding back stuff running on WASM. With Blazor, performance, memory usage, and payload size are big issues. With Flutter and Compose Multiplatform, neither is giving you a normal HTML page and instead just renders onto a canvas. With Rust, projects like Dioxus are small and relatively new. And before WASM GC and the shared heap, there was always more overhead for anything doing DOM stuff. WASM GC is also pretty new - it's only been a little over a year since all the major browsers supported it. We're really in the infancy of other languages in the browser.

[sroerick]

I feel like it was less than a year ago that Typescript was basically the only game in town and if you liked anything else you were a loon.

I have been an anti Typescript guy for a long time but I wouldn't deny for a moment that it's probably by far the most mature ecosystem.

[pjmlp]

WASM is a solution looking for a problem that most people don't care.

ASP.NET MVC alongside JS/TS frameworks does the job just fine, as does Spring, Quarkus and co.