Frontend scaffold options

[dgorshkov]

Hi there! Congrats on the launch, and thanks for making this. Great idea.

Now onto the actual feature request.

So when I saw that this is Rails-inspired, I naturally expected something similar to generate scaffold and Action View. A way to have a bare-bones HTML frontend up and running quickly.

Instead, I'm getting a DIY kit to assemble a CRUD REST API, and zero help with the actual frontend. Should I use React/Vue? That's not the Rails way.

I'm also not seeing anything about this topic in the roadmap in the README.

"Loco follows Rails" is not true (yet).

Again, I find the project really awesome, but there's a long road ahead, it looks like.

[jondot]

Hi,
Thanks for the feedback -- I think it is very important.

We left the frontend part undecided, precisely for this reason -- to understand what people prefer. Even Rails moved from HTML and jquery, to HTML and ejx (remember that?), to HTML and PJAX, and then everyone did Rails API + React (remember that?), and today Rails is doing turbo and these kind of family of solutions. Rails evolved from feedback and we respect that.

We think Loco needs to evolve too. The foundation at 0.1.x is very strong (i.e. we already supply scaffold), the frameworks are there, and it's no-brainer to generate a bunch of view using the existing infrastructure.

Another possibility is that the Rust community will prefer a Rust-flavored frontend like Yew, or Dioxus or the likes.

I think the hard part is hitting at what people expect these days.

By the way we also promote contribution. If you think you have an idea we would happily review a PR and help you make it into the framework.

[gc-victor]

I was thinking of creating a framework using a mix of JavaScript and Rust on the server, but I think it could work with Loco. The idea is to use a JavaScript Runtime in Rust to return the pages.

It would be something similar to:
https://github.com/gc-victor/query?tab=readme-ov-file#function

Would you be interested in having it in Loco?

[kaplanelad]

Hey @gc-victor

Presently, our primary emphasis is on developing a REST API server, with a reduced focus on server-side rendering UI.

having said that,
we are open to your insights and perspective.
What addition do you think to add in Loco
which libs do you think should be added?

[gc-victor]

I understand it.

I'm using rustyscript with some extensions, a file-system based router and a build step.

[kaplanelad]

@gc-victor, feel free to implement your planned changes in your repository based on Loco (see HTML starter). Once done, we can see how well it can integrates with our project and which additional we can add.

[gc-victor]

@kaplanelad, I don't think it is worth working on, as you don't seem convinced about the value of this feature in Loco. Let's see if I can collaborate with the Loco on other stuff.

[dgorshkov]

Being opinionated and integrating Yew or Dioxus would make total sense. You should go for it.

[jondot]

Converted to discussion. We'll update as we move forward on this, thanks!

[Kade-Powell]

I'd like to propose along with dioxus you look at leptos for front end UI needs. There are some UI kits for it like leptonic.

Happy to see a project like this, thanks!

[jondot]

Thanks
I've checked dioxus, I'm kind of torn in between.. hard to say it would be more productive than using something like React. I'm wondering if there's a real world project I can take a look at to see how people actually work with dioxus

[Kade-Powell]

The allure of sharing types between UI and backend systems greatly enhances productivity. Both Dioxus and Leptos leverage a shared server functions crate, allowing seamless generation of server-side and client-side functions from a single definition. Those opting for Rust in their tech stack typically prioritize its type safety and ecosystem over JavaScript’s vast offerings. Notably, Rust allows interoperability with JavaScript in both Dioxus and Leptos. In my specific use cases, a full-stack Rust approach stands as the primary reason to consider a project like Loco. Additionally, HTMX has been noted in other discussions as a desired option, and leveraging Leptos or Dioxus to render HTMX-enhanced applications seems viable for those who want it. The advantage here lies in crafting type-safe applications with the flexibility of opting for JavaScript where needed. Also if you're concerned with attracting more developers I would say leptos has an API more familiar to a web developer than dioxus does.

