71–80 of 172 posts
Earlier quoted context omitted.
You can't determine the file system structure from the URLs. The can map directly, but they don't have to Also... http?
Why not http? Secure connections add overhead. It's not like this site contains any secrets?
Depending on how much your write, URL collisions can naturally become a real problem. If you use a SSG then all your post HTML documents will be in the same directory, forever. This isn't a problem if you don't spit out posts, but if you post a lot your directory can become rather unwieldy. I'd say, at least throw a year in there: /2022/su/.
I manage this problem by appending a 5 digit number in front each file, ie. 00001-Hello-world.md that I strip from the URL. It solves multiple problems for me. 1. All articles are sorted automatically. 2. I can visually see how many drafts I have (drafts are 00000-, published at 00nnn-)
Earlier quoted context omitted.
My name is Dan Blows, and my domain is da.nblo.ws, which I thought was the coolest thing ever. Most people are confused or don’t even notice it.
I used to have a mail address along the lines of d@nblows.com But beware, single letter local parts are not universally supported by web sites. Microsoft accounts with those mail addresses are possible (they used to be impossible), but recently I stumbled upon two other web sites that didn't like single letter local parts.
You don't know what you don't know. Discovery is about leveraging common heuristics. The more context information that's available, the easier it gets to get to the answer. Giving the least amount of information runs counter to that.
A URL is a reference, an identifier, that uniquely references a resource. A search engine essentially captures a ton of context information that you can leverage to get to a set of relevant references. An identifier can be a meaningless string of characters - e.g. a UUID - and as long as it's accompanied with context information, you can get to the resource it references.
Conversely, if you capture context in the URL itself - meaningful words, dates, authors,... - you're actually providing a breadcrumb trail for visitors - people and robots - to follow, leveraging common heuristics they might use to get to that web resource directly. Might, because discovery is always a process of making educated guesses and following cowpaths to get to the right answer.
So, no, making URL's shorter isn't necessarily advantageous.
In the same vain: long passwords using commonly, easily to remember words instead of an unintelligible string of 16 characters.
Tangentially, I also have ambiguous feelings over the widespread use of URL shorteners. Partly because they act as a middle man providing brittle URL's that can - and will - break in the long run. Partly because they hide a ton of potential context information that might be captured in the original URL.
> You can tell someone. You can even say it out loud! Whether answering an email or talking to someone on the phone, I can say, “Go to sive.rs/ff for my talk about the first follower.” or “My newest book is at sive.rs/h.” I do this often, so having memorable URLs saves me a lot of searching.
Again, context matters. This might work if you want to highlight specific content - e.g. a marketing page for your book - but it certainly doesn't work all the time for all your content. Is that blogpost from 2007 really that important that you need to be able to "say it out loud" to someone on the phone today at any moment?
Short URL's come at a cost. What's the trade off you're making here?
> They look nicer. They’re aesthetic. They show care.
I don't care. Really. I don't. I care about readability and accessibility. Sure enough, URL's with tons of non-nonsensical query parameters are a blight, but this has more to do with readability then "aesthetics". It's an URL, not poetry.
> They remove the middle-man. With long URLs, people use those ugly social share buttons that promote (and further entrench) harmful social media sites, and add visual clutter to your site. Short URLs encourage people to copy and paste the URL directly, which lets them share it anywhere, instead of only the sites for which you have a share button.
Or maybe the answer here is to avoid using social share buttons on your website at all?
> They’re enough. Using 36 characters (a-z and 0-9): 4-character URLs give you 1,679,616 (36⁴) unique combinations.You don’t need more than that.
Well, how about "sive.rs/qxfa" or "sive.rs/kxig" or "sive.rs/ddiz"? It's an argument that's in direct contradiction with the author's first argument. Again, heuristics matter. Readability matters. A big chunk of those 1.6 million odd unique combinations aren't usable of the bat because they are simply unintelligible strings of characters without meaning.
Regarding the example of instead of hi.html just name the file hi and use the nginx Config “default_type text/html” —- is there an equivalent to this for other webservers (Eg Caddy etc) ? Perhaps it would be cleaner to just create a directory called hi with and index.html?
I don't understand the benefit of this at all. I've been dropping the ".html" from URls for ages now, not by modifying the filename, but using Apache's MultiViews. Apart from anything else, some tools still benefit from a filename's extension advertising that file's type, even if they shouldn't.
Seems perhaps similar to try_files for nginx that a sibling commenter referenced?
I don't like this at all - there is value in a hierarchical naming structure - even if it doesn't represent actual directories . A simple example is: https://www.kozubik.com/ ... where you can find "items": https://www.kozubik.com/items/ ... and one thing inside of "items" is an article on NDS emitters: https://www.kozubik.com/items/nds/ ... which contains supporting multimedia objects: https://www.kozubik.com/items/…
https://sive.rs/short-urls-why-and-how
would be much more valuable than