3 ms·

Also the lack of 20 years of optimization where it spent a lot of time as one of the larger open source web servers and so got a lot of attention. In 2024 peop

Also the lack of 20 years of optimization where it spent a lot of time as one of the larger open source web servers and so got a lot of attention. In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers.

nickjj 2y ago
> In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers. This seems like a weird trade off to me. The "learning tax" is really only paid once with nginx. Once you understand how it works and configured a reasonably end-to-end example with it then you can carry that over to your next project with minimal changes. I've hosted countless Flask, Django, Rails, etc. apps over the years and very little changes on the nginx side of things. I'd rather learn this tool once and have better runtime performance all the time across all projects. With that said, the performance difference probably won't be very noticeable for most sites but still, I personally wouldn't want to give in to running a less efficient solution when I know a more efficient solution exists right around corner that requires no application code changes to use -- just a little elbow grease to configure nginx once. This is especially true when nginx has a ~20 year track record of stability and efficiency.
- jacob019 2y ago
  Right. Everytime nginx comes up someone has to bring up how much better caddy is. After using nginx everywhere for nearly two decades I have no desire to learn a new tool. Nginx does everything I want, even some exotic stuff and plugins for certain use cases. It is highly configurable, has plenty of good documentation, is well supported in every distro, and is extremely performant. I don't care how much easier caddy is and that it can configure certs for me. I prefer the unix philosophy anyway, and it's not like I'm spending a significant amount of time on nginx configs or certs. I use acme.sh for certs it only takes a couple minutes to provision a new instance with nginx and acme.sh, just the way I want it. End rant.
  - lelanthran 2y ago
    > I don't care how much easier caddy is and that it can configure certs for me. I always find this a weird selling point, TBH. It's probably a selling point for people who don't already know the existing $FOO. For me, putting effort into learning the new thing only to use it exactly as the old thing is wasted effort. I don't know what I gain by moving to the new $FOO, usually.
  - tempest_ 2y ago
    Sure, but you list of things there describes a work flow that is becoming a bit old. I would wager the vast majority of Nginx "installs" are running in a container now a days. The distro doesnt matter and few are provisioning an instance of anything, that's some container orchestration job. Last week trying to coax nginx to be able to set a CSP nonce in a web apps index.html which apparently meant I would need to custom build Nginx or a custom build a container with a custom built Nginx to install a plug-in to do it. This type of stuff adds up and having a bunch of stuff hidden in Nginx Plus doesn't help either. I think Nginx is a great piece of software its just that people don't need all its offerings, they just want to host some tiny js and proxy to an API and things like caddy were built for that. The limited throughput doesnt matter when CloudFlare or Cloud front cache most of the things it is serving anyway.
    - jacob019 2y ago
      I'm pretty much always in a container too, and I'm perfectly happy with the workflow, it scales just fine and can be orchestrated as well. When I'm deploying a new project, bringing up a new container with nginx is like 0.1% of the work, why mess with that? I like Debian, I use it in my containers. Yes there are slimmer and lighter things, I don't care, my stack is rock solid. As for the CSP nonce, I'm surprised that there isn't a plugin, but compiling isn't a big deal, just annoying. Alternately NGINX is scriptable or you can do it at the application level as well. If caddy is easier for you or for that use case, then that's great, use it with my blessing.
_cenw 2y ago
I'd consider only pushing 20Mbps on a 2.5GbE network more than a lack of optimization. Supposedly you can tune some buffer sizes to make it better, but it's still laughably bad for serving larger files.

nickjj 2y ago

> In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers. This seems like a weird trade off to me. The "learning tax" is really only paid once with nginx. Once you understand how it works and configured a reasonably end-to-end example with it then you can carry that over to your next project with minimal changes. I've hosted countless Flask, Django, Rails, etc. apps over the years and very little changes on the nginx side of things. I'd rather learn this tool once and have better runtime performance all the time across all projects. With that said, the performance difference probably won't be very noticeable for most sites but still, I personally wouldn't want to give in to running a less efficient solution when I know a more efficient solution exists right around corner that requires no application code changes to use -- just a little elbow grease to configure nginx once. This is especially true when nginx has a ~20 year track record of stability and efficiency.

jacob019 2y ago
Right. Everytime nginx comes up someone has to bring up how much better caddy is. After using nginx everywhere for nearly two decades I have no desire to learn a new tool. Nginx does everything I want, even some exotic stuff and plugins for certain use cases. It is highly configurable, has plenty of good documentation, is well supported in every distro, and is extremely performant. I don't care how much easier caddy is and that it can configure certs for me. I prefer the unix philosophy anyway, and it's not like I'm spending a significant amount of time on nginx configs or certs. I use acme.sh for certs it only takes a couple minutes to provision a new instance with nginx and acme.sh, just the way I want it. End rant.
- lelanthran 2y ago
  > I don't care how much easier caddy is and that it can configure certs for me. I always find this a weird selling point, TBH. It's probably a selling point for people who don't already know the existing $FOO. For me, putting effort into learning the new thing only to use it exactly as the old thing is wasted effort. I don't know what I gain by moving to the new $FOO, usually.
- tempest_ 2y ago
  Sure, but you list of things there describes a work flow that is becoming a bit old. I would wager the vast majority of Nginx "installs" are running in a container now a days. The distro doesnt matter and few are provisioning an instance of anything, that's some container orchestration job. Last week trying to coax nginx to be able to set a CSP nonce in a web apps index.html which apparently meant I would need to custom build Nginx or a custom build a container with a custom built Nginx to install a plug-in to do it. This type of stuff adds up and having a bunch of stuff hidden in Nginx Plus doesn't help either. I think Nginx is a great piece of software its just that people don't need all its offerings, they just want to host some tiny js and proxy to an API and things like caddy were built for that. The limited throughput doesnt matter when CloudFlare or Cloud front cache most of the things it is serving anyway.
  - jacob019 2y ago
    I'm pretty much always in a container too, and I'm perfectly happy with the workflow, it scales just fine and can be orchestrated as well. When I'm deploying a new project, bringing up a new container with nginx is like 0.1% of the work, why mess with that? I like Debian, I use it in my containers. Yes there are slimmer and lighter things, I don't care, my stack is rock solid. As for the CSP nonce, I'm surprised that there isn't a plugin, but compiling isn't a big deal, just annoying. Alternately NGINX is scriptable or you can do it at the application level as well. If caddy is easier for you or for that use case, then that's great, use it with my blessing.

_cenw 2y ago

I'd consider only pushing 20Mbps on a 2.5GbE network more than a lack of optimization. Supposedly you can tune some buffer sizes to make it better, but it's still laughably bad for serving larger files.