It’s ok to use JavaScript generated GUID in a browser?

No. But we live in distributed and disconnected world. And we also like optimistic UI’s. Why should I wait for “foo created” server response anytime internet isn’t available or is terribly slow? Therefore every sane web apps must maintain client side model. Then we can just create “foo”, modify or delete it later, and wait for server response. Sync asap is better than waiting for save.

So we need client side generated ID’s. But GUID is not a solution. It’s huge, ugly, and impossible to generate properly in a browser. What if we just use incremented ID, and replace it with real GUID after sync? No, that’s not possible too, because we need to project ID into URL for app navigation, and updating ID would break browser back/forward buttons.

The solution I’m using is UEID — Unique enough ID. It’s random string looking like that: sn1s7vb4gcic. It’s short and all, but can it replace GUID? No. It’s limited to user scope. For one user, it’s unique enough. For other users, it must be replaced with real GUID or server side generated ID, and then a new type will be created anyway, e.g. mySong -> publishedSong.

UEID can be generated with such function: goog/string/string.js#L1177.