Вот это неплохо, правильно. Есть конторы, которые сразу акции делят среди разработчиков. Но мне ничего подобного не встречалось здесь в России, было бы интересно узнать о реальных таких ситуациях.

Лучшая мотивация для талантливого человека, помимо конечно его интереса к тому, что он делает, это понимание того, что то, во что он вкладывается, будет иметь финансовую отдачу на протяжении всего жизненного цикла его творения. Разрабатывает, например, группа разработчиков сервис проигрывания музыки, значит все, кто составляют ядро разработки должны непосредственно иметь долю с прибыли этого сервиса, на протяжении всей жизни этого сервиса. Понятно, что в реальности дело обстоит иначе. Тебя мотивируют премиями разовыми, полностью выжимают как лимон, а потом работа в проекте заканчивается. Проект потом приносит прибыли компании, а те кто его разрабатывают в лучшем случае работают на поддержку его за зарплату. Главное, самое интересное, над тобой куча всяких сотрудников, с экзотическими должностями, которые пытаются придумать какие-то смешные способы мотивации. Пока молодой, талантливый мотивация одна(, и все эти CRM -ы этим пользуются), а именно, получение реального опыта, хотя, на мой взгляд, талантливые программисты, создают этот опыт для будущих менее талантливых программистов, талантливым программистам, интересен предмет, он их мотивирует, их мотивирует пределы возможного. Когда программист начинает думать, что его вклад несоразмерен тому, что он имеет — это уже программист другого типа. Он уже понимает, что его когда-то использовали. Это проблема, которую описал, она очень сложная. Можно встать на место владельцев компании и найти кучу контр примеров, например один из самых любимых, типа программист, который уже на доле, начинает пробуксовывать, теряет форму. Или как определить прибыль, которую приносит конкретный проект, который в свою очередь использует разработанную инфраструктуру других проектов. Например, может сервис проигрывания музыки сам по себе не имел бы таких прибылей, если бы не находился в среде других смежных проектов. Но мне бы хотелось владельцам компаний заметить, что их благосостояние неуклонно растет, ну это если взять все известные крупные IT компании. Таким образом однозначным считаю, на протяжении всего жизненного цикла работы (не разработки) программного продукта, программисты, которые вносили основной вклад в разработку ядра этого продукта, должны получать «обратку», сколько или даже что — это уже другой вопрос, самое главное, создатели должны быть отблагодарены их творениями.

Не понял какие тонкости работы с ошибками в node js вы раскрыли, кроме поля code. Ваша статья в целом относится к V8 и JavaScript.
Например следующие практические вопросы, которые возникают в node js, вообще не находят ответов в вашей статье.
В каких случаях использовать throw, в каких emit('error'), а в каких использовать callback c err?
Как использовать механизм domain, для целей централизованной обработки ошибок?
Как использовать reject в promise для обработки ошибок?
Как различать ошибки сигнатуры вызовов от всех остальных?

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

Согласно источнику, мною очень уважаемому при создании функции, в моем примере someMethod:function() {...} внутреннему свойству функции [[Scope]] будет присвоено значение текущего узла цепочки областей видимости в этом узле согласно стандарту уже содержится ссылка на priorThing, далее это ([[Scope]]) свойство уже не меняется никогда. А теперь цитата из источника

Как уже было сказано выше, в целях оптимизации, когда функция не использует свободные переменные, реализации могут не запоминать лексический контекст, однако в спецификации ECMA-262-3 об этом ничего не сказано; поэтому формально (и по технического алгоритму) – все функции запоминают [[Scope]] ещё при создании.

Таким образом когда вызывается функция replaceThing, в этот момент начинается разбор и интерпретация тела этой функции, будет создан theThing, его свойству someMethod будет присвоена ссылка на функцию-выражение, свойство [[Scope]] которой будет указывать на объект переменных (VO) вышестоящего контекста, которым является функция replaceThing. И в этом объекте согласно стандарту должна быть priorThing. И если ее там не будет, то только в процессе создания функции replaceThing оптимизатор проанализировав ее тело может принять решение о том включать ее в VO или нет. Т.е. еще до исполнения (активизации) функции replaceThing определяется судьба priorThing. А сборщик мусора начинает свою работу на много позже, и если оптимизатор не исключит из VO priorThing, то мы всегда сможем добраться из глобальной переменной theThing до всех созданных в предыдущих вызовах объектов, а в следствии чего сборщик не сможет удалить эти объекты.

Ну вот видите, и даже вы не привели пример того вопроса, на который может не ответить и «неджуниор», тогда утверждение «Эти ошибки совершают разве что только джуниоры» неконструктивное, в общем то пустое, его тогда можно интепретировать так, если вы что-то не знаете, то вы джуниор, а это не всегда так.

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

И даже в этом примере (пункт 3) не все так однозначно с утечками памяти, оптимизаторы могут убрать из замыкания переменную если она не используется в нем, и тогда утечка памяти не возникнет. В этом случае

