Вытесняемая многозадачность, события и один поток в одном предложении, как мне кажется, образуют какую-то кашу. Под вытеснением обычно же понимают тот факт, что поток исполнения может переключится не по своему желанию. В этом же случае если сопрограмма написана криво, то она захватит поток исполнения навечно, разве нет?
Чем больше в книге express, тем меньше ее полезность в будущем. Тем более, что уже есть koa, использующий генераторы и написание асинхронного кода в синхронном стиле. А в скором времени появится async/await. На текущий момент все слишком быстро меняется, только базовая информация по node актуальна и полезна долгое время.
Как же все знакомо) А в вашей реализации есть какие-то интересные отличия от sharejs.org (как самый простой пример) или от OT алгоритма, лежащего в основе Google Docs? Было интересно послушать. Кроме undo, животрепещущий вопрос работы в офлайне.
Отличная сравнительная таблица webpack.github.io/docs/comparison.html показывает, что и какой сборщик модулей умеет. Особенно впечатляет параметр Runtime overhead у webpack.
Асинхронный и многопоточный — это не одно и тоже.
По умолчанию есть только один поток, которые асинхронно обслуживает очередь сообщений.
В браузере для многопоточности есть WebWorkers, но единственное возможное общение между потоками осуществляется через отправку строк или сериализованного в строку JSON-а, к одним и тем же переменным из разных воркеров обратиться нельзя.
Наверное, есть еще какие-то теоретические возможности это оптимизировать, но применимо ли это к тому же V8. Поток исполнения один, синхронизировать между потоками не нужно. Насчет константы тоже не факт.
Requirejs… Используйте CommonJS модули в комплекте с browserify или webpack. У них runtime меньше, в мир npm интегрироваться проще.
Статья уже устарела на несколько лет.
К сожалению, изменять href у ссылки — не самый кроссбраузерный способ. В IE отсутствие 80 дефолтного для http порта трактуется иначе, чем в других браузерах. Вот тут чуть подробнее.
Или, например, вспомнить frontend и разработку на js. В одном браузере работает, в другом нет, а в третьем вроде все правильно, но все-таки немного по другому. И это очень часто. Не говоря уже о бесконечном количестве js-библиотек, которые появляются, как грибы после дождя, которыми уже пользуются тысячи программистов, но у которых под 300-500 issues на github.
Поэтому умение быстро найти в багтрекире то, с чем сам столкнулся, для программиста необходимо. И не нужно этого бояться. Это нормальный рабочий процесс.
Текст без смайликов начинает казаться то ли грустным, то ли каким-то суровым — у моих собеседников и иногда у меня возникает такое ощущение, если общаемся в соц сети.
Для текста без смайлов идеально подходят письма — они большие, серьезные, лишние скобочки в них никто не ждет.
Для каждого браузера по разному. Но, например, в текущем Chrome код, который не сохраняет длину массива в локальную переменную, будет работать быстрее. Свеженькая статья на эту тему.
По умолчанию есть только один поток, которые асинхронно обслуживает очередь сообщений.
В браузере для многопоточности есть WebWorkers, но единственное возможное общение между потоками осуществляется через отправку строк или сериализованного в строку JSON-а, к одним и тем же переменным из разных воркеров обратиться нельзя.
Статья уже устарела на несколько лет.
Поэтому умение быстро найти в багтрекире то, с чем сам столкнулся, для программиста необходимо. И не нужно этого бояться. Это нормальный рабочий процесс.
Для текста без смайлов идеально подходят письма — они большие, серьезные, лишние скобочки в них никто не ждет.