Is leptos the right choice for the UI rewrite?

[SleeplessOne1917]

@phiresky mentioned in the maintainer chat that he has concerns about using leptos for the UI repo. While I think leptos is definitely a step up from inferno, I have my own concerns about it. To spur discussion, I'll make some pros/cons lists for leptos, solidjs with solid start (my first choice of leptos alternative), and nextjs (popular fullstack framework with many compatible libraries).

Leptos

Pros

• Lets devs make UIs in rust, an incredible and ergonomic language.
• Lightning fast
• WASM bundle for whole app sent to browser on first load, making client-side page changes very fast
• Great support for progressive enhancement and graceful degradation

Cons

• Rust's high learning curve will make it harder for many devs to contribute, especially frontend devs who are less likely to have used the language
• Very limited ecosystem; many useful libraries are maintained by only one person with few commits and seem likely to be no longer actively developed
• Documentation and other supplementary information is fairly limited
• All of the WASM being sent on first load could make first load time slower

SolidJS/Solid Start

Pros

• Performance on par with (and sometimes even better than) leptos
• Small bundle size
• Excellent tutorial
• Support for progressive enhancement/graceful degradation on par with leptos
• Semi-decent ecosystem compared to leptos
• React-like without many of react's footguns

Cons

• Relatively unused compared to other frameworks
• Solid Start is still in beta and will probably have bugs not present in other frameworks
• Ecosystem smaller than other fontend/fullstack frameworks like react, angular, and vue
• Supplementary learning materials outside of the official tutorial and docs sparse

NextJS

Pros

• Uses react, which is known by many frontend developers
• Batteries included(ish, at least compared to the other frameworks listed here).
• Very large ecosystem of compatible libraries that can be used.
• Easy to find supplementary learning materials compared to the other frameworks listed

Cons

• Uses react, with all the bloat and footguns it entails
• Support for progressive enhancement/graceful degradation lacking compared to leptos and solid start

This list was made off the top of my head from my experience working with these frameworks. I'm likely forgetting to include other useful information about them. Then, of course, there are many other frameworks to choose from (I'd say too many). I've heard svelte/sveltekit is both nice to develop with and fairly performant, although I have no first hand experience with it.

[dessalines]

Thx for writing this up, you've laid out most of the good pros / cons for each. Just to add a few more, for why I chose leptos specifically.

• Rust
  • Lemmy-ui is such a massive app, that doing a complete from-scratch rewrite in javascript would be a waste of time IMO, even if some of the newer javascript frameworks are cleaner.
• First-class SSR / isomorphic support.
  • Leptos has 4 different SSR modes out of the box.
  • We've already finished the difficult part of that in this codebase already. Most of the work now is the tedious job of building out the components.
• Tailwind support. Kind of nullifies all other CSS frameworks and strategies.
• Very active dev community.
  • The matrix space and github for leptos are really active, with a lot of people helping out with any issues.
  • I played with Sycamore / Perseus a bit at first, but found nearly all the dev activity switched to leptos.
• Signal-based reactivity
  • This is what SolidJS, jetpack-compose, and all the newer UI frameworks seem to use, but we get to use a better language.

To address some of the concerns:

Rust's high learning curve will make it harder for many devs to contribute, especially frontend devs

Its an issue, but I think a little bit overblown: devs have to learn new frameworks and languages every few weeks now. Actual devs know more than 1 language, and aren't afraid to learn new ones, especially since nearly all the concepts directly translate.

Even projects that use react don't have many devs that stick around, and the core contributors dwindle down to just a handful of people. So you might as well use the tools that the core devs are going to be happy working with, rather than catering to fly-by contributors.

ecosystem

Nothing in lemmy needs to be that complicated: people would be happy if we provided a mostly static experience like old.reddit. But there are a few typically js-powered things that I could see us having issues with, like the emojipicker, auto-complete. Those are def going to be hurdles.

I figured out that we'll be okay w/ translations tho with leptos_i18n.

WASM

There's a lot of work going on to optimize WASM for all rust web projects, and luckily none of that will affect the high-level code. The first load will be a hit no matter what, but caching and etags can make sure that we don't take that hit again until another release.

---

If I were to want to stay in the javascript ecosystem, I'd say we go with SolidJS + tailwind, but since a full rewrite is such a large undertaking, to me its not worth the effort. We might as well devote any extra energy we have to a rust rewrite, and eventually put lemmy-ui in maintenance mode.

cc @phiresky

[jim-taylor-business]

great summary @SleeplessOne1917 - Solid and Next are 2 great frameworks but i do agree with @dessalines 's analysis overal.

i would also softly challenge the "Leptos Cons":

* Rust's high learning curve will make it harder for many devs to contribute, especially frontend devs who are less likely to have used the language

