Hacker News Reader

Comment by hoten | Hacker News Reader

Another optimization in the same vein: make sure the first KB contains the <meta charset> element, to avoid false-starts in the HTML parser. In fact, it's actually specified as an _error_ in the spec to have it come after 1KB!

It's mentioned in passing on the Lighthouse docs for the charset audit[1], but here's a great breakdown by hsivonen[2].

Of course, in the headers is even better. Point is, try not to have too much cruft before the charset.

[1] https://web.dev/charset/

[2] https://github.com/GoogleChrome/lighthouse/issues/10023#issu...

View on HN

> Of course, in the headers is even better.

Yes, much better. And given prevalence of UTF-8 this days, why not just hard-code your webserver to add such header everywhere:

- Apache

  <VirtualHost ...>
    <Directory ...>
      AddDefaultCharset utf-8
        ...

- nginx

  http {
        charset utf-8;
        ...

- Caddy: done already with no explicit config required, yay!

Have to say, I absolutely love Caddy as a general webserver and reverse-proxy. Lightweight, easy to configure, relatively flexible, sane defaults.

I was skeptical coming from running my home server with nginx as a reverse proxy for a bunch of services, but caddy is a joy to use.

> easy to configure, relatively flexible, sane defaults

Compared to what? You think nginx is not easy to configure or has insane defaults somehow? Really baffled why people come out of the wood work to pile on beautifully architectured designs in favor of some random project they happen to like or just because it's written in a language they have a special affinity for like Go or something.

In terms of saner defaults: The charset="utf-8" default described above is one example. TLS enabled by default is another.

Also, you could asked all your questions without being incendiary and making assumptions about why people like Caddy. Nobody mentioned Go except you.

Have you used Caddy for reverse proxying compared to nginx? It's infinitely easier. Two lines per site, https built in, dynamic upstreams are handled by default, HTTP 2 enabled (maybe nginx does HTTP 2 by default,; not sure).

Easier in what sense? If you find the most esoteric feature and then claim it's easier for that purpose, that doesn't count! If you're going to claim it's easier to configure than nginx you have to make a fair comparison by comparing not the features that you care about, but instead the features that define the system as a whole.

I would think automatic support for TLS, no configuration necessary, would qualify?

You mean?

  certbot --nginx

You are missing the steps to install, setup, cronjob, for certbot.

What about HTTP->HTTPS redirection, etc?

Same for secure cipher selection.

All of that Caddy gives you in 1 line of config (i.e. domain name)

Funny you mention those because the line above automatically adds all those for you including https redir for all your vhosts.

The biggest thing you miss is that nginx doesn't do all this for you, you have to install a 3rd party thing to manage it.

If we allow your example, then caddy wins hands down because it also makes me rich because it fronts the websites that make me money.

But that would be ridiculous thing to claim Caddy does, because it doesn't do that itself.

While I understand your point, installing certbot isn't onerous at all and this is a strange thing to be arguing about.

Setting up TLS and reverse proxy to several upstreams. This isn't an uncommon use case.

nginx: https://github.com/shepherdjerred/servers/tree/8688ba2086d87...

caddy: https://github.com/shepherdjerred/servers/tree/main/zeus/con...

I have a feeling you're think we're attacking nginx. I can't speak for the other poster, but I have huge respect for nginx. It's a great piece of software and it's what I'd reach for in production.

I'm not sure that Caddy is a good choice for production, but for my hobby work it is just so much easier to use.

Neat comparison!

(And Caddy is an excellent choice for production. Or so says the many companies now powering half a million sites with it!)

I looked into nginx as a replacement for Apache a few years ago and gave up because of the weird dichotomy between open-source nginx and commercial nginx. There seemed to be a lot of FUD about the OS version coming from the commercial people so I moved on.

With the announcement a couple of days ago that the commercial nginx folks are embracing OS again I might take another look.

I didn’t know there was a commercial version. What are the advantages of using that over open source version?

I wish I knew. Hence my comment about FUD.

https://news.ycombinator.com/item?id=32572153

The paid version (nginx plus) has a few additional features that you often end up needing/wanting (the dashboard for example, for ops users) in enterprise environments.

For what its worth, I switched from nginx to Caddy years ago and haven't looked back - Caddy's built in support for LetsEncrypt and zero configuration for the most common reverse proxy scenarios is just too compelling to ignore now - the speed and ease with which one can throw up an SSL front end with valid letsencrypt cert is amazing.

The Caddy website has it written

"Caddy is a powerful, extensible platform to serve your sites, services, and apps, written in Go"

That could confuse developers thinking they can only develop apps in Go with caddy?

English is my second language, and the comma separating that particle from the rest of the sentence makes it pretty explicit even for me that it is talking about the platform, at the same semantic level as “powerful”, “extensive” and “to serve your sites […]”.

Yes, but the incongruousness of telling me what language something is written in in its sales one-liner makes me think it must be pitching itself as "especially for apps written in Go", because who thinks I am going to pick a tool because it is written in Go? "Try ElasticSearch, written in Java!"

I avoid new server software written in languages with too many footguns such as c or php. Nginx gets a grandfather exception, but I'm not sure I would have extended one to caddy.

I would, Go and Rust are fast compiled languages and I would absolutely pick something written in those over alternatives.

And bit ironic considering the portability of Go enables one to develop a web service with built-in packages without requiring an explicit web server.

Reply on news.ycombinator.com