Even if you have the full menu on your phone, you still have to zoom into the menu to read it and pan the view. I don't see how that's any different from scrolling through a categorized menu in a website on your phone.
The difference for me is when the menu gets large then it becomes laborious to scroll through a long linear menu vs a rectangular representation of that same data - which allows for much shorter scrolls. Imagine the menu on a restaurant was handed to you on a 4ft long receipt, you’d get pretty fed up of moving it up and down.
Zooming allows you to narrow in on the content you desire from a big picture point of view while vertically scrolling you just must hope that you get lucky to find what you are looking for.
Agreed. When I first considered porting small APIs over to Rust, Rocket appeared to be the most popular besides Actix. Axum hadn't even came out (it came out a month later and we ended up using it even though it was in its infancy). It's pretty unfortunate because Rocket could be amazing but the lack of updates killed it. See you guys in 5 years when v0.6 comes out.
Linear looks good but it's SaaS only. It doesn't feel like a good idea to pump a lot of a company's crucial data into an external system without a way to get it out and continue elsewhere (which is a problem with a lot of bug tracking and project planning software).
> Except that I read that it's great for writing, but a nightmare for reading.
This is true at first. I can see it being pretty daunting to come into an existing project and trying to understand the styling of components. Starting from scratch and easing it into an existing project is much easier imo. That's what I did for a personal website. Now that I understand it and have converted the entire website to Tailwind, I don't want to switch to anything else going forward.
I started with the book to learn the fundamentals. I didn't get very far before I decided to rewrite an existing API I had in Python into Rust.
It definitely took some time and learning but now I have 6 Rust API microservices, a few scheduled/queue-reading services, and a shared library for common models/utils/providers.
To be fair, Caddy's docs aren't great either. Last time I tried to deploy it to give SSL to something that didn't have it, took me 2 hrs to figure out the docs enough to get it working.
Caddy 1 docs felt handcrafted for each use case it supports, whereas Caddy 2 documentation feels generated, except for a couple of pages, which is enough to cover 99% of my needs.
I also think Caddy 1 was just simpler to use in general, so it didn't matter as much. But I don't have much experience with that version, so could be wrong.
Time and trial-and-error is what eventually solved it.
I was trying to configure the auto-HTTPS functionality to use DNS challenges, because my setup forbids any of the others, and this apparently requires plugins that are only supported by community efforts, so that's probably why I had such an issue.
The docs around configuring this were not immediately clear to me. Its like one part is over in this corner, the other over there. And the part about DNS provider plugins is off in a completely different direction. I definitely think things could be better organized. Also your one tutorial for getting HTTPS support only mentions the very basic cases. I think it'd be beneficial to see some more advanced tutorials using for instance some of the other LE challenge methods, something like this definitely would've saved me some time.
I love & use caddy for proxying to Docker containers + other services running outside Docker.
I wish there were an easier way to bind docker ports to Caddy automatically (without using dokku et al.), but for now I maintain a Caddyfile. Which, thinking of it, doesn't even require setting up a janky script for the rare times when I need to host a new service & modify the config.
I guess there's no reason to make things harder for myself 6 months in the future.