i think learning Rust generally in the server/desktop environment does have a steep initial learning curve, but in the web development environment a dev will quickly recognise the similarities with JS/DOM/browser based web development and indeed the other 2 languages are the same; HTML and CSS. i think this flattens the initial curve and Leptos' ergonomics helps a lot with that compared to other Rust frameworks.

* Very limited ecosystem; many useful libraries are maintained by only one person with few commits and seem likely to be no longer actively developed

true, the ecosystem is still young

* Documentation and other supplementary information is fairly limited

not experienced this myself, what is there i have found to be as well documented as most other frameworks

* All of the WASM being sent on first load could make first load time slower

similar issue to JS bundlers and certainly similar size. this normally weighs in around several megabytes that is totally acceptable these days

[erlend-sh]

Lemmy-ui is such a massive app, that doing a complete from-scratch rewrite in javascript would be a waste of time IMO

This is a very important point. For this reason, I think it’s well worth considering an existing UI project as a new official UI, for the purpose of improving the immediate state the JS-based UI while the Rust alternative gradually develops.

I suggest the Lemmy project formally adopts Photon to replace lemmy-ui.

• already at feature-parity with lemmy-ui core.
• among the most actively developed Lemmy frontends around
• mobile & desktop friendly
• uses tailwind, for which there seems to be a preference here
• doesn’t take any energy away from lemmy-ui-leptos since Photon is a pre-existing project with its own developer(s)

I’ve talked briefly with @Xyphyn and I know they are open to exploring this possibility.

[erlend-sh]

Some separate notes on Leptos:

Very limited ecosystem; many useful libraries are maintained by only one person with few commits and seem likely to be no longer actively developed

Can say which libraries you’re referring to? Are these libraries that lemmy-ui-leptos relies on?

All of the WASM being sent on first load could make first load time slower

This has been solved by the opt-in ‘islands architecture’ of Leptos v0.5, which released today.

[gbj]

To share a semi-informed opinion (created Leptos, not very familiar with Lemmy, so consider it 50-50): I have always said that the best/only reason to use Leptos (or Sycamore or Dioxus or Yew) is that you want to write your frontend in Rust. There are no (frontend) performance benefits over something like SolidJS. (There are benefits, both in rendering performance and in load times, over React/Next!)

There is no best way to create a web app, full stop. I happen to think that Leptos is the best way to create a web app in Rust, and those last two words are pretty key.

Nothing in lemmy needs to be that complicated: people would be happy if we provided a mostly static experience like old.reddit. But there are a few typically js-powered things that I could see us having issues with, like the emojipicker, auto-complete. Those are def going to be hurdles.

@dessalines it would be worth checking out the new experimental-islands stuff in Leptos 0.5: If the user experience of "basically an old-school multi-page app with some islands of interactivity sprinkled in" works, it can probably reduce your WASM binary payloads by ~80%. I'm happy to talk through any of the concepts there as needed.

[SleeplessOne1917]

@erlend-sh

I suggest the Lemmy project formally adopts Photon to replace lemmy-ui.

While I can be convinced, I'm against the idea. There are already several features for 0.19 that have been implemented in the existing UI project that will have to be implemented again in photon. @Nutomic I believe you also expressed pushback against this.

Very limited ecosystem; many useful libraries are maintained by only one person with few commits and seem likely to be no longer actively developed

Can say which libraries you’re referring to? Are these libraries that lemmy-ui-leptos relies on?

We had the issue with the icon library already. We had to switch to leptos-icons from leptos heroicons because the heoricons crate stopped receiving active development.

[erlend-sh]

There are already several features for 0.19 that have been implemented in the existing UI project that will have to be implemented again in photon.

The essentials appear to have been completed already:

• feat: v0.19.0 support Xyphyn/photon#162

[dessalines]

@erlend-sh We have no association with whoever made photon, and they've never contributed to lemmy-ui or the lemmy backend. I don't see us accepting as "official", a front end that we have no control over.

@gbj Thanks, that's great to hear! I'm sure we'll have plenty of questions that we'll ask in the matrix chats as we develop this further.

[erlend-sh]

I don't see us accepting as "official", a front end that we have no control over.

Of course not. What I’m proposing is that you make contact with the Photon developer to figure out if a transition into co-ownership would be possible, I.e. moving Photon into the Lemmy org with @Xyphyn staying on as the lead maintainer of it.

This would be purely additive. The Leptos UI is happening regardless, but it will take months to finish, at best. Meanwhile no one is keen on spearheading development of the official (legacy) UI.

[Nutomic]

Whats the reason for rewriting lemmy-ui in the first place? I dont remember seeing any clear explanation for that.

While I dont work on lemmy-ui, a full rewrite doesnt make any sense to me. The project has been under development for three years now, so there has been tons of testing and bug fixing over that time. Any full rewrite would have to start from scratch in that regard, and would be plagued by countless bugs. Additionally a new frontend would cause complications for admins because the deployment and configuration would be different. Switching to Photon as official frontend would additionally mean that users would have to get used to a completely different design.

