Findoss

Часто применяется для:

1. Локальные приложения и утилиты командной строки

• Сборщики и трансляторы
  
• Пакетная обработка и сценарии отложенной обработки
  
• Скрипты, CLI (интерфейсы командной строки)
  
• Генерация документации, отложенное формирование отчетов
  
• Сценарии тестирования для других систем
  

2. Серверы

• Серверы веб-приложений и SPA
  
• Серверы и API для мобильных приложений
  
• Любые другие веб-API (RPC, JSON, REST)
  
• Серверы сообщений и трансляция событий (чаты, игры, интерактив)
  
• Заплаты на уже готовые системы, написанные на других языках, для реализации вебсокетов, SSE, лонг-пулинга и т.д., т.е. для затыкания дыр, для решения проблем в узких местах уже работающих систем.
  

3. Клиенты

• Оконные приложения (nw.js, node-webkit)
  
• Кравлеры, парсеры и сбор данных
  

4. Железо

• Программирование микроконтроллеров (arduino, espruino, tessel)
  
• Промышленная автоматизация
  

Редко применяется (но подходит) для:

• CMS, публикация контента (просто ниша уже занята и в этой задаче нода не дает чего-то принципиально нового или сверх соблазнительного).
  
• Массовая электронная коммерция и торговля (не применяется для массовых движков магазинов, но используется отдельными крупными компаниями для торговых и платежных задач в качестве дополнительного средства к уже имеющемуся ПО, по сути закрывает узкие места).
  

И плохо подходит:

• Вычисления и моделирование, со скоростью математических операций нода и JS, как не типизированный язык, не дают хороших показателей
  
• Научные приложения (по тем же причинам)
  

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!

.then(function(param1) {
  ...
  return Promise.all([
    Promise.resolve('val1'),
    param1
  ]);
})
.then(function(arr) {
  var param2 = arr[0]
    , param1 = arr[1] 
})

Попробую на пальцах объяснить.

Событие – это конверт, на котором написано его название. Внутрь конверта можете вложить что-нибудь, а можете оставить конверт пустым.

Элемент – это столик. Кто угодно может подойти и положить на столик свой конверт.

Слушатель – это мужик, который топчется около столика и смотрит, нет ли чего с интересующим его названием. Может несколько человек поджидать конвертики с определённым названием – прочтут все, если только в конверте не написано «по прочтении съесть» – тогда кто-то съест и дальше не передаст.

Как создать/отправить конверт. В любом месте кода создайте конверт и дайте ему название: var myEvent = new Event('teaTime'); Остается положить конверт на нужный столик:

document.getElementById('stolik').dispatchEvent(myEvent);

Чтобы в событие вложить какие-то данные, нужно использовать другой конструктор и передать нагрузку в поле detail:

var event = new CustomEvent('saySomething', { detail: "Hello there!" });

Для чего нужно создавать свои события? Чтобы развязать куски кода. Например, в разных местах документа можно нажать на кнопку повторяющегося виджета. Виджет создаст на document событие "widgetClicked". А ещё несколько одинаковых компонентов в странице, слушающих document на предмет события "widgetClicked", получат пинок и что-нибудь вытворят.

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

Вкратце, полноценный клиентский разработчик должен знать:
– html5/css3 + bootstrap
– один-два препроцессора (less/stylus)
– чистый js и пару-тройку клиентских библиотек или фреймворков (knockout/backbone/angular/react)
– немного node.js, чтобы уметь пользоваться пакетным менеджером (npm) и билд-менеджером (gulp/grunt)

Этот список покрывает большинство клиентских задач в средней студии или стартапе.

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

Другой вопрос – что со всем этим делать.

Я обычно предлагаю попытаться начать свой маленький проект. Какой-нибудь простенький личный сайт, игру на js (тот же flappy bird или 1048 – много ума здесь не нужно). Посложнее – свою тему или библиотечку. Это будет хорошим практическим опытом, который не стыдно описать в резюме.

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

Если говорить о личном опыте, то я неплохо подтянул js с помощью codewars – задачки начинаются от самых простых (преобразование строк, перебор массива), до очевидно тяжелых (собственные интерпретаторы и преобразование данных изображения).

А вот попытка спихнуть на верстальщика UI/UX – это уже экономия со стороны отдельных контор, которые по какой-то причине не хотят нанимать отдельного дизайнера/проектировщика в штат или по контракту. Тут, к сожалению, придется мириться и смотреть статьи по теме – тот же GoodUI.