4 ms·

The only sure cure for the JavaScript blues is WebAssembly. Use something like Leptos and be happy: https://www.leptos.dev/ https://www.leptos.dev/

Rohansi 2y ago
The treadmill continues.
- peutetre 2y ago
  Well, it's more like graduating from a kid's tricycle to a mountain bike. Sure the tricycle had streamers on the handlebars and the little basket on the front was cute, but you can get more places with a mountain bike.
pier25 2y ago
Leptos is even worse than React in memory consumption and startup metrics. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- peutetre 2y ago
  But faster overall, one code base front and back, and it will only improve as new WebAssembly features roll out (js-string-builtins, Memory64, eventually component model DOM access). And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation https://nuenki.app/blog/bloom_filters_optimisation
  - pier25 2y ago
    > But faster overall Only in further updates to the DOM. There are very few use cases where you need to continually update thousands of DOM elements. For most use cases, start up time and memory usage are really the most important metric.
incrudible 2y ago
WebAssembly can't do anything without Javascript. You're still using the same annoying Web APIs with another layer of indirection between. Plus, now you're using the slow Rust compiler so your iteration times are going to suffer. We already have type-safety in Typescript. We don't have to care about lifetimes, either.
- palmfacehn 2y ago
  Agree that WASM cannot yet directly manipulate the DOM. But are build times in JS/TS framework world any slower than Rust compile times? I'm not convinced on this point. As a disclaimer, I still prefer vanilla JS and progressive enhancement.
  - incrudible 2y ago
    TS is very fast with esbuild and the likes, it's basically just stripping off the type annotations. Your setup may vary, of course. The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
- peutetre 2y ago
  > WebAssembly can't do anything without Javascript. But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.

Rohansi 2y ago

The treadmill continues.

peutetre 2y ago
Well, it's more like graduating from a kid's tricycle to a mountain bike. Sure the tricycle had streamers on the handlebars and the little basket on the front was cute, but you can get more places with a mountain bike.

pier25 2y ago

Leptos is even worse than React in memory consumption and startup metrics. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

peutetre 2y ago
But faster overall, one code base front and back, and it will only improve as new WebAssembly features roll out (js-string-builtins, Memory64, eventually component model DOM access). And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation https://nuenki.app/blog/bloom_filters_optimisation
- pier25 2y ago
  > But faster overall Only in further updates to the DOM. There are very few use cases where you need to continually update thousands of DOM elements. For most use cases, start up time and memory usage are really the most important metric.

incrudible 2y ago

WebAssembly can't do anything without Javascript. You're still using the same annoying Web APIs with another layer of indirection between. Plus, now you're using the slow Rust compiler so your iteration times are going to suffer. We already have type-safety in Typescript. We don't have to care about lifetimes, either.

palmfacehn 2y ago
Agree that WASM cannot yet directly manipulate the DOM. But are build times in JS/TS framework world any slower than Rust compile times? I'm not convinced on this point. As a disclaimer, I still prefer vanilla JS and progressive enhancement.
- incrudible 2y ago
  TS is very fast with esbuild and the likes, it's basically just stripping off the type annotations. Your setup may vary, of course. The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
peutetre 2y ago
> WebAssembly can't do anything without Javascript. But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.