Алексей Уколов

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

Удаленная отладка на Android с Chrome
https://developers.google.com/web/tools/setup/remo...

А какую информацию вы ищете? Там в списке есть название, описание, ссылка на репо. Поиск работает. Чего еще хочется?

Насколько кроссбраузерной должна быть верстка?
Какие современные требования к кроссбраузерности?

Все можно сделать.... (как бы странно это не звучало....)
1. Нужно составить схему архитектуры, создать список классов и их методов, функций и т.д..
2. Наложить файлы на архитектуру, чтобы понимать где что делается.
3. Затем, рефакторинг архитектуры и кода (если необходимо и есть время).
Продолжать работу.

PS: не очень приятная работа, однако без неё однозначно всё встанет в ближайшем будущем на этом решении без необходимого понимания и документации разработчика.

Не волнуйтесь, вас уволят и правильно сделают. И вот почему.
Начну со стороны хорошего бизнесмена:
У него уже есть cms и crm, которую он пилил 5 лет, умеет продавать и знает. Да, так получилось, свой велосипед, ужасно написанный, но это его не волнует до тех пор, пока она кормит и его и всех его подопечных. Отказаться от неё означает не только огромные временные затраты на смену всего, начиная от обучения программистов как её пилить, заканчивая обучением всех, кто будет её касаться. Так же это означает поддержка уже двух систем, старых клиентов со старой и новых с новой. Но самое главное - это высокий риск того, что продавать её будет тяжелее.

Со стороны хорошего разработчика:
А хорошему разработчику вообще до фени, с чем ему работать. Спросите у опытных. Эмоционировать при виде говнокода и велосипедов - это максимализм юного программиста. Разработчики с опытом умеют погружаться в любой велосипед, в любой говнокод и работать с ним. А потому что они уже навидались и в своё время тоже кричали и пытались перевернуть мир, но, кому это надо? Вы - наёмный работник, вы не должны писать красивый код, вы должны решать бизнес задачи. Бывалые так и делают, просто иногда про себя вздыхая, т.к. чувство прекрасного всё же не убить :)

Способов масса. Вот один из:

HTML:

<button class="js-button" data-toggle-text="Close">Open</button>
<div class="js-container hidden">
Some text here.
</div>

CSS:

.hidden {
  display: none;
}

Если вы не используете jQuery в проекте, то посмотрите пример на чистом JavaScript:

JavaScript: (Демо: codepen.io/anon/pen/EjzYpy )

;(function($D){
    var $button    = $D.querySelector('.js-button'),
        $container = $D.querySelector('.js-container');
  
    $button.addEventListener('click', function(e){
      var data = e.target.dataset,
          toggleText = $button.innerHTML,
          isVisible = $container.style.display == 'block';
      
      $button.innerHTML = data.toggleText;
      data.toggleText = toggleText;
      
      $container.style.display = isVisible ? 'none' : 'block';
    });
})(document);

Если используете jQuery, посмотрите следующий пример:

jQuery: (Демо: codepen.io/anon/pen/MwdgEN )

$(function(){
  var $button    = $('.js-button'),
      $container = $('.js-container');
  
  $button.on('click', function(){
    var toggleText = $(this).data('toggle-text');
    
    $(this).data('toggle-text', $(this).text())
           .text(toggleText);
    
    $container.toggleClass('hidden');
  });
});

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

Можно настраивать CI, можно разводить agile процессы, но главное - выяснить требования заказчика, и подстраиваться под них.