Число JS-библиотек ни в коей мере не уменьшается; наоборот, оно растёт с каждым днём. Когда мы доходим до приложений JS, лучшим выбором оказываются шаблоны, чем полноценные библиотеки, потому что это приводит к более чистому базовому коду и лучшему процессу работы с ними.

Не так давно я писал, что вы могли бы попробовать написать свою библиотеку, когда придёт время. Шаблонизаторы же требуют несколько больших навыков и понимания языка, с которым вы работаете, поэтому лучше полагаться на любой шаблонизатор из имеющихся в списке ниже.
ICanHaz,Hogan,Handlebars,Mustache,Transp-cy,doT,Walrus,Chibi,templayed,ECT,Pithy,T,Nunjuck,Jade,Dust

Приветствую! Я уже писал обзор на подобный набор. Но в процессе изучения и после комментариев владельцев выяснилось что мне пришла подделка! Грусть-пичаль, конечно, но вместе с подделкой в магазине оказался и оригинал. О нем и пойдет речь в обзоре. Заодно и изучим отличия оригинала от копии.
Читать дальше

В комментариях к посту про Underscore/Lo-Dash я упомянул, что среди библиотек, расширяющих стандартную библиотеку JavaScript, я предпочитаю SugarJS, который, в отличие от большинства аналогов, работает через расширение нативных объектов.

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

Это побудило меня перевести манифест SugarJS по этому вопросу. По всей видимости, автору этой библиотеки приходилось очень часто слышать подобные нападки. Поэтому он очень взвешенно и достаточно непредвзято прокомментировал каждую из них.

В этом материале разбираются подводные камни JavaScript, известные и не очень, а также предлагаются методы защиты. Поэтому я думаю, что статья будет интересна и полезна любому JS-разработчику, независимо от его отношения к проблеме расширения нативных объектов.

Передаю слово Andrew Plummer.

---

Итак, Sugar — библиотека, которая модифицирует нативные объекты JavaScript. Подождите, разве это не во зло? — спросите вы, — вы что, не извлекли урок из горького опыта Prototype?

По этому поводу существует много заблуждений. Sugar избегает подводные камни, о которые спотыкался Prototype, и фундаментально отличается по своей сути. Однако этот выбор — не без последствий. Ниже разобраны потенциальные проблемы, вызываемые изменением нативных объектов, и изложена позиция Sugar насчет каждой из них:

1. Модификация объектов среды
2. Функции как перечисляемые свойства
3. Переопределение свойств
4. Конфликты в глобальном пространстве имен
5. Допущения насчет отсутствия свойств
6. Следование спецификации

Читать дальше →