Про виртуальный браузер вы утрируете — в нашем случае это небольшая библиотека для генерации дерева нод и компонент (компиляция шаблонов), из которого потом создается html для клиента. Также вы затрагиваете лишь одну маленькую часть приложения — рендеринг шаблонов. А как быть с директивами/компонентами которые имеют свой под-шаблон в котором определяются другие компоненты с другими шаблонами? Также каждая компонента может определять свою модель. А такое разделение обязательно — HMVC отличный паттэрн, и этим путём идут многие, ангулярные директивы, web components, enyo. Код приобретает лучшую структуру, легче внедрять компоненты в систему, легче налаживать взаимодействие компонент, легче разрабатывать — в этом мы уже убедились на опыте. Поэтому на сервере не просто шаблонизатор должен быть, а библиотека которая умеет инициализировать нужные компоненты и давать им возможность определять или переопределять свой шаблон или свою модель и это всё в древовидной структуре.
renskiy хорошо ответил о общей кодовой базе. По сути в этом то и смысл. Что бы не было разделения — например, это мы пишем на symphony, а это будет в angular. Я как раз сейчас для большой статьи о гибридном javascript подготавливаю одно хорошее приложение. Ну а что бы на пальцах объяснить, возьмем такой пример компоненты — имеется короткий список записей за последнюю неделю с ссылками на сами записи. Говоря о приложении, я также подразумеваю целую композицию компонент, то есть наш список с записями может находится в другой компоненте — активность за неделю, где будут еще списки с твитами и прочее. Но и не просто это отображается, но и нужна какая-то не хилая динамика в этом всем — например, добавили запись, и в список автоматически добавился новый пункт. Так вот, думаю вы согласны, что на клиенте angular/backbone или другой какой фреймворк обязателен, иначе на jquery довольно скоро появится каша. Также в большом приложении есть две основные стадии — runtime и load time. Кстати, изоморфный javascript избавляет нас от `single-page application`, которое превращается в multi-page application.
И вот если пользователь попал в screen, где помимо других находится и наш компонент с активностью за неделю, из рантайма, то тут всё просто RESTful API + нужные контроллеры/директивы = вот и наш список. Но как быть если пользователь попал непосредственно по урлу в этот самый скрин — здесь мы уже имеем load time приложения. Использовать restful api снова? Но у нас же не один компонент который жаждет получить свою модель, а много запросов на сервер и при load time это огромные минуса в производительность. Предлагали собирать с помощью php? Но у нас же целая композиция компонент/директив с их шаблонами — как этим всем ещё отдельно управлять из php? Долгое время мы нужные данные встраивали непосредственно в html, а также пытались компоновать все запросы компонент в один, но и в таком подходе было через чур много головной боли, не нужного кода и дополнительный render overhead на клиенте. Также немаловажным здесь является и сео — паук не может проиндексировать наш список записей например. А вот с node.js мы вздохнули с облегчение. При load time компоненты «сами себя» генерируют и клиенту отдается уже готовый html, клиенту также отдается код нужных компонент и они там «сами себя» инициализируют для дальнейшей динамики в рантайме. Таким образом и производительность на клиенте лучше, и для сео хорошо, и кода меньше — разве не хорошо? Возможно снова плохо объяснил, давайте какие-то моменты лучше опишу. Это будет также полезным для будущей статьи, что бы понять, что людей смущает в гибридном javascript.
Про jquery на сервере вы конечно же правы, а вот про бессмысленность общего подхода — не совсем. В Atma.js используем компонентный подход к построению приложения и у нас есть 3 возможных типа рэндеренга компоненты — клиент, сервер или «изоморфный». Клиент — здесь всё просто и всё как вы знаете из бэкбона, ангулара — стандартный mvc шаблон. Сервер — также довольно просто — как вы описали, есть модель и шаблон — генерируем html. Серверный подход используем редко, лишь тогда, когда нужно скрыть модель и компонент от клиента в целом. А вот изоморфный метод рэндеринга передает не только html клиенту но и небольшую мета информацию по атрибутам компоненты в виде html комментария. На клиенте же создается новый экземпляр (`instance`) компоненты — навешиваются dom-события, присваивается модель, создается дерево компонент и прочее. В таком подходе несколько плюсов — 1) Клиент получает html (`seo-/scriptless-friendly`). 2) Выигрываем в производительности, так как никакого построения DOM больше на стороне клиента нету. 3) Этот же компонент можем использовать только на клиенте в дальнейшем рэндеринге.
Объяснил возможно немного сумбурно, но `профит` в этом огромный.
Вот jsperf хороший сервис, но никогда не уверен в актуальности теста — не хватает удаления и редактирования. А Маска уже давно перешла немного в другую область — mvc движок — todomvc, поэтому на данный момент чистое сравнение с шаблонизаторами также не совсем верно. Одним главным отличием всегда было то, что генерировался DOM вместо HTML, и такой подход себя оправдывает в общей производительности приложения.
Именно, что расценивать как небезопасно? Можно любой объект таким образом превращать в `Array`. Берется `length` property (если есть) и заполняется массив «undefined» или index values.
Да, уже разобрался. LESS не поддерживает мултистрочные стринги, поэтому такая декларация не проходит, а в одну строку писать анимационные фрэймы дело не радостное :) Создал pull request к less.js, авось примут.
Да я вот сел щупать `keyframes` и немного расстроился по синтаксису. Всё как бы хорошо, но кажется многострочная декларация не работает, _или я что-то не так делаю_.
А расскажите пожалуйста, или дайте ссылки с описанием, о том, как работает livereload скриптов. Ведь если в каком-то файле имеются event listeners, если мы экспортируем куда-то объекты/функции (передаем указатели), замыкания и прочее, то это же нужно как-то чистить перед внедрением новой порции. Иначе большая вероятность того, что всё будет поломано.
Согласен, Style Recalculation на фоне Script Evaluation / Parse HTML занимает довольно мало времени. (Ну по крайней мере, тот css который у нас в приложениях). Но уверяю вас, что если зацикливаться на таких вещах, то и вся система в целом будет производительной, отзывчивой и приятной. Из этого происходит стиль программиста — если он не обращает на такие вещи внимания, то зачастую и на многие другие также не будет обращать внимания. Собственно именно из этого возникают все разговоры, что вэб приложения, особенно под мобильные устроиства, «тормознутые». Мы видим совсем иную картину — оказывается можно писать быстрые и сложные мобильные вэб-приложения.
Архитектурный недостаток '.foo .bar' пока умолчим.
На самом деле вы ошибаетесь. Есть огромная разница между '.foo .bar' и '.foo > .bar'. И первый вариант использовать нельзя — первое производительность, второе чрезмерное размытие контекста. Вот небольшой тест на jsperf. На «вебкитах» разница существенная. И это учитывая, что браузер лишь один элемент сопоставляет с одним селектором. И не сложно прикинуть, как картина будет выглядеть при рендеринге, когда будет просто сотни элементов и сотни селекторов.
Да, я приблизительно так и понял. Когда-то давно разрабатывали на ASP WebForms, конечно не GWT, но своих прелестей хватало. Ну а потом постепенно во фронтенд переехали с WCF (restful) сэрвисами, но не хватали полноценного бэкенда, поэтому продолжили пользоваться уже asp.net mvc. А с приходом ноды радости не было границ — один код на всех платформах. Если будет нужна какая помощь — пишите, а так желаю удачи.
Ну у нас весь код также заточен и под node.js, и у нас компонентный подход к проектированию. Поэтому разработчик может решать, где каждый отдельный компонент рэндерится — на клиенте или на сервере, или там и там. Поэтому приложения могут быть разнообразного типа и назначений.
Atma.js. «Лайврэлоудер» должен быть глубоко интегрирован в mvc структуру. Ведь появляются трудности при горячем обновлении ДОМа, если на элементах навешаны обработчики, хотя с этим справится можно, но вот правильно перезагружать контроллеры стороннему релоудеру не удастся. Весь проект хоть уже и не молодой, но в паблик начали выкладывать по-частям недавно, поэтому с документацией пока проблемы.
И вот если пользователь попал в screen, где помимо других находится и наш компонент с активностью за неделю, из рантайма, то тут всё просто RESTful API + нужные контроллеры/директивы = вот и наш список. Но как быть если пользователь попал непосредственно по урлу в этот самый скрин — здесь мы уже имеем load time приложения. Использовать restful api снова? Но у нас же не один компонент который жаждет получить свою модель, а много запросов на сервер и при load time это огромные минуса в производительность. Предлагали собирать с помощью php? Но у нас же целая композиция компонент/директив с их шаблонами — как этим всем ещё отдельно управлять из php? Долгое время мы нужные данные встраивали непосредственно в html, а также пытались компоновать все запросы компонент в один, но и в таком подходе было через чур много головной боли, не нужного кода и дополнительный render overhead на клиенте. Также немаловажным здесь является и сео — паук не может проиндексировать наш список записей например. А вот с node.js мы вздохнули с облегчение. При load time компоненты «сами себя» генерируют и клиенту отдается уже готовый html, клиенту также отдается код нужных компонент и они там «сами себя» инициализируют для дальнейшей динамики в рантайме. Таким образом и производительность на клиенте лучше, и для сео хорошо, и кода меньше — разве не хорошо? Возможно снова плохо объяснил, давайте какие-то моменты лучше опишу. Это будет также полезным для будущей статьи, что бы понять, что людей смущает в гибридном javascript.
Объяснил возможно немного сумбурно, но `профит` в этом огромный.
По аналогии иногда используют `Array.prototype.slice.call(arguments)`, так как `arguments` также не `Array`.
Тот туториал, который у вас на сайте с рефрешем глобальной функции — ну извините, это детский сад. Наверняка же есть примеры посложнее.
Style Recalculationна фонеScript Evaluation / Parse HTMLзанимает довольно мало времени. (Ну по крайней мере, тот css который у нас в приложениях). Но уверяю вас, что если зацикливаться на таких вещах, то и вся система в целом будет производительной, отзывчивой и приятной. Из этого происходит стиль программиста — если он не обращает на такие вещи внимания, то зачастую и на многие другие также не будет обращать внимания. Собственно именно из этого возникают все разговоры, что вэб приложения, особенно под мобильные устроиства, «тормознутые». Мы видим совсем иную картину — оказывается можно писать быстрые и сложные мобильные вэб-приложения.Архитектурный недостаток
'.foo .bar'пока умолчим.'.foo .bar'и'.foo > .bar'. И первый вариант использовать нельзя — первое производительность, второе чрезмерное размытие контекста. Вот небольшой тест на jsperf. На «вебкитах» разница существенная. И это учитывая, что браузер лишь один элемент сопоставляет с одним селектором. И не сложно прикинуть, как картина будет выглядеть при рендеринге, когда будет просто сотни элементов и сотни селекторов.