Да, callback setTimeout'а выполняется в том же потоке, что и основной скрипт. Да, ответы от сервера тоже все выполняются в одном потоке строго по очереди. И да, места на экране тоже будут апдейтиться по очереди.
Именно поэтому при написании асинхронных скриптов (я про JS сейчас в основном, на других не писал) нельзя допускать, чтобы какой-то синхронный блок долго выполнялся, зависнет всё. В браузерном JS это легко наблюдается зависанием браузера, т.к. пока выполняется JS даже браузер ничего не делает, не то что какие-то другие потоки.
> правда extsrc выглядит в этом случае даже лучше.
Не лучше, у document.write своя семантика, у innerHTML — своя.
Просто нужно описать этот нюанс в документации.
1. После document.write('<a href="#">') никаких document.write не будет. Просто текст после тега script станет ссылкой. Поэтому в буфере будет лежать битый html.
3. Можно просто current_script.parentNode.insertBefore(span, current_script.nextSibling).
document.write не совсем честный получается. Ситуации достаточно специфичные, но всё же.
1. То, что пишет document.write не приводится к нормализованному html. Например, мы можем написать document.write('<a href="#">') и всё, что дальше, будет считаться ссылкой, пока не встретиться </a>
В случае innerHTML текст сначала нормализуется в правильный html, потом вставляется в документ.
2. В случае, если внешний скрипт с extsrc с помощью document.write создаст ещё один внешний скрипт, а тот, в свою очередь, тоже вызовет document.write, то всё сломается, т.к. к моменту вызова последнего document.write он (document.write) уже родной, а не ваш переопределённый. По крайней мере в Firefox так, в остальных не смотрел.
Ну и несущественное замечание: генерируемый с помощью document.write контент добавляется после текущего script, а не перед. Это не важно, но так, для справки.
Сервер передаёт в обработчик запроса два объекта: request и response. У response есть метод end(), который и сообщает, что надо закончить передачу данных. Пока он не вызван, загрузка не закончится.
Всегда использовать асинхронные. Любой синхронный вызов уменьшает количество запросов (http-запросов от пользователей), которые может обработать скрипт.
Перебор свойств объекта, разумеется, такой и должен быть. Перебор элементов массива так делать нельзя, и hasOwnProperty может не спасти, т.к. у самого массива могут быть нечисловые свойства.
Именно поэтому при написании асинхронных скриптов (я про JS сейчас в основном, на других не писал) нельзя допускать, чтобы какой-то синхронный блок долго выполнялся, зависнет всё. В браузерном JS это легко наблюдается зависанием браузера, т.к. пока выполняется JS даже браузер ничего не делает, не то что какие-то другие потоки.
Не лучше, у document.write своя семантика, у innerHTML — своя.
Просто нужно описать этот нюанс в документации.
el.innerHTML = '<a href="#">' «напишет» в элемент el '<a href="#">'</a>, т.е. тег a автоматически закроется.
Если не будет nextSibling, то insertBefore будет работать как appendChild, т.е. добавит в конец.
3. Можно просто current_script.parentNode.insertBefore(span, current_script.nextSibling).
1. То, что пишет document.write не приводится к нормализованному html. Например, мы можем написать document.write('<a href="#">') и всё, что дальше, будет считаться ссылкой, пока не встретиться </a>
В случае innerHTML текст сначала нормализуется в правильный html, потом вставляется в документ.
2. В случае, если внешний скрипт с extsrc с помощью document.write создаст ещё один внешний скрипт, а тот, в свою очередь, тоже вызовет document.write, то всё сломается, т.к. к моменту вызова последнего document.write он (document.write) уже родной, а не ваш переопределённый. По крайней мере в Firefox так, в остальных не смотрел.
Ну и несущественное замечание: генерируемый с помощью document.write контент добавляется после текущего script, а не перед. Это не важно, но так, для справки.
Ваш пример будет выглядеть приблизительно так
А сервер не останавливается даже если запросов нет, иначе кто на запросы отвечать будет.
alljs.ru/articles/array/iterators.html#every-some
Использовать every или some, а не forEach.