Does it make the URL in the URL bar longer? Yeah, but does that matter?
No, it doesn't.
If you're using a central system to generate id's (UUID's or other), then you are indeed missing a lot of the benefits of UUID's and might as well use some other ID scheme.
The benefits of UUID are many systems can generate them, and your database can eventually accept them, all with a very high guarantee of uniqueness/no-collisions. Not to mention the other nice bits like non-sequential and non-enumerability.
Most modern databases have UUID/Binary types/functions to allow for more efficient storage/handling anyway.
I appreciate shorter URLs any time I copy and paste them, which always involves looking at them and sometimes involves scrolling to the end to remove tracking- and search-related fluff.
128 bits is an absurd amount for a unique ID within a single system. Even 48 bits is very, very large -- enough to provide a unique ID (MAC address) to every Ethernet device made for something like 100 years.
The purpose of a UUID is to provide a negligible probability of collisions between randomly-generated IDs in a global space forever. Almost no applications require that, so most of the time using a UUID is just needlessly taking up space.
What you want is that the number of possible items to enumerate is significantly less than the square root of the cardinality of the ID range, means you can relatively safely randomly generate IDs with few collissions.
I'm really reaching here, but an ID that omits special characters is easier to extract from a url, since it can be double-clicked in a URL bar to select it, whereas a GUID with hyphens forces the user to select the beginning and the end of the string.
Realistically I think this matters to developers more than users (I hope your application doesn't force users to interact with GUIDs in the address bar) but that's the only "waste" I can identify.
EDIT: Someone elsewhere noted that they can base64 encode their GUIDs to achieve this and I'm seething that I'd never thought to do that
(Maybe that's what you meant, amd yes, it's still clunkier than simply double clicking, but not much)
Maybe the double-click logic needs to be less stupid then. Or have it progressive, e.g. double-click = alphanumeric, triple-click = stop at symbols, quadruple-click = stop at slashes only, quintiple-click = the whole URL.
Use the device microphone to listen for swear words and adjust algorithm with machine learning accordingly
I usually did that in .NET simply because I thought it was prettier without the hyphens.
The is-hyphen-part-of-a-word issue depends on the text control (browser, UI widget library, …) / terminal you use, which is not universal.
In any case, the hyphens/dashes are not required part of the representation, and one can use the “dashless” representation (exactly 32 hex digits) in URLs and in-code without any issues whatsoever, as far as I know; for example, Postgres accepts either “dashful” or “dashless” UUIDs the same.
UUIDs are at least visually kind of white noise, companies have no problem+with+links?that=look&like=this, so why do they care about UUIDs?
You can't beat that. Or would you rather receive texts that include the following?
https://www.amazon.com/dp/B09V3HZ8B5/?pd_rd_w=DAycy&content-id=amzn1.sym.04e31e32-5e01-4048-8b59-a557891d595f:amzn1.sym.04e31e32-5e01-4048-8b59-a557891d595f&pf_rd_p=04e31e32-5e01-4048-8b59-a557891d595f&pf_rd_r=M1KXM468KNZJV189JBE7&pd_rd_wg=3O1uC&pd_rd_r=e51c1edc-213f-4c6d-b081-e23afa6bf4ab&ref_=vn_s_iwp&qid=1694453553
Let's not match the lowest common denominator, shall we?
As you have been told apple.com/iphone = www.amazon.com/dp/B09V3HZ8B5
The rest of what you posted on the Amazon link is tracking bullshit. Now, THAT is irrelevant !
Amazon product URLs are looong, but maybe people don't share them enough for Amazon to care. YouTube and Twitter put more effort into making them short.
So you could have urls like:
example.com?<a single icon>&productname=somethinghumanreadable
A more "apples to apples" comparison (pun intended) would be the MagSafe charger:
https://www.apple.com/shop/product/MHXH3AM/A/magsafe-charger...
I'm sure they put some thought into not making it ?v=f6dde15a-3485-4f36-b0b9-a3b56fbc12ae.
Yes. That's one of the author's arguments.
) A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from an user’s perspective.
"Does it matter" is a very reasonable response to someone expressing their opinion.
If I say "x matters and here's why" and you respond "yeah but does x matter?", you're either not paying attention or being rude and dismissive.
And what do they mean with communication? Reading it aloud? If the URL is too long to stick in a tweet or message, there are plenty of URL shorteners out there.
On link-sharing sites like this one, we care about the URL’s we share and will often strip off the tracking stuff.
And I bet that for most users 3c6n63N is as confusing as a73ba12d-1d8b-2516-3aee-4b15e563a835
You don't need to make it a user exposed identifier, and you can have a centralized (but out-of-the-critical-path) process assigning friendly IDs if you can afford visibility delays (for either the whole item or at least the friendly ID, which if it is the only user-facing locator may mean that the individual item can’t be directly accessed even if it is visible in aggregates, until that is assigned; if you allow access by both the UUID and the friendly ID, with the latter presented as preferred once available, this is resolved but this may appear messier.)
Others have noted the usefulness of generating ids for user-created data without involving the server, while being able to post that data at a later time without worrying too much about collisions.
Suspenders-and-belt practice would of course dictate that the server do some type of collision detection and mitigation before storing the received data.
If UUID exists in database and user ID is different, tell client "Yo, we've got a collision here. Your new ID for this data is blah".
Generate new UUID. If I've ever used that UUID before, generate a new one.
If the server rejects my UUID, switch to the new one provided by the server
Personally, I'd look on home-brewed solutions for generating unique "friendly ids" with the same deep suspicion I look at home-brewed crypto, particularly if this were done client-side for multiple clients without involving a server round-trip. Getting it right is a Hard Problem. The perceived complexity of UUIDs is there precisely because it is a Hard Problem.
It might, e.g. with embedded systems. I can neither confirm nor deny that we once BOFed our own devices because we assumed that 1200 bytes was a big enough buffer to hold a URL.
Nowadays many links are much longer because of referrer information and tracking parameters. So the UUID doesn't add much.
Not that people will care. Once a URL is longer than a few words plus a code most users won't even look, even if they bother that far. You'll be in danger of starting to hit some browser/server/proxy limits though.
Not that I mind that sort of information being lost, I'm happy for the incessant tracking of everyone's everything these days needs to go to hell.
Address bar: https://www.youtube.com/watch?v=SHWhKRKlG98
Share button: https://youtu.be/SHWhKRKlG98?si=gwQHHze3UnjTobJg
You've never needed to give an order number, member ID, account ID, invoice number, etc?