5 ms·

I went down this Rust front end route with my trivia web app [0], but ended up abandoning it. There were just too many points of friction. * The tooling is no

I went down this Rust front end route with my trivia web app [0], but ended up abandoning it. There were just too many points of friction. * The tooling is not nearly as good as JavaScript for the front end. * Every time you want to use a front end library, you have to figure it out yourself as there won’t be any documentation for how to use it with your framework. * Rust compile times really break your flow when working on front end code. At least for me, for front end coding, there is a lot of interactive development where you look at the web app on desktop/mobile and adjust element size/spacing etc to make sure things look nice. Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. * For front-end code, Rust’s borrow checker really gets in the way. The JavaScript garbage collector works really well front front-end code. Rust’s borrow checker is not bringing any performance advantages for this use case and brings a lot of complexity. On the backend, you can justify the complexity of Rust with appeals to efficiency/scalability/server cost. With front end code which is running on the client, you lose that justification. I ended up going with React/TailwindCSS and have been happy so far. 0. triviarex.com

aww_dang 4y ago
>Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. I'm more of a JS-lite builder. Typically I will only decorate pages with the necessary JS for interactivity. Happier using traditional SSR. Pages load with no spinner or reflow. Sometimes I inline a JSON blob for state. For the layout tweaks you describe, I typically edit the displayed page in Chrome's developer tools. Once I am satisfied I apply those changes to the template and JS. This feels more ergonomic than refreshing the page. I imagine the same technique would apply to the unified Rust front-end/back-end experience. Just edit the rendered page in developer tools. I've never been an early adopter. Let's see how this shapes out for version 1.0 or if another framework overtakes it.
- cowsandmilk 4y ago
  Hot reloading is still a widely loved feature for server side rendering. It is part of what mad PHP widely popular and many other frameworks have auto recompilation and reloading on watching changes. The smoothness of automatic recompilation falls apart the longer it takes to compile and rust is not known for fast compiles.
- satvikpendem 4y ago
  This works for smaller informational sites but not for larger web apps. I use SSR as well but through NextJS, so that I can organize my components.
- eviks 4y ago
  How is this more ergonomic vs page autorefreshes? While you lose your favorite editor tooling by moving to the browser (and then you also have to copy&paste back)
  - aww_dang 4y ago
    For layout issues, the CSS inspector helps. No need to refresh. For everything else, I just use the editor.
erlend_sh 4y ago
(Not the creator of Perseus, just a friend and fan of the project.) I tend to agree. I’ve also partaken in some Rusty frontend experiments that were discontinued. Rust is years behind on the JS ecosystem’s development velocity for frontend. That said, frameworks like NextJS are becoming incredibly complex, and Rust excels at taming complexity. We’re already seeing Rust making major inroads at the lower levels of the JS stack, e.g. Deno, swc, turbo, parcel, react-relay.., even 3.5% of the next.js repo! Not a lot of Rust folks agree with me on this because they delight in using Rust-lang as a universally applicable tool for app-making, but I think frameworks such as Perseus will reach their true potential once they incorporate JS/TS as a last-mile scripting language. Basically like a C++ engine with C#/Lua scripting for game logic.
- brundolf 4y ago
  > We’re already seeing Rust making major inroads at the lower levels of the JS stack, e.g. Deno, swc, turbo, parcel, react-relay.., even 3.5% of the next.js repo! There's a big difference between using it to write tooling, runtimes, etc. and using it to write application code (what GP was talking about). In the above examples, end users don't have to use a Rust workflow at all
owlmad03 4y ago
I wouldn't think of Rust as a language for Front-end development or similar either, I rather think of it as a systems programming language. Yes, it may be able to imitate tools like React, but not replace them. Not even in the slightest.

aww_dang 4y ago

>Doing this in real-time with JavaScript/html/css is nice. Having a Rust compile between each step is a pain. I'm more of a JS-lite builder. Typically I will only decorate pages with the necessary JS for interactivity. Happier using traditional SSR. Pages load with no spinner or reflow. Sometimes I inline a JSON blob for state. For the layout tweaks you describe, I typically edit the displayed page in Chrome's developer tools. Once I am satisfied I apply those changes to the template and JS. This feels more ergonomic than refreshing the page. I imagine the same technique would apply to the unified Rust front-end/back-end experience. Just edit the rendered page in developer tools. I've never been an early adopter. Let's see how this shapes out for version 1.0 or if another framework overtakes it.

cowsandmilk 4y ago
Hot reloading is still a widely loved feature for server side rendering. It is part of what mad PHP widely popular and many other frameworks have auto recompilation and reloading on watching changes. The smoothness of automatic recompilation falls apart the longer it takes to compile and rust is not known for fast compiles.
satvikpendem 4y ago
This works for smaller informational sites but not for larger web apps. I use SSR as well but through NextJS, so that I can organize my components.
eviks 4y ago
How is this more ergonomic vs page autorefreshes? While you lose your favorite editor tooling by moving to the browser (and then you also have to copy&paste back)
- aww_dang 4y ago
  For layout issues, the CSS inspector helps. No need to refresh. For everything else, I just use the editor.

erlend_sh 4y ago

(Not the creator of Perseus, just a friend and fan of the project.) I tend to agree. I’ve also partaken in some Rusty frontend experiments that were discontinued. Rust is years behind on the JS ecosystem’s development velocity for frontend. That said, frameworks like NextJS are becoming incredibly complex, and Rust excels at taming complexity. We’re already seeing Rust making major inroads at the lower levels of the JS stack, e.g. Deno, swc, turbo, parcel, react-relay.., even 3.5% of the next.js repo! Not a lot of Rust folks agree with me on this because they delight in using Rust-lang as a universally applicable tool for app-making, but I think frameworks such as Perseus will reach their true potential once they incorporate JS/TS as a last-mile scripting language. Basically like a C++ engine with C#/Lua scripting for game logic.

brundolf 4y ago
> We’re already seeing Rust making major inroads at the lower levels of the JS stack, e.g. Deno, swc, turbo, parcel, react-relay.., even 3.5% of the next.js repo! There's a big difference between using it to write tooling, runtimes, etc. and using it to write application code (what GP was talking about). In the above examples, end users don't have to use a Rust workflow at all

owlmad03 4y ago

I wouldn't think of Rust as a language for Front-end development or similar either, I rather think of it as a systems programming language. Yes, it may be able to imitate tools like React, but not replace them. Not even in the slightest.