trunk VS sycamore

Note that Leptos uses Trunk to serve the client side application. Trunk is a zero-config Wasm web application bundler for Rust.

I've been using Rust and WASM for my latest front-end project, and I think this setup is a viable alternative to commonly used JS frameworks for those willing to put in some effort to ramp up on new technology. Addressing the concerns from the article:

"No universal import system" - Rust has it's own module system and Cargo is used for managing dependencies, no need to worry about different module systems.

"Layers of minification, uglification, and transpilation." Just compile Rust to WASM file for the browser, same as using any other compile target.

"Wildly different environments." Something that you'll still need to deal with. Some runtime dependencies are system-specific (code running on the browser usually needs access to Web APIs, and JavaScript, code running on the server can't access WebAPIs but can access the system clock and filesystem. Sometimes separate libraries or separate runtime configs are needed (e.g. configurable time source)

"Overemphasis on file structure." Not a problem for imports, but you may still have file structure dependencies things like CSS, image resources etc.

"Configuration hell." Pretty much non-existent once you have your Rust compiler setup locally.

"Development parity." Just use trunk: https://trunkrs.dev/, to watch, build and serve, config is minimal.

Trunk, the Rust-equivalent of Webpack & Vite, comes with tailwind built-in. You heard that right! You don't even need to install the tailwind CLI via npm or something like that. No more package.json! <3

Can you not use dioxus with "trunk" (https://trunkrs.dev/) ?

Thanks a lot! As I said in an earlier comment, building this allowed me to explore a lot of features of rust like Traits, Dynamic Dispatch, Pattern Matching, Const evaluation, Static variables, etc. and that on top of that trying to figure out how to conveniently port it to WASM was also a nice learning experience. I am currently using trunk as a bundler which ties in neatly with a GitHub action but before that, I tried cargo-run-wasm, which felt a little hacky. So overall a whole lot of learning.

Here here. I don't think programmers - as a group - get to complain about people not learning programming tools while simultaneously making them so unapproachable (especially Linux things).

It's not just the overuse of acronyms. There's also:

* Religious devotion to the CLI despite it having terrible discoverability.

* Really bad naming. Git is probably the worst offender at this, but the whole of Unix is a naming mess. WTF is `usr`? Is that where user files go?

* Generally over-complicated tooling. A good example of this is Node/NPM. So complicated to set up! Contrast it with https://trunkrs.dev/

* Deification of distro packages. No I do not want to spend half of my development time packaging my app for 10 different distros. I guess I'll go with curl | bash then.

* Distain for binary app distribution. I'm looking at you glibc.

I used Notan for drawing the game board in combination with the excellent egui for adding UI elements. It was surprisingly easy to bring it to web with Trunk.

Hi, the author of MailCrab here :-) Yew is nice, especially if you enjoy writing Rust. However, it definitely takes more time and dedication than writing a frontend in React, Vue etc. Yew and the surrounding ecosystem keeps improving, and it is way more usable than when I first tried it. The tooling I used (Trunk https://trunkrs.dev/) is very minimal with respect to the number of features compared to many of the popular web-bundlers (Webpack etc.) but it works well for most simple use-cases.

Yew is way way nicer in that regard because it uses Trunk which is very excellent and you don't have to deal with any of that really. Just trunk serve and away you go. Plus you get the advantage of not having to deal with Javascript. Typescript is nice, but it's no Rust.

The alternative to wasm-pack is trunk. I've never used it, so I can't tell you how good it is.

Perseus is a fast frontend web development framework for Rust with built-in support for reactivity using Sycamore, server-side rendering, and much more. Sycamore is a frontend library that allows you to build interactive user interfaces with Rust. I’d say that Perseus is to Sycamore as Next.js is to React, so it’ll be helpful for you to have a fair understanding of Sycamore before jumping into using Perseus — although it’s not necessary to follow along in this article.

Now, I considered whether to spend more time fixing everything that now failed in sycamore 0.9. But there are major changes ahead which would require yet another major refactoring, to the point where I am not sure whether it would not be more of a rewrite than a refactoring, given my previous experiences with sycamore.

Sycamore.

Sycamore, Yew, or Seed if you want a full-stack solution. (Or Leptos if you want something that's faster but less mature.)

There are others, like Sycamore, similar story as Leptos but imo Leptos is (currently) more ergonomic.

Sycamore is a reactive library for creating web apps in Rust and WebAssembly. https://github.com/sycamore-rs/sycamore

I tried my first project with yew as frontend. And my experience was after some time similar to the already mentioned ones: It is a little more to take on than I actually wanted. And some things were not straightforward to achieve. I switched to sycamore for the other projects now and I am much more satisfied (but this could also be since I have some more experience in the Rust ecosystem by now). Changing from yew to sycamore was pretty easy and I can achieve most of the tasks with less code.

If you want to do fullstack/SPA stuff, check out Sycamore, Seed, and Yew.

If you want to do front-end SPA development, take a look at Yew, Seed, or Sycamore.

I have written a front-end (website) application in Rust that is used internally in production. I wouldn't recommend to use something like sycamore, leptos, dioxus, yew for you next puplic web-app now but i can absolutely see how this is used in the future as those libs mature.