Some famous programmer once wrote about how links should last forever.
He advocated for /foo/bar with no extension. He was right about not using /foo/bar.php because the implementation might change.
But he was wrong, it should be /foo/bar.html because the end-result will always be HTML when it's served by a browser, whether it's generated by PHP, Node.js or by hand.
It's pointless to prepare for some hypothetical new browser that uses an alternate language other than HTML and that doesn't use HTML.
Just use .html for your pages and stop worrying about how to correctly convert foo.md to foo/index.html and configure nginx accordingly.
> Some famous programmer once wrote about how links should last forever.
You're probably thinking of W3C's guidance: https://www.w3.org/Provider/Style/URI
> But he was wrong, it should be /foo/bar.html because the end-result will always be HTML
20 years ago, it wasn't obvious at all that the end-result would always be HTML (in particular, various styled forms of XML was thought to eventually take over). And in any case, there's no reason to have the content-type in the URL; why would the user care about that?
There's strong precedence for associating file extensions with content types. And it allows static files to map 1:1 to URLs.
I agree though that I was too harsh, I didn't realize it was written in 1998 when HTML was still new. I probably first read it around 2010.
But now that we have hindsight, I think it's safe to say .html files will continue to be supported for the next 50 years.
If it's always .html, it's cruft; get rid of it. And what if it's not HTML but JSON? Besides, does the user care? Berners-Lee was right.
https://www.w3.org/Provider/Style/URI
If it's JSON then name it /foo/bar.json, and as a bonus you can also have /foo/bar.html!
You say the extension is cruft. That's your opinion. I don't share it.
The alternative is to declare what you want on the Accept header, what is way less transparent but is more flexible.
I never saw any site where the extra flexibility added any value. So, right now I do favor the extension.
At the risk of committing the appeal-to-authority fallacy, it's also the opinion of Tim Berners-Lee, which I would hope carries at least some weight.
The way I look at it is that yes, the extension can be useful for requesting a particular file format (IMO the Accept header is not particularly accessible, especially if you are just a regular web browser user). But if you have a default/canonical representation, then you should give that representation in response to a URL that has no extension. And when you link to that document in a representation-neutral way, you should link without the extension.
That doesn't stop you from also serving that same content from a URL that includes the extension that describes the default/canonical representation. And people who want to link to you and ensure they get a particular representation can use the extension in their links. But someone who doesn't care, and just wants the document in whatever format the website owner recommends, should be able to get it without needing to know the extension. For those situations, the extension is an implementation detail that is irrelevant to most visitors.
> it's also the opinion of Tim Berners-Lee, which I would hope carries at least some weight
Not at all. He's famous for helping create the initial version of JavaScript, which was a fairly even mixture of great and terrible. Which means his initial contributions to software were not extremely noteworthy, and he just happened to be in the right time and right place, since something like JavaScript was apparently inevitable. Plus, I can't think of any of his major contributions to software in the decades since. So no, I don't even think that's really an appeal to authority.
> [Tim Berners-Lee is] famous for helping create the initial version of JavaScript
You may be thinking of Brendan Eich? Berners-Lee is famous for HTML, HTTP, the first web browser, and the World Wide Web in general; as far as I know he had nothing to do with JS.
Found it: https://www.w3.org/Provider/Style/URI
Why did I think Joel Spolsky or Jeff Atwood wrote it?
I use /foo/bar/ with the trailing slash because it works better with relative URLs for resources like images. I could also use /foo/bar/index.html but I find the former to be cleaner
It's always bothered me in a small way that github doesn't honor this:
https://github.com/sdegutis/bubbles
https://github.com/sdegutis/bubbles/
No redirect, just two renders!
It bothers me first because it's semantically different.
Second and more importnatly, because it's always such a pain to configure that redirect in nginx or whatever. I eventually figure it out each time, after many hours wasted looking it up all over again and trial/error.
mod_rewrite means you can redirect the .php page to something else if you stop using php.
Unless mod_rewrite is disabled, because it has had a few security bugs over the years. Like last year. [0]
[0] https://nvd.nist.gov/vuln/detail/CVE-2024-38475