Stdit

По моему опыту, nodejs — удобная, стабильная и быстрая штука, имеющая отличное сообщество и много хороших библиотек в npm. Преимущества можно перечислять долго, лучше сразу перейти к проблемам.

— Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
— Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
— Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
— Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
— При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.

По поводу камней:
— Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
— Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
— Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
— Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
— Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
— Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).

По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.

Конечно да. AngularJS — один из самых интересных современных фреймворков, детальная информация про его подкапотную была бы интересна и полезна, думаю, многим. Серию постов на Хабре не хотите сделать?

Можно использовать старый добрый graphviz.

// m1.js
module.exports.Model = function() {
  this.test = function() {
    console.log("MODULE 1");
  };
};

// m2.js
module.exports.Model = function() {
  this.test = function() {
    console.log("MODULE 2");
  };
};

//test.js
var model1 = new (require('./lib/m1.js').Model);
var model2 = new (require('./lib/m2.js').Model);

model1.test();
model2.test();

//result
MODULE 1
MODULE 2

Если html формируется на сервере — то и экранирование на сервере.
Если формируется на клиенте — то экранируется в рамках json (или в чем он там приходит с сервера), а html-экранирование может выполнять javascript-шаблонизатор.
И ещё, я не понял, причем тут perl.

Попробуйте использовать не выпадающий селект, а с зафиксированным размером (size). Если нужно именно выпадение с фиксацией, тогда придётся вручную его анимировать или писать целиком «свой селкет».

[мимо]

А зачем вам объект «окружность»? Что вы с ним потом собираетесь делать, ради чего здесь он создаётся? Может проще написать просто какой-нибудь «хелпер»:

helpers.circle = function (context, x, y, radius, color) {
    context.arc(x, y, radius, startDegrees, endDegrees, counterClockwise);
    context.fillStyle = color;
    context.fill();
}

Ну или завести объект «рисовальщик», хранящий ссылку на графический контекст и настройки рисования, и имеющий необходимые методы (вроде приведённого выше) для работы с этим контекстом:

function Painter(context, defaultColor) {
    this.context = context;
    this.defaultColor = defaultColor;
    this.circle = function (x, y, r, color) {
        if (color === undefined) {
            color = this.defaultColor;
        } 
        this.context.arc(x, .... // code
    }
}

Это если вам нужно наследование. Объекты по-моему имеет смысл создавать только для реально существующих инстансов (спрайты, например, от которых наследуются игровые объекты и персонажи). Если окружность — это динамический объект, тогда можно уже думать и крутить, в зависимости от архитектуры графики, например так:

function Circle(x, y, r, color) {
    this.x = x;
    this.y = y;
    this.r = r;
    this.color = color;
    this.render = function (context) {
        context.arc(this.x, ... 
    }
}

Клиентский яваскрипт или серверный? Онлайн ресурс на чистом JS — для тренировки можно сделать простую онлайновую игрушку на NodeJS + socket.io. Очень увлекательный и творческий процесс, приносит кучу опыта и удовольствия.

А эту штучку не смотрели? (обсуждение).

За это отвечает css свойство overflow, высота должна быть ограничена.

Вижу тут два варианта: либо помещать форму в iFrame, вставленный в страницу «модально», либо в обычный модальный попап (div), но в форме блокировать submit (return false), слать и обрабатывать результаты ajax-ом. В во втором случае html каждой формы должен быть либо загружен заранее, либо приходить из XHR ответа.

GIF идеально должен подойти. Если нужен труколор — тогда композиция из PNG + JS-анимация. Если на ИЕ8 пофиг — тогда Canvas.

.match(/^#([a-z]{4})(\d+)$/)

Написание CMS — это огромная работа. Ничего плохого нет в том, чтобы попробовать самому написать CMS в образовательных целях, это лучший способ изучить на практике проектирование и получить опыт, который поможет в дальнейшем понимать готовые CMS и писать на них нормальный код. Прежде чем писать CMS, нужно написать Framework для неё. Можно начать с изучения готовых решений, например Symfony2. Перед практикой обязательно изучение теории, паттернов проектирования, способов оптимизации и т.д. Не стоит рисковать применять свою CMS на боевых сайтах и серверах, потому что почти наверняка в ней будут уязвимости и архитектурные ошибки, которые в дальнейшем создадут вам или коллегам немало проблем.