V Sh.

AJAX-приложение не работает с другими страницами, это в корне неверный подход. Такое приложение работает с данными, которые асинхронно отдаёт ему сервер. Т.е. всё необходимое у вас уже должно быть на странице, а рулите вы только данными.

По уму даже responseText юзать неправильно (т.е. получать HTML). От сервера вы должны получить либо XML, либо JSON, а формировать HTML нужно уже на клиенте.

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

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

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

Стартовый внутренний таймер - задаёт сервер по UUID девайса, шифрует его и кладет рядом с приложением.
Свой таймер держите внутри приложения с необходимой временной шкалой.
1 секунда прошла timer++
еще одна прошла timer++
Перевод часов тут - не особо спасёт.

Никому не нужны ваши данные. Перестаньте думать, что все вокруг хотят вас обмануть.
Если бы фрислансеры крали\сливали инфу, то никто бы с ними не работал.

>Я полагаю что можно перенести магазин на другой сервер, там удалить клиентов и заказы, поменять пароли и можно безопасно нанимать фрилансера.
Только потом вы будете сами всё переносить и делать все необходимые настройки. И если что-то не будет работать - я пошлю вас далеко, так как работу я сделал.

Из моего предыдущего ответа на схожий вопрос:
Вы у врача тоже просите его осмотреть вас в одежде, не вынимания рук из карманов и на расстоянии 20км?

Фрилансеры каждый день работают с чужими сайтами с конфиденциальной информацией им эти данные не интересны. Да можете измудриться и вынести всё это отдельно но только жизнь осложните себе и фрилансеру и в конце всё равно дадите ему доступ к основному серваку что бы правки внедрить всё же.

Написать метод расширения ToMyCoolString() будет быстрее чем поиск

В таком подходе один большой минус: вы никогда не узнаете почему автор написал именно так. Код обычно составляет ~25% всех знаний автора. И возможно, что к именно такому решению он пришел только после 10 разных прототипов. Либо учите теорию, чтобы была полная картина в голове, либо так, как хотите вы. Но это получается зубрежка и прокатит только на экзамене.

При чем здесь Тостер? Пиши в техподдержку

В стандартной схеме каждый следующий уровень требует больше опыта. Эта схема позволяет получить ощущение прогресса практически нахаляву. Т. е. вы можете пропорционально уровню увеличивать опыт за монстров/квесты, чтобы скорость получения уровней была неизменной, но ощущение продвижения, роста ставок всё равно останется. Кроме того, у вас появляется контроль над распределением уровней игроков. Если вы захотите уменьшить количество высокоуровневых игроков или повысить престиж эльфа восьмидесятого уровня, вы просто корректируете формулу в одном месте, и готово.

В случае с равноценными уровнями вы отодвигаете опыт на второй план, эффект писькомерки снижается. Кроме того, сложнее управлять прогрессом игрока, например, как замедлить получение уровней? Давать меньше опыта? Давать столько же опыта, но сделать сильнее врагов? Оба варианта могут восприниматься нечестными со стороны игрока. Не факт, что вам пренепременно нужно влиять на количество высокоуровневых игроков, но, может быть, у вас экономика развалится, если все игроки будут максимального уровня, или ещё что.

Короче говоря, нельзя просто взять и выставить для каждого уровня одинаковое количество опыта. Оба варианта жизнеспособны, но будьте готовы к тому, что вам придётся корректировать дизайн в других местах, чтобы ничего не развалилось.

в первичный ключь может входить любой тип (алфавитный - только до 128символов или 256 - зависит от огранизации в СУБД. если поле больше, то остальные символы не учитываются при создании ключа). Так же в ключь может входить не одно поле, а несколько и с разными типами. Но самая высокая скорость работы именно с ключами типа integer. Некоторых СУБД специально оптимизируют код обработки ключей с такими типами, что бы добиться наивысшей скорости работы с подобными сурогатными ключами.

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