var theThing = null;
var replaceThing = function () {
    var priorThing = theThing;  // hold on to the prior thing
    theThing = {
        longStr: new Array(1000000).join('*'),  // создаем 1Mб объект
        someMethod: function() {console.log('xxx');}
    };
};
setInterval(replaceThing, 1000);

оптимизатор исключит из замыкания priorThing, и утечки не будет

а вот в этом случае

var theThing = null;
var replaceThing = function () {
    var priorThing = theThing;  // hold on to the prior thing
    theThing = {
        longStr: new Array(1000000).join('*'),  // создаем 1Mб объект
        someMethod: function() {console.log(eval(''));}
    };
};
setInterval(replaceThing, 1000);

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

Хорошая статья, важная, вот тут недавно задавался этим вопросом, но применительно к виртуальной машине v8.engine, считывал файлы в буфер, поскольку памятью в script -овых языка занимается специальные менеджеры, то прямого доступа к системным механизмам управления памятью нет и вот тут возникают очень много вопросов. Вот например, что будет делать менеджеры памяти в таких виртуальных машинах, если я буду загружать файлы в буферы памяти, теоретически я могу предположить, что например виртуальная машина такая умная, что она отобразит эти файлы на память процесса, а специально, созданные структуры в куче будут ссылаться на отображенные адреса в памяти процесса. Грубо говоря, в таких окружениях это все остается за кадром.

Почитайте, пожалуйста здесь историю создания проекта и самое главное мотивацию, т.е. основным мотивом было асинхронная отложенная загрузка модулей на клиенте, в браузере, собственно в третий раз, настаиваю на том, что это главное — это котлета, теперь попытаюсь отделить её от мух, которые вы решили заметить на котлете. В процессе развития и использования проекта скорее всего встал вопрос, а что, то если разработчики слишком например сильно будут дробить свои проекты на множество модулей, тогда возникает ситуация, когда на клиенте может возникнуть множество запросов на сервер по загрузке этих модулей, и естественным образом возникло желание сократить количество таких запросов, попытавшись оптимизировать загрузку путем объединения нескольких модулей в один, по степени связности, и вот возник оптимизатор, который так, на всякий случай, может используя стиль подтягивания модулей и плюс ваш конфигурационный файл объединить все в один, и это только частый случай работы оптимизатора, а вы его выставляете, этот частный случай, за котлету, если этот частный случай вы повсеместно используете в своих проектах, то тогда, извините за то, что я вас побеспокоил. В других проектах ваш частный случай вообще может не рассматриваться. Оптимизация, по определению носит сугубо эврестический характер, и никогда не является панацеей, некоторые разработчики в процессе написания модулей оптимизируют их контент сами, без использования дополнительных утилит. Ну если использовать require js, только для того, чтобы потом все объединить в один файл и грузить на клиент, просто потому, что нравиться стиль определения и подхватывания модулей, а потом сборки, то тогда действительно можно рассматривать его в качестве альтернативы другим подходам и библиотекам. Спасибо за понимание.

Я написал, что require js ничего не собирает, имея в виду конкретно модуль require js, а не r.js — оптимизатор, который собирает, и то не всегда в один файл и цель, которого не простая конкатенация, вы меня тут отправляете к докам, пишите про build конфиг, зачем?.. r.js — это addon, его можно использовать или нет. Основное назначение Require js, повторю, отложенная загрузка по требованию, вот это мой посыл, а вы его видимо не понимаете и пишите, про то, что есть еще r.js, который собирает и какой он крутой, я вам об одном пишу, а вы о другом.

Если вы считаете, что основная цель optimizer собрать в один файл, грубо говоря, цель — «конкатенация», то тогда я с вами соглашусь, что неправ, но мне видится другая цель, а именно, сборка модулей по принципу связанности.

Простите, в чем не прав?

К асинхронной загрузке модулей, на клиент, browserfy не имеет никого отношения, сравнивать его с require js не стоит, это разные по назначению библиотеки. Browserify собирает модули в один, используя стиль require node js. Require JS позволяет асинхронно загружать модули на клиент по мере их необходимости, и это принципиально и даже концептуально их отличает. Browserify можно немного сравнить с Grunt с точки зрения основного назначения — а именно, получение целевого модуля собранного из других, и вот тут можно сравнить те или иные подходы по их использованию.

Абсолютно имеет место быть все, что в статье описано, как вариант декларативного запроса, не вижу причин почему его нельзя использовать, пять баллов.

Проделана большая работа, пусть вы изобрели новый велосипед, спасибо вам.

Грубо говоря браузер после того как уйти со страницы выполнив все обработчики в том числе и unload, уже в своем окружении проверяет, а висит ли хоть один обработчик на unload, если его unload undefined, то тогда кэшировать, если остальные конечно условия в вашем списке тоже выполняются. Так ли это?