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.<p>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.
Great initiative from the folks at tokio. How does it aim to be different from loco.rs <a href="https://github.com/loco-rs/loco" rel="nofollow">https://github.com/loco-rs/loco</a>?
I'll say that first code snippet is a fantastic TLDR.
This sound fantastic and Django is the main thing I miss from python.<p>htmx+ tailwindcss is the one combo that is right and I use it so seeing is the direction give me hope.<p>Some notes, I hope can be considered!:<p>- 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<p>- The main pain is that everything is tangled to the ORM and the auto-admin<p>What I have done informally is that with traits I have something like `ListQuery` and compose `Paginate(ListQuery)`.<p>Then pure descriptors of what the ui DO, but not what it looks like and not even html at all.<p>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.<p>What I miss is a way to introspect to auto-generate things more auto.
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.<p>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.
Yes, that is the goal. Those frameworks have a bit (more than a decade) head start though :) there is a lot to build.<p>There already is an ORM (<a href="https://github.com/tokio-rs/toasty/" rel="nofollow">https://github.com/tokio-rs/toasty/</a>). You can see a sketch of the roadmap here: <a href="https://github.com/tokio-rs/topcoat/issues/104" rel="nofollow">https://github.com/tokio-rs/topcoat/issues/104</a>
Super exciting stuff, especially coming from one of the best projects in Rust (imo). Can't wait to see where this goes!
Hmm... I'm a big fan of a lot of the things that the tokio project has built and a happy user of axum.<p>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.
Does “full-stack” really mean “webserver + webpage” nowadays?
Roadmap: <a href="https://github.com/tokio-rs/topcoat/issues/104" rel="nofollow">https://github.com/tokio-rs/topcoat/issues/104</a>
ORM: github.com/tokio-rs/toasty<p>It is early, a lot is coming, but you can already build good stuff now.
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.<p>Unfortunately, you end up bound to Python’s poor performance and poor typing stories, which Rust solves in spades.
Here's a v0.0.2 jinja2rs built on minijinja with optional python compatibility; <i>CompatMode::Django(…) Django template language (filters, app-directory loader, auto-escape)</i> :<p>jinja2rs::filters : <a href="https://github.com/westurner/dsport/blob/main/src/jinja2rs/src/filters.rs" rel="nofollow">https://github.com/westurner/dsport/blob/main/src/jinja2rs/s...</a><p>jinja2rs::filters::django :
<a href="https://github.com/westurner/dsport/blob/main/src/jinja2rs/src/filters/django.rs" rel="nofollow">https://github.com/westurner/dsport/blob/main/src/jinja2rs/s...</a><p>Which Rust components are like the Django ORM and django.contrib.admin and DRF/FastAPI; with convention over configuration and tests and great docs?
Back in my day 'batteries-included' at least included schemas/models and a database abstraction. Claude can whip one up quick!
Looks incredible, also loving toasty. Great work all around
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.<p>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()`.<p>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.<p>I like Tokio and think it's really well made, but this framework seems a bit wrong to me.
I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make <i>everyone</i> 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.<p>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.
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.<p>I'll try it out next time and give feedback later. And you're right, it's just a difference of opinion.<p>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.<p>Sorry for being critical. I'm not that good of a programmer, so it might be a mistaken observation. Please check it.
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?
This will (very soon) integrate tighter with the Toasty ORM <a href="http://github.com/tokio-rs/toasty/" rel="nofollow">http://github.com/tokio-rs/toasty/</a>. E.g. tight form -> record flow. We are shipping now though to get usage.<p>What pain points do you have in the Rust web framework ecosystem? Happy to hear.
Likewise. I'm commenting based on my position:<p><pre><code> - Rust Fanboy; use it in several domains (embedded, PC applications, bio/chem)
- Web dev is the main thing I still use Python for, as there's nothing on Django's level.
</code></pre>
Of interest: I am not a fan of Async in rust. I get that for web stuff it is a suitable model, but I still don't like it for no original reasons. As you stated, I don't feel like this is solving the missing aspects, e.g. auto migrations, admin, email, auth, etc.
Migrations: Done with Toasty (<a href="https://github.com/tokio-rs/toasty/" rel="nofollow">https://github.com/tokio-rs/toasty/</a>) which I intended to be integrated tightly with topcoat. You can see a rough roadmap here, which will be posted: <a href="https://github.com/tokio-rs/topcoat/issues/104" rel="nofollow">https://github.com/tokio-rs/topcoat/issues/104</a><p>Better to ship early and hear what people want though :)
Is the name a POR-15 product reference? Incredible if so :D<p><pre><code> \m/_(>.<)_\m/</code></pre>
Reminds me of if ruby had a baby with diarrhea.<p>Rust in general