Шаблонизаторы javascript: зачем, почему и как это работает?

Так JS-фреймворкам нужен шаблонизатор для View. Например, Underscore со своим шаблонизатором, Handlebars, Mustache. А вот Angular.JS так вообще сам себе шаблонизатор )

Чтобы потом было какие проблемы решать, вроде той, например: Как оптимизировать AJAX для ПС :}

AJAX

Вот чтобы было удобно отображать полученные данные и запилили шаблонизаторы на фронтенде. Впрочем, если тебе удобнее var result = " ... " + data.var1 + ..., никто не запрещает.

Для локализации используется, например.

зачем, почему

эволюция парадигмы разработки в вебе, полное разделение фронтенда и бекенда, возможность посадить людей за разные участки которые не пересекаются, меньше багов, меньше проблем, быстрее разработка, больше профит, лучше UX (это если мы берем шаблонизацию на JS в рамках Single Page Application)

как это работает

глянь handlebars для примера просто, думаю там все понятно

Именно наткнувшись в приложении на «усы» и задался этим вопросом.

Спасибо за ответ. Как все усложнилось то за прошедшие 6 лет.

ЧСХ, используют это в основном там, где не надо.

Этот сайт внес ясность.

Короче говоря оно надо, чтобы при необходимости проще было запихнуть данные в JSON -> HTML.

Такое вот у него в жизни назначение.

umren, подскажи пожалуйста какой js-фреймворк целесообразно изучать новичку.

Ну, естественно, кроме jquery :-)

Ты имеешь ввиду структурный, который позволяет вывести организацию кода на новый уровень?

я думаю проще всего начинать с backbone, там меньше магии, больше кода пишешь.

Да именно. Из «новомодных».

Хотя опять же, действительно, шаблонизация разметки на js (эдакий «внук» document.write) усложняет индексацию поисковиками, не?

Как ты выходишь из подобных положений?

Спасибо.

Изучать AngularJS, потом ReactJS.

А мне бэкбон больше нравится, больше свободы...

Хотя опять же, действительно, шаблонизация разметки на js (эдакий «внук» document.write) усложняет индексацию поисковиками, не?

тут говорил об этом

Если вообще чито шаблонизатор то само быстрый и простой: http://olado.github.io/

Ток он чота лежит прям щас ))

Хорошо, предположим, что фронтенд полностью реализован на AngularJS, например.

Что ложиться на server-side, какие конкретно участки веб-логики?

Просвети.

Что ложиться на server-side, какие конкретно участки веб-логики?

REST на бекенде в виде апи и все, что тебе еще от него нужно? надо ведь где-то все хранить, почту отправлять, rabbit mq забивать и мемкешы засирать в том числе.

То есть минимальная серверная логика, которая дергает БД и отдает результат во фронтенд?!

Это если очень упрощенно представить.

И вообще, что можно почитать о грамотной архитектуре построения веб-приложений?

Понятно, что у каждой задачи свой масштаб и там, где jquery и его присные плагины уже несправляются берем фреймворк «покруче».

Есть какие-то общие архитектурные решения?

И вообще, что можно почитать о грамотной архитектуре построения веб-приложений?

слишком opinionated, можно отслеживать общие тенденции если читать все доступные источники и слушать гуру от сообщества.

Есть какие-то общие архитектурные решения?

мне кажется тут просто решает опыт.

То есть минимальная серверная логика, которая дергает БД и отдает результат во фронтенд?!

Это тоже слишком общее утверждение? Хочу проверить свою систему понятий, прежде чем двигаться дальше.

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