[mikebelanger]

The allure of sharing types between UI and backend systems greatly enhances productivity.

Yeah not having to constantly declare types into something in OpenAPI/gRPC/graphQL (or worse, just manually) is incredibly alluring. That said, if most of the HTML gets server-side rendered anyways, that can often side-step the issue of synchronizing API payload schemas.

If you're interested in interoperability with Javascript libraries, I suspect they would find it easier to grab state from the regular DOM than Virtual, and therefore any Rust framework that doesn't use the virtual DOM would be preferable. So a +1 for Leptos from me. Not sure about Diouxus.

[ealmloff]

I'm wondering if there's a real world project I can take a look at to see how people actually work with dioxus

Here are a few examples:

• https://github.com/Satellite-im/Uplink
• https://github.com/terhechte/ebou
• https://github.com/purton-tech/cloak

[jondot]

Thanks! I actually know cloak just didn't know it to that level

[Gitznik]

How about providing a simple static HTML setup from the start, potentially with htmx, and if people need something more they can switch to a full FE framework of their liking?

This should give a quick and simple starting point for at least smaller projects, without locking the user into a specific, more complex and opinionated FE framework.

[mateusdeap]

I'm just going to second this opinion. Especially on the account of htmx. Maybe I've been reading too much of their book, but I do believe (or at least it makes sense to me) that a web framework will out of the box render html server side and send it to the client. Which is what I thought when I came across loco and it being inspired by Rails. And is the basic way the web works: exchange of HTML via HTTP.

Then, as a second option or a configuration possibility, you make it talk to some frontend that expects a JSON payload or some other data format.

But again, just my opinion, which is heavily built on my experience with Rails, Ruby, etc. I'm completely unaware of the Rust community's general preferences when it comes to these things, although I have noticed that most rust shops tend to do their web frontends with some JS frontend framework, so maybe sending a JSON by default is the more natural thing here and I'm the odd ball hahaha

[mateusdeap]

Also, I'm definitely curious as to this: suppose I want to do things like Rails does it (render HTML server side and send it over to the client), how would I do that with loco? Is there a templating language like in the Ruby/Elixir/Python world? Or would it be done some other way? How would I get my app server to properly replace the data where I want it in the HTML?

[mikebelanger]

@mateusdeap The rust ecosystem has a number of template approaches that would work. Askama for example. But there's many other options.

How would I get my app server to properly replace the data where I want it in the HTML?

In the case of HTMX, you'd add an hx-post (or whatever attribute corresponds to the respective HTTP-method) to whichever parent element's HTML you want to replace, then specify inner/outer HTML.

Tbh, while I think HTMX is a step in the right direction, my feeling is plain, vanilla JS can be used here too. Just fetch whatever endpoint has the HTML, and hold a reference to whichever element's HTML you want to replace. Some people suggest using web-components to encapsulate the functionality too.

[mateusdeap]

In the case of HTMX, you'd add an hx-post (or whatever attribute corresponds to the respective HTTP-method) to whichever parent element's HTML you want to replace, then specify inner/outer HTML.

Oh, I think my question became ambiguous. What I meant was precisely if there were any templating languages and how do I get loco to respond with html instead of JSON. I mean, I think I'm missing something, but the view examples I saw all seemed to be Rust structs that would get transformed into JSON rather than HTML with rust interpolated in it.

Another way of saying would be what's the loco equivalent of render :index, I suppose

I'm definitely checking out askama.

[mikebelanger]

Looks like Loco uses Tera for email HTML. Was there an idea to extend Tera's use for "regular" browser HTML?

Besides the other commenter's suggestions (leptos, yew, etc), consider Silkenweb. Its similar to Leptos, but has a philosophy that aligns with loco in that it minimizes fancy-macro boilerplate.

[kaplanelad]

We created an example of how to serve/develop a front-end app with Loco.
Blog
Repository

It will be greate to get your feedback.