Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Topcoat: The full full-stack framework for Rust

github.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Topcoat: The full full-stack framework for Rust

#21

Post by jdw64 »

I'm looking at it with anticipation, but I want to hold back because I don't want to offend you... I think this works as a wrong pattern in Rust.

When I see syntax like $(...), it looks like a transpiler that embeds Rust AST inside JS. I think it would make Rust's already terrible developer experience even worse. I think the actual value of the string length on the server side will differ, specifically `len()`.

And I'm not sure if bundling binaries and assets this way is the right approach. This feels less like Rust and more like a DSL that intersects Rust and JS. it feels like something different.

I like Tokio and think it's really well made, but this framework seems a bit wrong to me.

Re: Topcoat: The full full-stack framework for Rust

#22

Post by carllerche »

jdw64 wrote: post #21

I'm looking at it with anticipation, but I want to hold back because I don't want to offend you... I think this works as a wrong pattern in Rust. When I see syntax like $(...), it looks like a transpiler that embeds Rust AST inside JS. I think it would make Rust's already terrible developer experience even worse. I think the actual value of the string length on the server side will differ, specifically `len()`. And I…

I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make everyone happy. And JS libs are a heavy inspiration. They do a lot right and have years of experience in the browser-app space. If you don't like it, Axum aims to be the lower-level HTTP router that anyone can build their own abstractions on top of.

That said, if you are up to it, I would ask that you try using it and provide your thoughts after using it as an issue. Feedback is appreciated.

Re: Topcoat: The full full-stack framework for Rust

#23

Post by carllerche »

biorach wrote: post #20
carllerche wrote: post #17

Earlier quoted context omitted.

Yes, that is the goal. Those frameworks have a bit (more than a decade) head start though :) there is a lot to build. There already is an ORM ( https://github.com/tokio-rs/toasty/ ). You can see a sketch of the roadmap here: https://github.com/tokio-rs/topcoat/issues/104

> Those frameworks have a bit (more than a decade) head start A decade? More like 21 years

Don't remind me... I'm old. (I was involved w/ Ruby on Rails in the early days)

Re: Topcoat: The full full-stack framework for Rust

#24

Post by jdw64 »

carllerche wrote: post #22
jdw64 wrote: post #21

I'm looking at it with anticipation, but I want to hold back because I don't want to offend you... I think this works as a wrong pattern in Rust. When I see syntax like $(...), it looks like a transpiler that embeds Rust AST inside JS. I think it would make Rust's already terrible developer experience even worse. I think the actual value of the string length on the server side will differ, specifically `len()`. And I…

I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make everyone happy. And JS libs are a heavy inspiration. They do a lot right and have years of experience in the browser-app space. If you don't like it, Axum aims to be the lower-level HTTP router that anyone can build their own abstractions on top of. That said, if you are up to it, I would ask that you try us…

Thank you. I hope I didn't offend you. First, I think the len() part is problematic. Could you check that for me? I think it's calling Rust's str::len() and using JS's String.length, which I think should be aligned with UTF-8.

I'll try it out next time and give feedback later. And you're right, it's just a difference of opinion.

Also, for the API side, Unicode strings are usually 4 kinds right? I think using Rust-style snake_case, we might need separate functions like len(), utf16_len(), and so on. But I'm not sure how to handle the abstraction between libraries and browsers.

Sorry for being critical. I'm not that good of a programmer, so it might be a mistaken observation. Please check it.

Re: Topcoat: The full full-stack framework for Rust

#25

Post by mamcx »

This sound fantastic and Django is the main thing I miss from python.

htmx+ tailwindcss is the one combo that is right and I use it so seeing is the direction give me hope.

Some notes, I hope can be considered!:

- The main thing is the auto admin, then `auth`, is great that the `auth` is mean to have a one-to-one connection for your own extensions

- The main pain is that everything is tangled to the ORM and the auto-admin

What I have done informally is that with traits I have something like `ListQuery` and compose `Paginate(ListQuery)`.

Then pure descriptors of what the ui DO, but not what it looks like and not even html at all.

THEN, I inject the stucts/enums (all Ui is things like `Label{...}` with not logic at all in templating, all the server side is in charge of pre-render) into some templating and there is where the ui is alive, but replacing is 100% doable and expected.

What I miss is a way to introspect to auto-generate things more auto.

Re: Topcoat: The full full-stack framework for Rust

#26

Post by jonahx »

carllerche wrote: post #3

I didn't expect to see this here yet. We opened up the repo because we ran out of private CI usage. A blog post is coming next week :). Happy to answer questions here though. One thing to keep in mind, the main reason for Topcoat to exist is that many organizations are already using Rust for infrastructure-level or performance sensitive reasons and often just want to build a web app using the programming language the…

I'll say that first code snippet is a fantastic TLDR.

Re: Topcoat: The full full-stack framework for Rust

#27

Post by swaptr »

carllerche wrote: post #3

I didn't expect to see this here yet. We opened up the repo because we ran out of private CI usage. A blog post is coming next week :). Happy to answer questions here though. One thing to keep in mind, the main reason for Topcoat to exist is that many organizations are already using Rust for infrastructure-level or performance sensitive reasons and often just want to build a web app using the programming language the…

Great initiative from the folks at tokio. How does it aim to be different from loco.rs https://github.com/loco-rs/loco?

Re: Topcoat: The full full-stack framework for Rust

#29

Post by carllerche »

swaptr wrote: post #27
carllerche wrote: post #3

I didn't expect to see this here yet. We opened up the repo because we ran out of private CI usage. A blog post is coming next week :). Happy to answer questions here though. One thing to keep in mind, the main reason for Topcoat to exist is that many organizations are already using Rust for infrastructure-level or performance sensitive reasons and often just want to build a web app using the programming language the…

Great initiative from the folks at tokio. How does it aim to be different from loco.rs https://github.com/loco-rs/loco ?

Both Loco and Topcoat aims to be "batteries included" but that means very different things to each project. Topcoat aims to make it easy to build reactive apps without writing any browser JS (or Rust). It uses a similar strategy to Hotwire, HTMX, Datastar, ... It also will default to using the Toasty ORM (though topcoat is modular so you a swap it out). Topcoat is very young and there is a lot more to build.

Re: Topcoat: The full full-stack framework for Rust

#30

Post by hoistbypetard »

This seems to be missing both an ORM and an argument for building without one; I'd have a hard time calling something a "full full-stack framework" without either an ORM or a very well-articulated statement for why that's a non-goal and what convention replaces it, allows for auto-generated admin pages, etc.

I don't think an ORM is necessary, but I do think you need to say what people are meant to do instead and how your batteries are included without it, if you're going that direction.

Post reply on HN