logoalt Hacker News

Topcoat: The full full-stack framework for Rust

55 pointsby wertykyesterday at 8:41 PM31 commentsview on HN

Comments

carllercheyesterday at 10:54 PM

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 they already use.

mamcxtoday at 1:12 AM

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.

frytapedtoday at 3:21 AM

How does this compare to Leptos ?

hoistbypetardtoday at 2:34 AM

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.

show 1 reply
jjicetoday at 12:00 AM

Oh man I'd love a nice full stack framework in Rust! Django, Laravel, and Rails are very neat. I used to be a micro framework kind of guy, but having everything integrated is more and more appealing over the last few years.

This would take a long time to get feature complete with the core of those big full stack frameworks, but I'm rooting for it! Getting to use the Rust type system with a full stack web framework sounds incredible.

show 1 reply
hobofanyesterday at 11:13 PM

Hmm... I'm a big fan of a lot of the things that the tokio project has built and a happy user of axum.

I'm not sure that projects like Topcoat and something like their ORM is a great direction for the project, and worry that they will possibly gain outsized adoption in the community based on name recognition rather than merit.

show 1 reply
BobbyTables2yesterday at 11:49 PM

Does “full-stack” really mean “webserver + webpage” nowadays?

show 1 reply
frioyesterday at 11:56 PM

Exciting, but I’d give a lot for an equivalent to Django. There are very few problems I need to solve that are fixed by htmx style “full stack” apps, but many that are solved by the generated admin, authentication framework, caching, eventing etc.

Unfortunately, you end up bound to Python’s poor performance and poor typing stories, which Rust solves in spades.

hingler36today at 1:43 AM

Super exciting stuff, especially coming from one of the best projects in Rust (imo). Can't wait to see where this goes!

seanclaytontoday at 12:03 AM

Back in my day 'batteries-included' at least included schemas/models and a database abstraction. Claude can whip one up quick!

canadiantimtoday at 12:01 AM

Looks incredible, also loving toasty. Great work all around

jdw64today at 12:40 AM

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.

show 1 reply
newaccountman2yesterday at 9:18 PM

I don't feel like this is solving the painpoints I feel in the Rust web framework ecosystem. And how is it full-stack if they don't have anything for the DB layer in here?

show 2 replies
27183yesterday at 11:16 PM

Is the name a POR-15 product reference? Incredible if so :D

  \m/_(>.<)_\m/
goldturdyesterday at 11:17 PM

Reminds me of if ruby had a baby with diarrhea.

Rust in general