ince

Без разницы что, например
https://stackoverflow.com/questions/10286204/the-r...

2012-04-23T18:25:43.511Z

Here's why:

It's human readable but also succinct

It sorts correctly

It includes fractional seconds, which can help re-establish chronology

It conforms to ISO 8601

ISO 8601 has been well-established internationally for more than a decade

ISO 8601 is endorsed by W3C, RFC3339, and XKCD

Нет. Готовых функций нет.

Хотя сделать такое не сложно. Главное, знать, что хотеть. Из ваших примеров это ни разу не очевидно. В них не прослеживается закономерность и куча несостыковок. Вероятно, вы очень спешили, когда их составляли. Так что я даже не уверен, что вы сами знаете, что вам нужно. Но зато я уверен, что как только вы начнете делать (или начнете составлять ТЗ), то сразу поймете, что вам нужно, а что не нужно.

Когда сделаете свою функцию, не поленитесь вернуться в этот вопрос и проверить, насколько же сильно результат функции отличается от ваших примеров.

Тут Вам по кусочкам дали ответ, осталось собрать воедино, чтобы было понятно что к чему. Далее по пунктам:

1) Первое и самое главное здесь то, для чего вообще это хеширование нужно. Правильный ответ Вам дали "олды", о которых Вы сами упомянули, + Сергей Горностаев привел пример отличной книги, где об этом можно почитать подробнее. Если в двух словах, то в распределенных базах данных(когда они хранятся в более чем одном экземпляре) прежде чем сохранить какую-то информацию в какой-то из экземпляров нужно для начала понять, а в какой именно экземпляр должны сохраняться определенные данные. Вот представьте, Вы регистрируетесь в инстаграм, там сотни экземпляров баз данных, как им определить в какой вас сохранить? И тут как раз вступает в дело та самая хеш-функция по каким-то уникальным данным(например по мэйлу или по номеру телефона), которая дает на выходе число. Именно это число определяет в какой экземпляр базы данных сохранить конкретного пользователя(чаще всего там используют деление по модулю на количество экземпляров, ну об этом подробнее можете прочитать в книге, о которой говорилось).

2) Теперь о том, почему это используют как id вместо обычных чисел. Причин может быть на самом деле много, я вам приведу сейчас самую наглядную, а подробнее уже сами потом изучите. Как говорилось выше, распределенная база данных это множество разных экземпляров баз данных, где в каждом экземпляре свои данные. Вот представьте, что у нас 10 разных экземпляров. И хеш-функция по вашему логину указала, что вас нужно сохранить в экземпляр №6. А по моему логину хеш-функция показала, что меня нужно сохранить в экземпляр №3. Тогда что получается: и я и вы теперь записаны в таблицу Users, только ваша таблица Users не имеет никакого отношения к моей, потому что эти таблицы находятся в разных базах данных. То есть логически это одна база данных, но по факту это разные экземпляры. И если бы мы с вами были первыми пользователями и в качестве id использовались бы обычные числа(например автоинкрементные поля), то в базу данных записалось бы два пользователя с одинаковым id(если мы первые пользователи то оба получили бы id=1 каждый в своей базе), что является катастрофой. Так вот чтобы избегать подобных ситуаций, используются специальные идентификаторы, которые называются uuid. Все популярные СУБД имеют встроенную поддержку таких идентификаторов и способы их генерации. Однако насколько я понял в вашем случае вместо использования встроенных функций для генерации uuid разработчики используют результат хеш-функции в качестве этого самого uuid, что довольно классное решение на мой взгляд. А что касается производительности - результат этой хеш-функции это такое число в шестнадцатиричном виде(только чуть больше, 20 байт против 16 у uuid), как классический uuid, поэтому производительность вряд ли пострадает.

document.querySelectorAll("option[value='0']")

Нет, ключ в любом случае будет string

Но такое свойство у вас не получится создать: { %42: true }, а так получится { "%42": true }

Например использовать async/await:

async function foo(val = 0) {
  const response = await request(val); //предполагается, что request возвращает promise
  if (response.error) throw new Error('something bad happened');
  //делаем что-то с response
  foo(response.newVal); //вызываем foo с новым val
}

function recursiveRequest(requestData) {
  return fetch(
    //здесь формируем запрос из requestData
  ).then(response => response.json()).then(result => {
    if(result.isFinal) return result; // тут условие
    return recursiveRequest(result.nextRequest); //вызываем следующий запрос
  });
}

recursiveRequest({}).then(finalResult => {
  //работаем с последним результатом
});

Полифил

Нигде. Для зон .ru/.su/.рф - требование технического регистратора (оператора зон) - наличие паспортных данных. Да, можно нарыть паспорт бомжа Васи и зарегить на него. Если проект бросовый - нагадить и забыть - так можно делать. Если проект ценный, то при любом спорном моменте Вы просто не докажете, что домен Ваш. И проблемы - внезапно - могут перевесить не-анонимность...

рассмотрим на примере кипячения чайника со свистком - тебе нужно скипятить воды, ты налил чайник, и поставил его греться.
1) синхронно ты стоишь ждешь пока он скипит и не приступаешь к другим делам
2) асинхронно ты ушел в комнату гладить рубашку, погладил, вернулся на кухню и независимо от того скипел чайник или нет, ты его снял с плиты и налил воду
3) в режиме прерывания ты ушел в комнату гладить рубашку, чайник просвистел, ты прервался, пошел снять его с плиты

в js так же,
1) пока выполняется один синхронный метод движок не переходит к выполнению второго
2,3) движок запускает асинхронную функцию и не дожидаясь получения результата переходит к выполнению следующего метода, когда асинхронная функция закончит свое выполнение она уведомит движок и он по возможности прервется для получения и обработки результата