Remix.run Logo
cyberax 4 hours ago

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.

sroerick 8 minutes ago | parent | next [-]

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.

mdasen 2 hours ago | parent | prev | next [-]

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.

throw-the-towel 4 hours ago | parent | prev [-]

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

socalgal2 3 hours ago | parent [-]

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.

tcfhgj 27 minutes ago | parent | next [-]

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

cyberax 2 hours ago | parent | prev [-]

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 2 hours ago | parent [-]

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.