Show HN: Create-rust-app: now supports poem-web back end | Hacker News Reader

Show HN: Create-rust-app: now supports poem-web back end

github.com

28 pointshar1s9 comments

This repository is much larger than it should be, downloading over 42MB and taking over 100MB of disk space, mostly because you’ve included over 53MB of video files that are demonstration screencasts. These files do not belong in the main code repository: taxonomically they’re more marketing material than code, and they’re large enough that they make other things more difficult; they should be stored separately, e.g. in a separate repository (such as the corresponding .wiki repository, on GitHub), or uploaded through GitHub’s editor and referred to that way (not under version control).

There’s also create-rust-app_cli/template-plugin-dev/.cargo/admin/dist, 8MB of compiled artefacts, which looks like it doesn’t belong in version control either.

For best results, please remove these files from the repository, including all its history (git-filter-branch or whatever). Then the whole repository would be under a couple of megabytes, and much more palatable.

(When you’re on the other side of the world from where the repository is being served, downloading that 42MB repository can take several minutes rather than the 10 seconds I might hope for based on my typical download speeds.)

Thanks for the feedback Chris :) I'll see what I can do about the demo videos in the repository.

However, the 8MB compiled bundle is for those users who create projects with the admin plugin -- it gives them a dashboard into their database. It's still a work in progress, and I think moving it into a separate package should be considered (something on npm, I'd imagine)

I think that represents a flaw in Git really. It would clearly be better if you could store large files in a repo, but Linux doesn't need that so solutions like LFS are relegated to hacky add-ons that don't integrate well.

For example it's impossible to move files between the repo and LFS after they've been added without rewriting history, but there's no fundamental reason for that as far as I know.

Poem and axum seem to be new frameworks - both have the lowest downloads on https://www.arewewebyet.org/topics/frameworks/. I'm not too familiar with the Rust web ecosystem (only knew about actix and rocket before this), so is any one of them looking likely to become a dominant player in the future?

On the Node side I really like the batteries-included and opinionated approach of NestJS (which is modelled after Angular and inspired by Spring I think) and I think something similar on the Rust side would do very well.

Axum leverages the Tokio ecosystem which makes it an interesting contender. I personally find it easy to use, without the large amount of macros that Rocket uses nor the very long and complex types that Warp creates.

The introductory blog post is helpful: https://tokio.rs/blog/2021-07-announcing-axum

What makes the macro approach of Rocket undesirable? I thought it was comparable to decorators in TS or Python

Mostly opaqueness, i.e. it makes debugging and IDE/language server features harder to use. Macros generally also lead to longer compile times.

Also, unrelated to its use of macros, Rocket development seems to have stalled after August of last year.

Great start. Please consider adding warp as a backend. A small tutorial or blog will also be helpful in demonstrating the concepts.

thanks :)

The create-rust-app.dev domain is meant to host the documentation (which definitely needs more work!)

EDIT: as it stands, the installation instructions on the docs site are outdated haha

Reply on news.ycombinator.com