4 ms·

As someone who writes exclusively Rust on the backend and React on the frontend... To me React is a "language", not the technique of the "tree-diffing". And I

by loxs 4y ago

As someone who writes exclusively Rust on the backend and React on the frontend... To me React is a "language", not the technique of the "tree-diffing". And I think it's the best one there is for expressing an UI. The tree-diffing (and the speed deterioration) is only the (unfortunate) way to compile it to the DOM. Still worth it IMO. With Rust it can probably be done both safely and imperatively (i.e., fast) while retaining the declarative language. Haven't really thought it over fully, but so far it sounds really nice.

mikevm 4y ago
What about various libraries that don't use a virtual DOM and have vastly better performance than React, for example https://www.solidjs.com https://www.solidjs.com or Svelte?
- loxs 4y ago
  Svelte is nice, although a lot less ergonomic than React as it is not "native JS" which creates the need for "two domains" of programming - one, the Svelte domain (which is later compiled) and one JS domain which is called as a library. Haven't tried SolidJS yet. Cannot really say if Svelte is worse than React, as I have much more experience with React itself. My main blocker to adopt it (Svelte) is mostly library support - with React one can use "everything" in all kinds of "hackish" ways and with TypeScript, which wasn't really the case with Svelte last I checked, maybe 2 years ago.
  - miohtama 4y ago
    Svelte might not be internally as ergonomic as React, but the fact that it ditches “everything needs to be native JS” principle, allows one to build components with much less boilerplate. This translates to more readable code, less boilerplate and lines to type. Effectively Svelte sacrifices some of the purism principles in the favour of better developer productivity. The trick with Svelte is that “two domains” are very, very, close to each other. A JavaScript programmer can learn and understand Svelte after 2 days tutorials. Library support is something that can be improved only over time.
    - loxs 4y ago
      Yeah, I agree, but I suspect that React is still the "right" tool for 80% of the software out there (having all of these things in mind). Though I should give Svelte another go soon maybe :)

by loxs 4y ago

mikevm 4y ago

What about various libraries that don't use a virtual DOM and have vastly better performance than React, for example https://www.solidjs.com https://www.solidjs.com or Svelte?

loxs 4y ago
Svelte is nice, although a lot less ergonomic than React as it is not "native JS" which creates the need for "two domains" of programming - one, the Svelte domain (which is later compiled) and one JS domain which is called as a library. Haven't tried SolidJS yet. Cannot really say if Svelte is worse than React, as I have much more experience with React itself. My main blocker to adopt it (Svelte) is mostly library support - with React one can use "everything" in all kinds of "hackish" ways and with TypeScript, which wasn't really the case with Svelte last I checked, maybe 2 years ago.
- miohtama 4y ago
  Svelte might not be internally as ergonomic as React, but the fact that it ditches “everything needs to be native JS” principle, allows one to build components with much less boilerplate. This translates to more readable code, less boilerplate and lines to type. Effectively Svelte sacrifices some of the purism principles in the favour of better developer productivity. The trick with Svelte is that “two domains” are very, very, close to each other. A JavaScript programmer can learn and understand Svelte after 2 days tutorials. Library support is something that can be improved only over time.
  - loxs 4y ago
    Yeah, I agree, but I suspect that React is still the "right" tool for 80% of the software out there (having all of these things in mind). Though I should give Svelte another go soon maybe :)