This site doesn’t allow posts without JavaScript.
It’s not clear why caddy 2 is needed.
It’s not immediately apparent how to serve css or js
Your marketing would grab more beginners if you stated in a paragraph length page what problems caddy solves.
“WordPress alternative”
“Site hosting”
" Make my own website"
“Serve html with JavaScript”
“Write URLs with dots instead of slashes”
The examples github is too messy.
Now that nginx has gone corporate via Goldman Sachs, you can use “non-corporate” to stand out.
http.root doc.
Never use a word in its own definition.
Same with http.rewrite.
“Simple” and “complex” aren’t useful descriptions.
The community forums are run on the Discourse platform. JavaScript is a requirement.
Caddy 2 is needed because Caddy 1’s design necessitated some inflexibility in certain areas. Caddy 2 brings all the convenience of Caddy 1, but with incredible versatility in handling.
CSS and JS are usually just files. They are served the same way the index file is served. If you’re familiar with other web servers, this concept remains the same.
Caddy is web server software. It does not have its own content (e.g. “WordPress alternative”), it serves the content you configure it to (i.e. you can serve WordPress via Caddy). It is not site hosting; you need a server to run Caddy on. Caddy is also not a website builder. Serving HTML with JavaScript is done the standard way it has been done for decades with all web servers - put the files in the web root. Writing URLs with dots instead of slashes… hmm. I don’t actually think this can be done. It’s certainly not conventional. I wonder if any web server would handle this? And if so… Why?
The examples on Github are aimed at server administrators who would be configuring Caddy - these are Caddy’s “users”. People who are looking for a web hosting provider are most likely a whole step removed from the kind of people who will be deploying Caddy.
The docs don’t define the meaning of a root here. That’s industry standard terminology. They are defining the root directive for Caddy, which sets the web root.
In Caddy v1, simple and complex are descriptors used to differentiate between one-liner rewrites and rewrites with configuration blocks. If you find this differentiation useless, you are welcome to ignore it, but the difference is present all the way down into the actual directive’s code, where the terminology comes from.