[Feature Req] Refactoring the frontend

[phil-flip]

As outlined by neobooru in an old ticket of mine on szurubooru it was mentioned that the frontend is quite a hard thing to maintain without the use of a proper Framework. I started a while back with one in SvelteKit with TS and Tailwind because I wanted eventually make a fork of the Project and start talking the frontend. But because of other projects unrelated to this issue, I never finished it.
But because this project is written in rust I would imagine that you would like more a framework that fits your needs. Regardless, I thought it made sense to open up an issue for this. As it is something that might need redoing and should be tracked as a suggestion.

[Yochyo]

I'm considering completely rewriting the frontend during my Christmas break. I've modified parts the current frontend before, and that definitely wasn't the most pleasant experience (but far from the worst).

If I have experience with the framework you'd like to use, I'd be happy see what I can do.

[phil-flip]

Amazing!
If you want to I can also publish the very outdated and incomplete SvelteKit frontend to see what is still usable.
But for now I kinda want to see what @liamw1's opinion and plans are for this, before we make something that might not get merged upstream.

[liamw1]

the frontend is quite a hard thing to maintain without the use of a proper Framework

This is a recurring issue I've had as well. Even simple things like updating dependencies is very scary because JS is dynamically typed, so there's no way of knowing if I've borked something unless each branch I modified gets executed.

A rewrite in TS with a proper framework would be amazing, but I don't have frontend experience so it would take me a lot of time.

because this project is written in rust I would imagine that you would like more a framework that fits your needs

I'm not too attached to what frontend framework is used. I could choose something completely insane and start rewriting the frontend in Rust (which I've unironically considered), but I would like at least some potential for collaboration with others so this doesn't just become my archaic Rust project.

If you're both interested in collaborating on a frontend rewrite/refactor, I could open up a feature branch and you could push there. Or if you'd rather work on your own fork that's fine as well.

[Yochyo]

I had good experiences with SvelteKit and it sounds like a good choice for this kind of project. @phil-flip would you like to provide your code as a base?

[phil-flip]

@Yochyo I created a branch on this Repo called feature/new_frontend that you can fork. As you will probably notice, there isn't much content in it. But it gives a bit of a design idea, what I had in mind way back when.
I also took the time to download the newest version of SvelteKit and only drop in the work I already did. So it should be a stock experience with the newest features ™️

[aleee-idk]

Hi! I would like to know if there are news about this and to add my two cents on what I think would benefit the project.

I agree that a FE framework would allow to better maintain the codebase, and I think svelte is a good candidate, but I want to put HTMX on the table as an alternative. HTMX it's really good for projects that are heavy focused on the backend and it's really easy to integrate to a workflow in which server side rendering with templates (like minijinja or tera) are used.

This would allow to reduce the code complexity of adding a hole new language and it's ecosystem into the project, while maintaining the robustness of the rust type system as the source of truth. But it also has it's limitations, primarily as it serves to add a little interactivity to otherwise static pages, the more interactivity we would want to add the harder it gets; in which case a proper FE framework as svelte would be better.

Whichever the case, I would like to contribute to this feature as I have been enjoying the project and the FE could use some love, I have experience working in the frontend (mostly in react but they're all pretty much the same) and also a little in rust.

[Yochyo]

I'm working on it little by little. HTMX is an interesting suggestion. I kinda reached a point where rewriting the whole code in HTMX would take too long though.

[Yochyo]

@aleee-idk I kinda dismissed htmx this morning, but the longer I think about it the more I wonder. Could you explain why you think that it would be a good fit?

I doubt the frontend is going to change very much for now (i.e. it's mostly static pages) and htmx seems to shine when reactivity is involved, doesn't it?

[phil-flip]

I like to add: its very static, because noone wants to update with the current frontend system.

[aleee-idk]

A couple of things:

• I have tried to integrate frontend tooling into an axum project before with different approaches, the most successful one with vite-rs but it's still a nightmare to manage.
• The frontend ecosystem moves very quicky, I had other side projects before in which I could never actually work on them because I had to constantly deal with updates. That's without talking about the new framework or runtime every other week.
• The main components of this project are images and other media items, so a really fast and responsive UI would be ideal. HTMX weights a lot less that any frontend framework and server side rendering approach can help with this too.

It all sums up to "add a more modern feeling" to static pages without having to deal with all the javascript ecosystem, which would allow to center the focus on the backend and rely on the rust type system as said before. On this topic, early today I knew about this template library that seems awesome to use the power of rust also in the templates.

That been said, it really depends on the focus in which you want to aim the project: a full interactive frontend with animations, transitions, states updates and all that or a simple server side template driven approach. Because as good as it sounds to prevent adding the javascript ecosystem, it's way harder to try to do complex frontend interactions without it.

IMHO, I think it's better to put all the effort of the few collaborators into making the backend as robust, safe and snappy as possible.

[YelovSK]

I don't know whether it makes sense to even post it in here (probably not), but a couple of days back, I started making an Angular client for oxibooru, but it's not something that anyone should use. The motivation is in the readme, but the tl;dr is that I want to experiment and try dumb stuff myself, without having to consider what is good for most people. Additionally, it's mostly LLM-generated, as I don't want to spend my free time coding after work. Right now it has a pretty small coverage of the oxibooru api, so there's a lot of functionality missing. Plus it's a relatively heavy client. So in the end, I'm still hoping that someone will make a more modern client.

[liamw1]

@aleee-idk I think I'll have some time to dedicate to this project again, so I've been researching and comparing options for a new frontend framework. After reading into some of the reasoning behind HTMX, it seems very appealing to me. The simplicity of it is a big plus, especially considering the limited time and energy I have to work on the project.

I think I'll start experimenting with it. I'm fairly confident that most of the functionality in the current client can be replicated in HTMX. There are some exceptions, like how post notes are created, so it may require some sprinkles of JS here and there. Even so, removing as much JS as possible is another big plus. The rate at which the client dependencies accumulate CVEs is... concerning, so I'd like to rely on that ecosystem as little as possible.

[aleee-idk]

That's nice to hear, I was about to start developing a client as a proof of concept but I entertained myself doing a cargo-generate template for a MVC web aplication using axum + askama + HTMX. Maybe it can help to kickstart the new frontend or as inspiration.

Let me know if I can contribute with something, I don't have that much time but I can code a few hours a week.

[phil-flip]

I like the idea of using HTMLX as well, but I'm unsure if that's going to be maintainable and has a good ecosystem around it, mainly because of missing popularity.