То, что вы описали — это DOMContentLoaded, событие Load срабатывает при полной обработке всех ресурсов страницы. Однако, в таких ненормальных условиях, как наличие document.write непосредственно в script-теге, возможно существует и какое-то иное поведение.
1) Кажется, что в среднем пре-пуш (или интеграция проверок на ide) дает более быструю обратную связь разработчику. Можно использовать в совокупности с пре-ресив хуками, конечно.
2) Автоматическое переформатирование должно гарантировать корректность кода. Если оно не может гарантировать корректность в каких-то специфических случаях — оно не должно трогать код и должно требовать от разработчика правильным образом его исправить.
Вот с частичной потерей истории в git — это да, существенный момент. Однако по себе могу сказать, не так уж оно и нужно — в один прекрасный момент поймал себя на мысли, что лезу в blame чисто посмотреть, кто такую херню написал :) Зачем, почему, как исправить — как правило понятно из кода (а если непонятно, то есть комментарии). Так или иначе, в пушистом легаси коде отсутствие комментариев и неявность намерений исходного автора может действительно быть существенной причиной не делать авто-преобразований.
1) А чем пре-коммит хуки не понравились? Или у вас в проекте настолько легаси, что файлы по 4000+ строк?
2) Не задумывались над тем, чтобы прогнать автоматическое переформатирование кода на всем проекте? Один раз и навсегда.
Отвечу то, же что и парой комментов выше — он не лучше кластера ничем, кроме наворотов сверху, потому что внутри себя pm2 непосредственно использует cluster.
Плюшки все указаны в readme, в их числе — авто-перезапуск при падении, софт-рестарт воркера при превышении лимитов по памяти или процессору, поддержка деплоя через репозиторий и прочее. При прочих равных — довольно вкусные возможности.
Насчет корявостей — в cluster-модуле балансировка пакетов по воркерам может работать нестабильно. Не скажу за последние версии ноды, инфа актуальна на версии 0.12 — 4.2. До версии node 4.0 кстати кластер-модуль вообще не работал под нагрузкой — мастер-процесс, а также и god daemon (в случае пм2) просто падал напрочь через 5 минут вместе со всеми воркерами. Потом починили, вроде, но с pm2 (опять же под нагрузкой) началось жесткое забивание сетевого стека висящими коннектами. Предположительно из-за того, что при софтовом перезапуске воркера сокет для общения с god daemon-ом оставался висеть, но я в код настолько глубоко не залезал и не проверял, точно говорить не могу. Симптомы — частые неответы сервера и 50х ошибки. После замены pm2 и кластерного режима nodejs на балансировку nginx-ом по вручную созданным воркерам — исчезли почти все проблемы и общая стабильность значительно повысилась.
pm2 использует cluster-модуль внутри себя, поэтому «кто лучше» — вопрос неправильный. Помимо (коряво реализованных) управления процессами и балансировки запросов по процессам у pm2 есть масса других привлекательных плюшек, которые зачастую определяют выбор.
Пробовали у себя. Поплевались, выбросили. pm2 при работе в режиме кластера напрочь забивает сетевой стек висящими соединениями. Как итог — серьезное увеличение числа 50х ответов. У nodejs и так-то кластерный модуль через пень-колоду написан, а pm2 еще и своих глюков добавляет. Рекомендовать его для хоть сколько-нибудь серьезных проектов не могу.
И кстати, в исходный код pm2 лучше не смотреть людям с неустойчивой психикой.
Упоминание реакта в данном контексте несколько странно. Да, он может в изоморфность, однако это лишь одно из специфических решений для seamless-отрисовки как на клиенте, так и на сервере. Но на отрисовке свет клином не сошелся, изоморфность это также и про получение данных, и про их обработку (читай — бизнес-логику). И там тоже есть свои грабли, тысячи их.
Ну, v8 это же чисто синхронная штука. Вся асинхронщина отдается на откуп конкретной реализации, в данном случае — Blink. Не удивлюсь, если оперовцы подтюнили местную реализацию event loop-а и его обвязки, добавив туда возможность триггерить извлечение запланированных тасков из очереди колбэков в два раза реже.
Скажем так, решение ребят из fb вряд ли было серьезно обоснованным, скорее оно выросло в результате поиска наименее болезненного варианта записи многословных и многочисленных React.createComponent()-выражений. Какое может получиться месиво из js и jsx для более-менее сложного компонента — можно представить. При этом возможности реакта никак не ограничивают эту потенциальную сложность, и даже поощряют ее, например предлагая писать условные конструкции внутри jsx на js. Это всё оправдывается необходимостью постройки virtualdom, но смешивание разметки и логики не кажется необходимым.
Впрочем, для небольших компонентов, где мало разметки и мало кода (привет счетчику людей онлайн в fb), все же проще смешать все воедино. Основной вопрос как всегда в том, где граница между небольшим и большим :)
Всё бы ничего, если бы ребята не предлагали запускать свои скрипты от рута. Скрипты, которые, если я не ошибаюсь, еще и частично скачиваются с родных серверов при каждом запуске. То есть ssl-то мы поставили, но при этом создали еще большую дыру ¯\_(ツ)_/¯ Если на let's encrypt случится факап, то получим неплохой такой ботнет.
Для инструментирующего профилирования есть еще вот такое готовое решение (правда только для ES5). Там правда понавороченнее будет код, чем тот, что в примерах :)
А поделитесь, находили ли вы способ более-менее быстрого профилирования в боевых условиях? Например тот же njstrace существенно замедляет работу больших приложений, причем настолько существенно, что кроме как на тестовом стенде его применять невозможно.
Зря снимаете :) Случаев, когда версия модуля-зависимости не совпадает и потому ставится не в корень, а в node_modules модуля, объявившего зависимость — может оказаться субъективно больше (на моем проекте это так, например).
Кроме того, я в упор не понимаю, как оно решает, какую версию поставить в корень, похоже оно туда тащит первую попавшуюся в списке зависимостей.
Были проблемы. Не зря NAN появился. Бинарные модули, использовавшие api v8 напрямую (в версиях 0.10 и 0.12), были непригодны для компиляции с новой nodejs, когда она появилась. Своими руками портировал node-rsvg, например, после перевода его на NAN отпали проблемы с компиляцией на всех существующих версиях node/io.
Аргументы в пользу того, что в конкретно вашем случае код становится проще, звучат неубедительно. Кажется, что это усложнение ради усложнения.
КА имеет смысл применять там, где много состояний, много переходов, могут быть циклические цепочки переходов. Остальные случаи можно отнести к тривиальным и пользоваться соответствующими более простыми средствами.
Безусловно, говоря про поползновения на бой, я имею в виду только сервера приложений, которые пишутся мной и командой, в которой я работаю :) Как правило, туда в случае непредвиденных проблем проще и быстрее залезть самому, чем продираться сквозь бюрократию межкомандного взаимодействия. Но да, определенно не стоит это брать за постоянную практику — это для форс-мажоров.
Как программист, бывает, хожу по боевым серверам. Имею навыки администрирования серверов. Никто пока от этого не умер, кроме разве что нескольких багов, проявлявшихся только на бою. И кажется, что при определенном уровне ответственности и понимания того, что ты сейчас делаешь и как это может выйти боком, иметь доступ на бой не грешно, и поэтому не стоит всех девелоперов под одну гребенку :)
2) Автоматическое переформатирование должно гарантировать корректность кода. Если оно не может гарантировать корректность в каких-то специфических случаях — оно не должно трогать код и должно требовать от разработчика правильным образом его исправить.
Вот с частичной потерей истории в git — это да, существенный момент. Однако по себе могу сказать, не так уж оно и нужно — в один прекрасный момент поймал себя на мысли, что лезу в blame чисто посмотреть, кто такую херню написал :) Зачем, почему, как исправить — как правило понятно из кода (а если непонятно, то есть комментарии). Так или иначе, в пушистом легаси коде отсутствие комментариев и неявность намерений исходного автора может действительно быть существенной причиной не делать авто-преобразований.
2) Не задумывались над тем, чтобы прогнать автоматическое переформатирование кода на всем проекте? Один раз и навсегда.
Насчет корявостей — в cluster-модуле балансировка пакетов по воркерам может работать нестабильно. Не скажу за последние версии ноды, инфа актуальна на версии 0.12 — 4.2. До версии node 4.0 кстати кластер-модуль вообще не работал под нагрузкой — мастер-процесс, а также и god daemon (в случае пм2) просто падал напрочь через 5 минут вместе со всеми воркерами. Потом починили, вроде, но с pm2 (опять же под нагрузкой) началось жесткое забивание сетевого стека висящими коннектами. Предположительно из-за того, что при софтовом перезапуске воркера сокет для общения с god daemon-ом оставался висеть, но я в код настолько глубоко не залезал и не проверял, точно говорить не могу. Симптомы — частые неответы сервера и 50х ошибки. После замены pm2 и кластерного режима nodejs на балансировку nginx-ом по вручную созданным воркерам — исчезли почти все проблемы и общая стабильность значительно повысилась.
И кстати, в исходный код pm2 лучше не смотреть людям с неустойчивой психикой.
Впрочем, для небольших компонентов, где мало разметки и мало кода (привет счетчику людей онлайн в fb), все же проще смешать все воедино. Основной вопрос как всегда в том, где граница между небольшим и большим :)
destruction != destructuring, равно как и деструкция != деструктуризации.
А поделитесь, находили ли вы способ более-менее быстрого профилирования в боевых условиях? Например тот же njstrace существенно замедляет работу больших приложений, причем настолько существенно, что кроме как на тестовом стенде его применять невозможно.
Кроме того, я в упор не понимаю, как оно решает, какую версию поставить в корень, похоже оно туда тащит первую попавшуюся в списке зависимостей.
КА имеет смысл применять там, где много состояний, много переходов, могут быть циклические цепочки переходов. Остальные случаи можно отнести к тривиальным и пользоваться соответствующими более простыми средствами.