If there are good reasons to switch the technology, then it should be done in a way that keeps most of the existing code. So mainly switching to a different framework in the existing repo.

[erlend-sh]

I’m happy with this solution as far as alternative frontends go:

• Include other lemmy front ends in this ansible. lemmy-ansible#180

So feel free to refocus the discussion here on the merits of Leptos.

[SleeplessOne1917]

@Nutomic the motivation for rewriting lemmy-ui is primarily technical. Trying to do some things with inferno, especially keeping server and client side renders consistent with each other and sharing state between the server and browser, requires kuldgy workarounds to make work properly. This makes things harder to maintain and makes it easier for severe flaws to be introduced. For example, the XSS vulnerability that affected several instances a few months ago was caused by a mistake in the workaround that was used to send data about the site to the browser after server side rendering. While it is certainly possible to add features and fix bugs on the existing UI, the hacking it takes to get things to work and the bugs that slip through because of it is, to me at least, a time drain that, while maybe not expensive in the short term, adds up cumulatively to be more than the time it would take to do a rewrite in a more accommodating framework.

If there are good reasons to switch the technology, then it should be done in a way that keeps most of the existing code. So mainly switching to a different framework in the existing repo.

The only code that could be ported over to another framework cleanly would be the JSX and the vanilla typescript files. Regarding the latter, a lot of the typescript files we have are covering things that many frameworks have built-in/more compatible ways of handling, so much of that code would become irrelevant with a rewrite. Even with the JSX, different ways of handling things in a framework will likely end up changing that as well.

In short, not much of the existing UI code would be salvageable in an in-place change in framework and using a more featureful framework will help lead to a codebase with fewer foot-guns and, hopefully as a result, fewer bugs.

[jim-taylor-business]

i think this discussion has run it's course and the conclusion is in favour of Leptos.

can this issue be closed @SleeplessOne1917 ?

[phiresky]

I wanted to respond to this a while ago but never really got to it so I'll put my low-effort two cents here now just for completeness:

I don't think it's a great idea to move the official frontend to be in Rust, with the primary reason already mentioned in the top post: Rust has a high learning curve. Frontend development needs a lot of grunt work. Pulling numbers out my ass, 90% of frontend code is not complex but rather more juggling code and UI elements around a ton. Rust makes that harder for no real reason - the strengths of Rust (performance, memory safety, ...) are mostly irrelevant for UI.

And then the huge thing is that there's probably 10x-100x as many fairly capable JS/TS devs out there than Rust devs. Most of those won't be willing to learn Rust just to contribute to lemmy. You can already see so many discussions where people talk about adding random stuff to lemmy while absolutely refusing to consider contributing to lemmy proper or even looking at the lemmy code base - a lot of it I think is caused by Rust. For the backend that's probably fine, but for frontend it would be pretty bad. You'll lose a ton of potential contributors by moving to a Rust library, no matter how beautiful it is.

I know the current inferno framework based thing is a bit of a shit show, but really only a tiny portion of lemmy ui needs to be structured very robustly / high quality. For all the UI itself, having contributors seems more valuable to me than having it be beautiful. Also then people can add random minor features to one instance and see if people like it (free experimentation)

I think it would be a much better idea to migrate it to something like nextjs, which should be not-too-high effort to migrate to, has a huge user base (and thus developer knowledge and support base) and is being actively developed with no sign of stopping. Other changes (like revamping styling or structure) can be made incrementally.

[SleeplessOne1917]

I think it would be a much better idea to migrate it to something like nextjs, which should be not-too-high effort to migrate to, has a huge user base (and thus developer knowledge and support base) and is being actively developed with no sign of stopping. Other changes (like revamping styling or structure) can be made incrementally.

I'm not opposed to switching to NextJS or some other JS framework (though I'm somewhat partial to SolidJS/SolidStart), although I don't think we would be able to (or if we can, should) reuse as much code from the inferno project as you might expect. One major factor is that inferno uses the old class component style like versions of React before 16.8 use. Most of the react libraries I know of are made only with functional components in mind.

Regarding using rust: using a rust framework may make it harder for a larger number of devs to contribute, but given how much it's loved by the people who use it it could also mean the fewer devs who do contribute are more engaged with the project. The ratio of rust devs to TS/JS devs may also be mitigated somewhat due to Lemmy's appeal with FOSS aficionados, who I reckon are more likely to be programmers than you average social media user. The points I raise wrt rust should be taken with a grain of salt, as I'm not sure how how to reliably predict which language/framework would be better for attracting contributors.

Ultimately, my only hard stance on this is that the default UI needs a rewrite: InfernoJS is barely documented, barely supported by libraries, and overall significantly more of a pain to work with than all of the options listed in the OP.