ExtJS сам по себе огромный, там очень много кода и сборка получается большой.
Все модули basis.js, компоненты и шаблоны в сумме дают 389Kb (111Kb gzip). Но все модули никогда не используются, обычно доля кода фреймворка ~250Kb, тогда как размер самого приложения (достаточно большого) 800-900Kb (~250Kb в gzip). Фреймворк позволяет писать достаточно компактный код.
Сборщик basis.js собирает все в один пакет. Так проще и дешевле — скрипт загружается один раз и кешируется, при этом делается один запрос на js и один для css. Код тем не менее иниацилизируется лениво, по мере активации той или иной функциональности — потому старт достаточно быстрый.
Направление мыслей хорошее. Но получается слишком много кода и далеко не js-way. Особенно много по созданию классов и настройке рендеринга.
2. Скорость работы скрипта превыше всего.
…
4. Фреймворк работает на базе jQuery.
Тут определенно что-то лишнее. Если цель добиться высокой производительности, нужно забыть про jQuery, селекторы, html и render. Посмотри в сторону dom-based шаблонизаторов. Сейчас этой дорогой идут basis.js, react.js, ractive и даже meteor. В ember тоже идут в эту сторону, создавая HTMLBars. Вот пара моих докладов по этому поводу: раз и два.
Вообще советую посмотреть basis.js, в нем найдешь много знакомого. Например, те же именованные дочерние представления (сателлиты), или некоторые вещи из работы с данными и др. Только это все более развито…
Если не читал, вот первая часть руководства по фреймворку.
Ох, как лихо вы разделили ;)
Knockout не framework, angular не MV*. Хотя, конечно, зависит от того, что вы в это вкладываете. Если любая обвязка над значением и биндинги — это MV* фреймворк, то ок.
Решения basis.js, jQuery, al-fast-list и оба JS нельзя ставить в один ряд с Angular, Knockout, atom и jWidget, поскольку там идут прямые манипуляции с DOM, что противоречит архитектуре MV*.
Расскажите, где вы увидили прямые манипуляции с DOM в решение basis.js?
basis является каким то там MV* (не заморачиваюсь на эту тему) — есть и model, и своего рода view и controller.
Методы fill, update и clear должны работать только с моделью.
Модель не является обязательной сущностью. Эту задачу успешно может выполнять и контролер, и представление.
В любом случае «пузкомерка» не для того, чтобы разделить решения на категории и не было особых ограничений. Есть конкретная задача, нужно ее решить.
Конечному пользователю все равно на чем написано приложение и какие патерны используются, для него важно «работает» и «не тормозит».
Честно говоря, не понятна методика измерения. То есть какой use case рассматривается, что пользователь будет собственноручно вбивать элементы по одному? Я сомневаюсь, что это разумно.
Куда интереснее сколько времени будет генерироваться представление, когда в него добавят сразу 500-1000 записей. Ведь это обычный кейс, списки приходят от сервера (из localStorage) и мы их добавляем в представление.
Так же если приводите результаты измерений, то лучше выводить их табличкой. Да и избегать оценок «мгновенно» и т.п. — нужны цифры. Тем более их можно получить тем же способом, что вы использовали для основного теста.
Уважаемый, bakhirev.
Это, конечно, здорово, что вы взяли табличку из моей презентации. Но она не для того, чтобы гнуть пальцы или принижать чьи-то других, а для того, чтобы показать как быстро справляются с задачей те или иные решения. Методика измерений совершенно разная, и в данном случае нельзя сопоставлять цифры.
Судя по написанному в статье, работа проделана не малая. Уважайте других, пинать и критиковать проще, чем сделать что-то полезное.
В общем, в тесте была проблема, так что неправильно измерялось время для многих решений, из-за того, что они делают вычисления отложено (angular, knockout etc). Фактически не учитывался вызов callback.
Я поправил, теперь больше похоже на правду: plnkr.co/edit/RzZP7146NgWHlVchXZF7?p=preview
Чтобы не считать расходы на рендеринг я спрятал блок, куда рендерятся списки. Добавил галочку, чтобы можно было учитывать это время. Можно заметить, что даже спрятать/показать список из 10k элементов получается не быстро. Это время у всех будет практически одинаковым.
Смущает, что используется setTimeout(callback, 0) — это может накидывать дополнительное время.
Так же tenshi добавил свое решение и немного изменил решения на jQuery и Knockout, они стали побыстрее.
В итоге у меня получились такие цифры:
Конечно, нужно измерять каждое решение в отдельности. Некоторые, особо прожорливые до памяти, съедают ее столько, что это сильно сказывается на времени выполнения других.
Полностью вас поддерживаю, что сборка должна быть лишь перед деплоем.
В соседнем посте я писал о basis.js. Так вот в dev все разобрано, тоже есть live update (только js не обновляем, это нельзя сделать безопасно). Перед деплоем все это собирается. По принципу «граф на входе, граф на выходе», которые отстраиваются самостоятельно, по переданному индексному html файлу.
Я думаю, будущее именно за такими системами разработки и сборки.
У меня оно соотносится с цифрами — визуально чуть быстрее чем Angular.js
Я говорил про соотношение с basis.js. По ощущениям, последний визуально отрабатывает гораздо быстрее, хотя время выводится близкое…
Возможно, но Angular так же и официально, «покрывает» нишу больших приложений.
Ок. Тогда, хотелось бы от вас услышать характеристики большого приложения.
Я просто показал как можно победить узкие места, да и вообще по большому счету большинство синтетических тестов показывают «сферического коня».
В целом, да. Но это так определяется порог, когда вам нужно прибегать к «хакам».
У большинства «мейнстримовых» решений проблема именно в этом. Когда начинаем работать с большими количеством данными, начинаются проблемы, нужно думать про всякие «хаки». Мне кажется, что фреймворк должен подводить к этому на каких то безумных количествах, например, сотнях тысяч или миллионах моделей. Но не раньше (на тысячах).
В Angular Light ничего не «выпадает», все действия отрабатывают последовательно (в одной «итерации»).
Тогда как вы объясните одинаковые результаты и что визуально оно отрабатывает медленнее?
Разрабатывал большие веб-приложения на Angular, не возникло проблем с запутаностью кода.
Возможно, у нас разные представления о больших приложениях.
Вот, конечно это крайний вариант, без шаблонизатора, но показывает до куда можно опуститься, по сути директива просто дает точку позиционирования = элемент + данные, далее вы делаете что угодно.
Очень здорово, что добавили вариант с plain js. Да, так можно увидеть базовую линию, то есть ниже которой не опуститься. Заполнение правда можно сделать еще быстрее если сгенерить строку со всем html, и запихнуть через innerHTML. Правда в этом случае у нас не будет ссылок на элементы и обновление будет в несколько раз медленнее (если использовать ту же технику).
Любой шаблонизатор создает overhead, плата за универсальность, все дела. Но, по-моему, не плохой результат. Что скажете?
А реализация директивы это больше хак, чем реальное применение. То же можно проделать практически для любого решения. Так что можно сказать, что это «неспортивное поведение» ;)
Основная проблема с plain js (и соотвественно директивой), что если нам нужно поменять разметку, добавить больше значений, обработчики событий и т.д., динамически менять все это, и эти изменения делаются в множестве мест… я думаю, вы сами прекрасно знаете, что будет :)
P.S. Сначала подумал, странно что цифры выросли. И лишь потом заметил, что речь уже про 10k элементов, а не 4k :) Knockout все так же неправильно считается, у меня висит секунд 15 наверное, а показывает 1.5 — странно все это.
Нет, просто там дополнительно учитывается время рендеринга. Посмотрите в вашем варианте на Knockout.js 595ms и Angular.js 1075ms, у KO время лучше хотя визуально видно что он отрисовывается в 2 раза медленнее — т.е. цифры врут.
У того и другого свои заморочки с отложенными вычислениями.
Учитывать время рендеринга (именно отрисовки) нет смысла. Во-первых, это уже не часть измеряемого кода. Во-вторых вы не можете гарантированно сказать, когда он отработает.
То есть если мы изменяем скорость какого-то решения в целом, то имеет смысл включать все расходы (но через js всего не измерить). А если мы делаем тест, сравнивающий разные решения, то нет смысла включать оверхед, общий для всех.
В целом, я с вами согласен, что выпал рендеринг. Он занимает примерно одинаковое время. Если посмотреть на цифры, то для jQuery, Angular и basis.js цифры поменялись примерно одинаково, то есть на ~250ms на заполнении и ~150ms на обновлении. То что так сильно упало время для Knockout, скорей говорит о том, что часть работы он делает отложено и это не попадает в результат. Для Angular Light время заполнения уменьшилось больше чем на 250ms, возможно тоже что-то не учлось (или погрешность), зато обновление похоже на правду. Почему время Angular Light (inline) осталось неизменным, для меня загадка. Я думаю, что в обоих случаях выпадает часть работы. Так как в вашем варианте он близок к basis.js, но визуально работает в несколько раз медленнее.
Так оно, но это плата за «удобства», а в реальных приложениях «узкие» места можно переписать на vanilla js, например для теста выше можно было сделать директиву ng-fast-list которая не уступала бы по скорости.
Если честно, не увидел особых удобств. Код на angular запутан и его не назовешь «изящным» (но, возможно, это дело вкуса, конечно). И это на простой задаче, а если мы начнем добавляться функционал, то вы быстро обрастете кодом, и решение станет еще более запутанным.
Можно сделать дерективу? Сделайте, было бы интересно увидеть результаты. Но тогда нужно учитывать, что, например, для того же basis.js так же можно не создавать UI ноды, а использовать чисто шаблонизатор. Будет в 2-3 раза быстрее, но код будет «не очень» и не будет многих «удобств» (basis.ui как раз прячет за своим интерфейсом всю «неприятную» работу). Добавил реализацию для сравнения (файл bs_template.js).
Насчет борщика таких мыслей не было. А насчет grunt/gulp были… но есть нюансы ;)
Мы стараемся не делать решений на перспективу, у всего должен быть свой пользователь, чтобы сказать как правильно и насколько решение хорошее. Если будет необходимость в интеграции, то неприменно что нибудь придумаем ;) Тем более, что basisjs-tools можно использовать как модуль в своих скриптах (на это был расчет при проектировании).
А вот я немного переделал сам тест (методы clear просто делают свою работу, без вызова callback и меньше таймеров), и получилось так:
Выходит в вашем варианте не правильно измерялось и тестировалось, так как это добавило значительные накладные расходы (шутка ли jQuery на заполнении был в два раза медленнее, Knockout — в 3, basis.js — в 6). Малое влияние изменений на Angular Light (inline) видимо из-за того, что использовались его таймеры.
Не совсем. Если вы о докладе про данные, то там объясняется почему чаще всего медленно работает на больших количествах данных. Хранение данных в DOM наиболее частая ошибка, которая приводит к печальным результатам.
т.к. упомянутые там Ember и Backbone вроде как не используют DOM для хранения данных.
Они сами нет, но их пользователи – да. Когда стравниваются backbone и ember речь идет чисто про данные, и DOM уже не затрагивается, сравниваются разные реализации.
Хочется тесты в сравнении с другими фреймворками, особенно с Angular.js, которые можно «пощупать», наподобие
Делать хорошие тесты сложно, особенно так чтобы их мог запустить любой. Я уже давал ссылку на один, в комментарии ниже.
Ваш тест плохо организован. Не совсем понятно что вы тестируете. На результаты влияют посторонние факторы и особенность организации теста.
Так же не стоит использовать new Date, так как он не дает точность (например в Chrome дискретность 16ms). Нужно использовать performance.now() если доступен, и если нет – тогда new Date. Хотя там такие цифры что это не так страшно :)
Я добавил basis в тест: jsfiddle.net/GdE3r/1/
Цифры говорят сами за себя ;) И это при том, что другие создают только разметку, а basis – полноценные интерфейсные узлы, а у них богатый функционал.
Очень попахивает экстом и его ужасными фичами вида «перегрузка свойств в конструкторе» и «автосоздание вьюшек по конфигам».
Почему то все сравнивают с extjs, это прям тенденция :)
Перегрузки свойств в конструкторе нет, по крайней мере в том виде что в extjs. Есть нормализация, но это другое.
Предполагаю, что под «созданием вьюшек по конфигам» имеется ввиду фича extjs с xtype. Нет тут несколько другое. В следующей части будет рассказано про работу с данными, тогда станет понятно для чего на самом деле нужны childClass и childFactory. Данная статья вводная, объясняющая основные моменты и общий воркфлоу. Она делалась максимально простой, это обучающий материал, потому и примеры простые, и чем то напоминают другие фреймворки. Так что не пропустите следующую часть, она расставит точки на i.
Смутило, что вы удаляете элелементы, а потом добавляете в нужном порядке. Это конечно очень просто, но ресурсоёмко и теряет фокус. Я у себя пробегаюсь по спискам и трогаю элементы только если их действительно надо переместить.
Вы не верно поняли. А значит, в тексте плохое разъяснение. Не могли бы вы указать, что навело вас на такое мнение?
На самом деле, ничего не удаляется и перевставляется (если это конечно не перестроение DOM фрагмента по новому шаблону). Как вы правильно заметили это очень дорого. И по списку тоже не «бегаем». Узлы (basis.ui.Node) хорошо знают свою структуру и не делают лишних телодвижений без необходимости. Перемещения делаются перестановкой элементов, через insertBefore, только в том случае, если это действительно нужно.
Также я не разделяю эту любовь к requireJS. Какая разница будет у вас глобальная переменная или же зарегистрированный модуль, который доступен по глобальному имени? Те же глобальные переменные, но зачем-то спрятанные в недра глобальной функиции require.
Модульная система не связана никак с requirejs. Requirejs – это AMD, а в basis.js используется CommonJS. Реализация очень близкая к реализации node.js.
Имена никуда не зашиты. Неймспейсы (названия) проецируются на файловую систему. Для корневого неймспейса (например, basis – это корневой неймспейс) ассоцируется некоторый путь. К примеру, в статье basis.js подключается как bower_component/basis/src/basis.js, значит для basis базовый путь будет bower_component/basis/src/. Дальше использовался модуль basis.ui, его имя преобразуется в basis/ui.js. То есть точки заменяются на / и в конце подставляется расширение. К имени добавляется базовый путь и получаем путь к файлу bower_component/basis/src/basis/ui.js. То есть
Но согласитесь, первое написать гораздо проще.
Я не стал это расписывать в статье, чтобы не взрывать мозг преобразованием путей. По опыту, для многих это дается не легко.
Относительные пути — это тоже зло, потому что при переносе модуля нужно фигурно исправлять относительные ссылки в него и из него.
Суть в том, что мы должны стараться ссылать только вглубь. И даже больше, только на файлы модуля и на корневые файл вложенных модулей. В этом случае, обычно, все сводится к одной единственной замене. Это было показано в разделе про реструктуризацию файлов. Но, конечно, всегда бывают исключения.
Пока получаем только плюсы от относительных путей. То, про что вы говорите, скорей всего, про ситуацию, когда много перекрестных относительных ссылок (путей). Да, это проблема и этого нельзя допускать. Если возникается такая ситуация, то скорей всего у вас не правильно организованы модули и нужно подумать как это исправить.
Почитай про мою реализацию
Если правильно понял, то это про вычисления и данные. Про это будет в следующей части руководства. Предполагаю для вас она будет куда более интересной.
Хоть на первый взгляд многие видят сходство с extjs, на самом деле у них ничего общего.
Мощь extjs строится на готовых компонентах, и его можно назвать конструктором. Тюнить имеющие или создавать свои – занятие непростое. А без готовых компонент он практически бесполезен. К тому же он очень большой. В нем много готового, это и хорошо и плохо. Хорошо, потому что можно собрать быстро некоторое решение. Но плохо, что сложно сделать что-то свое уникальное или стилизовать.
basis.js: Компоненты которые в нем есть больше для демонстрации и для прототипирования. В каждом проекте по большей части делаются свои компоненты, это не сложно. Либо полностью заменяются шаблоны и верстка (так как представление слабосвязано с шаблоном, то ему можно подсунуть практически любой шаблон). Ну и, конечно, часто используются собственные наработки, качующие из проекта в проект. То есть в этом отношении basis является основой для создания компонент и интерфейса.
Еще, к пример, live update это не только про быстрый и удобный процесс верстки без перезагрузки страницы. Это так же адаптация представления под данные (мало данных одна верстка, много данных – другая) и такая клевая штука как темы. Еще хорошо развита работа с данными, об этом будет в следующей части. Думаю после нее отпадут вопросы о схожести с чем либо… по крайней мере с extjs точно ;)
Кстати extjs достаточно не быстрый, судя по моим экспериментам. Но мы можем сравнить, мне было бы весьма интересно.
Еще в extjs нет разделения логики и представления, нет дружелюбного сборщика (хотя может что-то поменялось?) и много чего еще. С другой стороны в basis.js тоже нет многого из того, что есть в extjs. Но у того фреймворка целая компания, куча людей, которая занимается исключительно его разработкой и развитием. Нам пока приходится только мечтать об этом :) Работа над фреймворком не является основной деятельностью, и сам он является продуктом работы над разными проектами и задачами. Так сказать собрание лучших решений, что получилось найти и различные best practices, накопленные в течении нескольких лет.
Кстати, а про какой генератор документации речь?
Насчет будущего, вижу его светлым и жизнерадостным, я оптимист ;)
basis.js старается не использовать странные стороны js и быть как можно ближе к его идеалогии. Например, года три назад мы отказали от this.inherit() (например, в Ember такой метод называется this._super()) – вызов переопределенного метода, так как поддержание это механизма дорого для производительности. Отказавшись такого хелпера, мы получили буст производительности в 2 раза (сам был в шоке). Сейчас мы пишем так
var MyClass = basis.ui.Node.subclass({
method: function(a, b){
basis.ui.Node.prototype.method.call(this, a, b);
...
}
});
Длинно, но зато быстро. Да и сейчас редко, когда нужно переопределять методы (для этого тоже было сделано не мало).
ES6 вместе с тем нацелено решать проблемы языка. В частности эту проблему. С ES6 мы сможем писать так:
А те фреймворки, что используются свой this.inherit/super/etc никакого преимущества не получат.
Еще мы смотрим на модульность в ES6. Выглядит так, что мы сможем адаптировать текущую реализацию чтобы
// помимо этого
var Node = require('basis.ui.Node');
// работало и это
import Node from 'basis.ui';
Что касается Dart, то тут затрудняюсь ответить. Я не уверен, что получится подружить реализацию классов basis.js с идеалогией Dart, а на ней многое строится. Но я пока не копал эту тему и возможно там не все так страшно.
Unit-тестированию не мешает, а функциональному тестированию мешает. Вы не можете провести функциональное тестирование до момента создания консистентного состояния системы, которое достигается успешной сборкой проекта.
Все равно не до конца понимаю, почему dev-версия не может иметь консистентного состояния? Возможно имеется ввиду конечное состояние, которое отдается пользователю, и вы хотите тестировать именно его? В этом случае вы так же делаете сборку, а потом тестируете.
Мелкие правки делаются гораздо чаще и проверяются вручную, прежде чем задача будет выполнена и потребуется тестирование. Вы же не делаете прогон тестов при каждом сохранении файла. Обычно функциональное тестирование проводится на законченных задачах и занимает куда больше времени чем сборка, будь она инкрементальная или нет. Опять же, вы можете прогнать тесты сначала на dev-версии (и это уже покажет проблемы, если они есть), а потом уже на сборке, что можно делать не так часто.
А что насчет минификации выходных файлов? Суть в том, чтобы после трансляции coffee->js склеить и минифицировать все JS файлы. Как вы это будете делать, если собираетесь компилировать Coffee на клиенте? Это проигрыш в скорости, как с точки зрения eval'a, так и с точки зрения трафика.
По той ссылке, что я вам привел есть и про сборку. При сборке coffee будет транслироваться в js, этот код будет обернут, проанализирован, сконкатенирован и минимизирован на ряду с остальным javascript. Трансляция coffee->js на клиенте происходит только в dev режиме.
Ну, во-первых это очень похоже на web-компоненты(см. polymer, mozilla x-tags), особенно идея с подключением стилей для конкретных объектов. По-факту, ваша система позволяет производить инкапсуляцию css, js и html в рамках компонента, верно? В таком случае это 1 в 1 повторяет идеологию web-компонентов.
Да, верно подмечено, это похоже на web-components. Но там есть ряд отличий и шаблоны basis.js дают гораздо больше, чем просто инкапсуляция.
Нет, но у меня всегда подключается gzip-пакет, в котором лежат все JS и CSS. А т.к. мои «фреймворки» позволяют мне выбрать шаблонизатор, с которым я буду работать, то компилируется этот код в JS, и позднее склеивается и минифицируется вместе с остальными JS файлами, тем самым получая максимально маленький размер трафика, который мне надо отдать пользователю. Это уже не говоря о том, что я могу провести вашу проверку на использование стилей в несколько раз быстрее, пробежав всего по 2 файлам: 1 css(результирующий) и 1 js(шаблоны), в то время как при вашем подходе мне придется открывать по 1 все стили и все шаблоны.
Как я уже писал, сборщик basisjs-tools тоже оптимизирует структуру шаблонов при сборке.
Пробежаться у вас вряд ли получится, потому что шаблонизаторы, те что вы имеете ввиду, прозводят функции, которые конкатенируют строки. Вы не можете предсказать результат такой конкатенации, так как там подставляются значения (переменные). Поэтому это одна из главных проблем — узнать на каком элементе, какие классы бывают. А еще, в таком подходе, те же классы часто меняются из представления. Например, $(this.el).addClass('foo-' + bar + '-' + baz) — вы можете сказать какой класс тут будет в результате? Вам так же не поможет поиск, если вы видите класс в селекторе, вы не сможете его найти в шаблоне, если он динамический, и так просто ответить на вопрос используется ли он.
В «нашем» подходе не нужно открывать файлы по одному. Вы просто описываете шаблоны и стили. В basisjs-tools есть команда extract, которая позволяет извлекать факты о вашем приложении. По сути она выполняется перед сборкой, так как сборщик использует эту иформацию, чтобы уже произвести результат. Так вот, вызвав такую команду можно получить список проблем, вам напишут в каком файле и какая проблема. Так как вы разрабатываете постепенно, то так же постепенно и исправляете проблемы и миллиона варнингов вы не увидите. Можно так же использовать плагин для Google Chrome (про который говорилось в статье), тогда не нужно выполнять эту команду, а можно посмотреть все варнинги в Developer Tools -> basis.js -> Warnings. На скриншоте, как раз видно сейчас в проекте 2 варнинга, они как раз про то, что использованы id для которых нет стилей.
Что насчет тестирования? Я придерживаюсь разработки через тестирование, и т.к. я тестирую не отдельные функции, а пользовательские сценарии, я бы хотел иметь собранный проект, т.к. чаще всего пользовательские действия затрагивают сразу несколько модулей, как быть тогда?
Отсутсвие сборки никак не мешает тестированию. Или я чего-то не понимаю?
Только что вам даст трансляция coffee->js без возможности сохранить результат? Или вы будете eval'ить код, который будет выходить из такого транслятора? И будете делать это для всех coffee файлов? Я могу сказать, что вы здесь ничего не выигрываете.
А зачем его сохранять? Да, код будет eval'ится (через new Function). Так же eval'ится и код всех модулей, на этом построена работа commonjs. Node.js делает точно так же. И, поверьте, в этом нет проблемы.
Когда вы делаете сборку, то в процессе код оборачивается в функции и в собранном варианте уже не будет eval'ится.
Здесь дело не в мифическом выигрыше, а в удобстве. Например, вам не нужно хранить временные файлы (результат компиляции coffeescript), если код не скомпилится вы увидите это в консоли браузера, в панели sources вы видите все файлы ровно так как они располагаются в вашей файловой системе etc.
Действительно, можно, однако инкрементальные сборки придумали как раз, чтобы уйти от того, что у вас в одной вкладки консоли открыт sass watch, в другой coffee watch, а в третей бог весть что. И более того, это по-прежнему не покрывает кейсов тестирования после изменения coffee файлов.
Если нет какой то функции, и она нужна — ее можно добавить. В вашем примере вотчер нужен только для sass.
Предполагаю, что мы подумаем насчет системы плагинов и тогда можно будет использовать один вотчер для любых файлов и работ, в том числе и для sass. В конечном итоге, проект open source и вы сами можете поучавствовать в имплементации необходимого функционала.
Вы считаете, что таск-раннеры а-ля Grunt, или системы сборки типо Gulp, Broccoli, Brunch не пользуются спросом?
Вы меня не правильно поняли, речь шла о поддержке sass в basisjs-tools, а не о таск-раннерах.
Не могу представить себе иного сценария, как файл index.html как корень графа, из которого идут две ветви: css и js, в которых в css отражаются зависимости директивы import, а в js — amd/commonJS модулей. Как это помогает разработке?
Html подключает javascript, css, изображения и другие файлы. Javascript подключает другие javascript модули и другой контент, такой как шаблоны, словари, json etc, для некоторых вещей свои синтаксические конструкции. Шаблоны — css, изображения, словари, другие шаблоны. И далее…
Chrome Dev Tools -> вкладка audit -> start
У вас всегда вся возможная разметка на странице? Речь не про статичные сайты, а про приложения, где динамически генерируются, вставляются, удаляются представления в зависимости от ситуации, а еще добавляются и удаляются классы, меняется разметка. Вариантов состояния разметки настолько много, что вы просто не сможете сделать так, чтобы audit правильно показал что используется, а что нет. Если речь, конечно, не про «Hello world» ;)
Хотел вам ответить, но mavrin уже не плохо справился с этим :)
Немного добавлю.
Таких тестов, чтоб «бери и пробуй» пока мало. Вот один из них, что я делал для последнего доклада: тест моделей lahmatiy.github.io/lib-compare/ (репозитарий), сравниваются два разных модуля basis, Backbone и Ember.
livereload.com/ — а такое решение не устраивает? Или я что-то не так понял?
Livereload и подобные, перегружают страницу, когда меняется какой то файл. С basis.js вам нужно это делать только для javascript файлов. Если вы меняете шаблоны, стили или словари локализации этого делать не надо. Базис перестраивает часть страницы, применяя изменения. То есть в этом случае нет перезагрузки страницы. Это не критично для сайтов, но очень критично для приложений, так как нам нужно сохранять состояние. Я планирую записать скринкаст, думаю из него все станет ясно. А пока можете либо проследовать руководству, и попробовать у себя. Либо поиграться в интерактивном туре, например, на этом слайде: basisjs.com/basisjs/tour/#ui_loose_coupling. Там сверху можно переключать закладки (файлы), код можно менять. Попробуйте выбрать пункт списка внизу, а потом менять файлы *.tmpl или *.css.
Фреймворк, очень хорошо подходит для больших проектов
Как и любой другой фреймворк, собственно.
Все очень зависит от того про какие размеры мы говорим, для каждого это своя цифра. Для меня большой проект это сотня другая модулей, еще больше представлений, десятки типов данных (моделей), тысяча другая файлов. В такой ситуации важно насколько читаемый код в итоге получается. Насколько просто реструктурировать проект, находить проблемы и понимать откуда «ноги растут» (например, вот кнопка — а в каком модуле она описана, где ее шаблон?).
Что касается описываемых вами недостатков — это даже не недостатки, а, скорее, небольшие трудности, которые переживает только что зародившийся проект.
Очень хорошо сказано :) Правда фреймворку уже 7-8 лет… но он только начинает выходить, так сказать, в массы.
Все модули basis.js, компоненты и шаблоны в сумме дают 389Kb (111Kb gzip). Но все модули никогда не используются, обычно доля кода фреймворка ~250Kb, тогда как размер самого приложения (достаточно большого) 800-900Kb (~250Kb в gzip). Фреймворк позволяет писать достаточно компактный код.
Сборщик basis.js собирает все в один пакет. Так проще и дешевле — скрипт загружается один раз и кешируется, при этом делается один запрос на js и один для css. Код тем не менее иниацилизируется лениво, по мере активации той или иной функциональности — потому старт достаточно быстрый.
Тут определенно что-то лишнее. Если цель добиться высокой производительности, нужно забыть про jQuery, селекторы, html и render. Посмотри в сторону dom-based шаблонизаторов. Сейчас этой дорогой идут basis.js, react.js, ractive и даже meteor. В ember тоже идут в эту сторону, создавая HTMLBars. Вот пара моих докладов по этому поводу: раз и два.
Вообще советую посмотреть basis.js, в нем найдешь много знакомого. Например, те же именованные дочерние представления (сателлиты), или некоторые вещи из работы с данными и др. Только это все более развито…
Если не читал, вот первая часть руководства по фреймворку.
Knockout не framework, angular не MV*. Хотя, конечно, зависит от того, что вы в это вкладываете. Если любая обвязка над значением и биндинги — это MV* фреймворк, то ок.
Расскажите, где вы увидили прямые манипуляции с DOM в решение basis.js?
basis является каким то там MV* (не заморачиваюсь на эту тему) — есть и model, и своего рода view и controller.
Модель не является обязательной сущностью. Эту задачу успешно может выполнять и контролер, и представление.
В любом случае «пузкомерка» не для того, чтобы разделить решения на категории и не было особых ограничений. Есть конкретная задача, нужно ее решить.
Конечному пользователю все равно на чем написано приложение и какие патерны используются, для него важно «работает» и «не тормозит».
Куда интереснее сколько времени будет генерироваться представление, когда в него добавят сразу 500-1000 записей. Ведь это обычный кейс, списки приходят от сервера (из localStorage) и мы их добавляем в представление.
Так же если приводите результаты измерений, то лучше выводить их табличкой. Да и избегать оценок «мгновенно» и т.п. — нужны цифры. Тем более их можно получить тем же способом, что вы использовали для основного теста.
Это, конечно, здорово, что вы взяли табличку из моей презентации. Но она не для того, чтобы гнуть пальцы или принижать чьи-то других, а для того, чтобы показать как быстро справляются с задачей те или иные решения. Методика измерений совершенно разная, и в данном случае нельзя сопоставлять цифры.
Судя по написанному в статье, работа проделана не малая. Уважайте других, пинать и критиковать проще, чем сделать что-то полезное.
Я поправил, теперь больше похоже на правду: plnkr.co/edit/RzZP7146NgWHlVchXZF7?p=preview
Чтобы не считать расходы на рендеринг я спрятал блок, куда рендерятся списки. Добавил галочку, чтобы можно было учитывать это время. Можно заметить, что даже спрятать/показать список из 10k элементов получается не быстро. Это время у всех будет практически одинаковым.
Смущает, что используется setTimeout(callback, 0) — это может накидывать дополнительное время.
Так же tenshi добавил свое решение и немного изменил решения на jQuery и Knockout, они стали побыстрее.
В итоге у меня получились такие цифры:
Конечно, нужно измерять каждое решение в отдельности. Некоторые, особо прожорливые до памяти, съедают ее столько, что это сильно сказывается на времени выполнения других.
В соседнем посте я писал о basis.js. Так вот в dev все разобрано, тоже есть live update (только js не обновляем, это нельзя сделать безопасно). Перед деплоем все это собирается. По принципу «граф на входе, граф на выходе», которые отстраиваются самостоятельно, по переданному индексному html файлу.
Я думаю, будущее именно за такими системами разработки и сборки.
Я говорил про соотношение с basis.js. По ощущениям, последний визуально отрабатывает гораздо быстрее, хотя время выводится близкое…
Ок. Тогда, хотелось бы от вас услышать характеристики большого приложения.
В целом, да. Но это так определяется порог, когда вам нужно прибегать к «хакам».
У большинства «мейнстримовых» решений проблема именно в этом. Когда начинаем работать с большими количеством данными, начинаются проблемы, нужно думать про всякие «хаки». Мне кажется, что фреймворк должен подводить к этому на каких то безумных количествах, например, сотнях тысяч или миллионах моделей. Но не раньше (на тысячах).
Тогда как вы объясните одинаковые результаты и что визуально оно отрабатывает медленнее?
Возможно, у нас разные представления о больших приложениях.
Очень здорово, что добавили вариант с plain js. Да, так можно увидеть базовую линию, то есть ниже которой не опуститься. Заполнение правда можно сделать еще быстрее если сгенерить строку со всем html, и запихнуть через innerHTML. Правда в этом случае у нас не будет ссылок на элементы и обновление будет в несколько раз медленнее (если использовать ту же технику).
Любой шаблонизатор создает overhead, плата за универсальность, все дела. Но, по-моему, не плохой результат. Что скажете?
А реализация директивы это больше хак, чем реальное применение. То же можно проделать практически для любого решения. Так что можно сказать, что это «неспортивное поведение» ;)
Основная проблема с plain js (и соотвественно директивой), что если нам нужно поменять разметку, добавить больше значений, обработчики событий и т.д., динамически менять все это, и эти изменения делаются в множестве мест… я думаю, вы сами прекрасно знаете, что будет :)
P.S. Сначала подумал, странно что цифры выросли. И лишь потом заметил, что речь уже про 10k элементов, а не 4k :) Knockout все так же неправильно считается, у меня висит секунд 15 наверное, а показывает 1.5 — странно все это.
У того и другого свои заморочки с отложенными вычислениями.
Учитывать время рендеринга (именно отрисовки) нет смысла. Во-первых, это уже не часть измеряемого кода. Во-вторых вы не можете гарантированно сказать, когда он отработает.
То есть если мы изменяем скорость какого-то решения в целом, то имеет смысл включать все расходы (но через js всего не измерить). А если мы делаем тест, сравнивающий разные решения, то нет смысла включать оверхед, общий для всех.
В целом, я с вами согласен, что выпал рендеринг. Он занимает примерно одинаковое время. Если посмотреть на цифры, то для jQuery, Angular и basis.js цифры поменялись примерно одинаково, то есть на ~250ms на заполнении и ~150ms на обновлении. То что так сильно упало время для Knockout, скорей говорит о том, что часть работы он делает отложено и это не попадает в результат. Для Angular Light время заполнения уменьшилось больше чем на 250ms, возможно тоже что-то не учлось (или погрешность), зато обновление похоже на правду. Почему время Angular Light (inline) осталось неизменным, для меня загадка. Я думаю, что в обоих случаях выпадает часть работы. Так как в вашем варианте он близок к basis.js, но визуально работает в несколько раз медленнее.
Если честно, не увидел особых удобств. Код на angular запутан и его не назовешь «изящным» (но, возможно, это дело вкуса, конечно). И это на простой задаче, а если мы начнем добавляться функционал, то вы быстро обрастете кодом, и решение станет еще более запутанным.
Можно сделать дерективу? Сделайте, было бы интересно увидеть результаты. Но тогда нужно учитывать, что, например, для того же basis.js так же можно не создавать UI ноды, а использовать чисто шаблонизатор. Будет в 2-3 раза быстрее, но код будет «не очень» и не будет многих «удобств» (basis.ui как раз прячет за своим интерфейсом всю «неприятную» работу). Добавил реализацию для сравнения (файл bs_template.js).
Мы стараемся не делать решений на перспективу, у всего должен быть свой пользователь, чтобы сказать как правильно и насколько решение хорошее. Если будет необходимость в интеграции, то неприменно что нибудь придумаем ;) Тем более, что basisjs-tools можно использовать как модуль в своих скриптах (на это был расчет при проектировании).
Вот цифры по вашей ссылке
А вот я немного переделал сам тест (методы clear просто делают свою работу, без вызова callback и меньше таймеров), и получилось так:
Выходит в вашем варианте не правильно измерялось и тестировалось, так как это добавило значительные накладные расходы (шутка ли jQuery на заполнении был в два раза медленнее, Knockout — в 3, basis.js — в 6). Малое влияние изменений на Angular Light (inline) видимо из-за того, что использовались его таймеры.
Вот работающий вариант: jsfiddle.net/GdE3r/2/
Не совсем. Если вы о докладе про данные, то там объясняется почему чаще всего медленно работает на больших количествах данных. Хранение данных в DOM наиболее частая ошибка, которая приводит к печальным результатам.
Они сами нет, но их пользователи – да. Когда стравниваются backbone и ember речь идет чисто про данные, и DOM уже не затрагивается, сравниваются разные реализации.
Делать хорошие тесты сложно, особенно так чтобы их мог запустить любой. Я уже давал ссылку на один, в комментарии ниже.
Ваш тест плохо организован. Не совсем понятно что вы тестируете. На результаты влияют посторонние факторы и особенность организации теста.
Так же не стоит использовать new Date, так как он не дает точность (например в Chrome дискретность 16ms). Нужно использовать performance.now() если доступен, и если нет – тогда new Date. Хотя там такие цифры что это не так страшно :)
Я добавил basis в тест: jsfiddle.net/GdE3r/1/
Цифры говорят сами за себя ;) И это при том, что другие создают только разметку, а basis – полноценные интерфейсные узлы, а у них богатый функционал.
Почему то все сравнивают с extjs, это прям тенденция :)
Перегрузки свойств в конструкторе нет, по крайней мере в том виде что в extjs. Есть нормализация, но это другое.
Предполагаю, что под «созданием вьюшек по конфигам» имеется ввиду фича extjs с xtype. Нет тут несколько другое. В следующей части будет рассказано про работу с данными, тогда станет понятно для чего на самом деле нужны childClass и childFactory. Данная статья вводная, объясняющая основные моменты и общий воркфлоу. Она делалась максимально простой, это обучающий материал, потому и примеры простые, и чем то напоминают другие фреймворки. Так что не пропустите следующую часть, она расставит точки на i.
Вы не верно поняли. А значит, в тексте плохое разъяснение. Не могли бы вы указать, что навело вас на такое мнение?
На самом деле, ничего не удаляется и перевставляется (если это конечно не перестроение DOM фрагмента по новому шаблону). Как вы правильно заметили это очень дорого. И по списку тоже не «бегаем». Узлы (basis.ui.Node) хорошо знают свою структуру и не делают лишних телодвижений без необходимости. Перемещения делаются перестановкой элементов, через insertBefore, только в том случае, если это действительно нужно.
Модульная система не связана никак с requirejs. Requirejs – это AMD, а в basis.js используется CommonJS. Реализация очень близкая к реализации node.js.
Имена никуда не зашиты. Неймспейсы (названия) проецируются на файловую систему. Для корневого неймспейса (например, basis – это корневой неймспейс) ассоцируется некоторый путь. К примеру, в статье basis.js подключается как
bower_component/basis/src/basis.js, значит для basis базовый путь будет bower_component/basis/src/. Дальше использовался модуль basis.ui, его имя преобразуется в basis/ui.js. То есть точки заменяются на / и в конце подставляется расширение. К имени добавляется базовый путь и получаем путь к файлуbower_component/basis/src/basis/ui.js. То естьНо согласитесь, первое написать гораздо проще.
Я не стал это расписывать в статье, чтобы не взрывать мозг преобразованием путей. По опыту, для многих это дается не легко.
Суть в том, что мы должны стараться ссылать только вглубь. И даже больше, только на файлы модуля и на корневые файл вложенных модулей. В этом случае, обычно, все сводится к одной единственной замене. Это было показано в разделе про реструктуризацию файлов. Но, конечно, всегда бывают исключения.
Пока получаем только плюсы от относительных путей. То, про что вы говорите, скорей всего, про ситуацию, когда много перекрестных относительных ссылок (путей). Да, это проблема и этого нельзя допускать. Если возникается такая ситуация, то скорей всего у вас не правильно организованы модули и нужно подумать как это исправить.
Если правильно понял, то это про вычисления и данные. Про это будет в следующей части руководства. Предполагаю для вас она будет куда более интересной.
Хоть на первый взгляд многие видят сходство с extjs, на самом деле у них ничего общего.
Мощь extjs строится на готовых компонентах, и его можно назвать конструктором. Тюнить имеющие или создавать свои – занятие непростое. А без готовых компонент он практически бесполезен. К тому же он очень большой. В нем много готового, это и хорошо и плохо. Хорошо, потому что можно собрать быстро некоторое решение. Но плохо, что сложно сделать что-то свое уникальное или стилизовать.
basis.js: Компоненты которые в нем есть больше для демонстрации и для прототипирования. В каждом проекте по большей части делаются свои компоненты, это не сложно. Либо полностью заменяются шаблоны и верстка (так как представление слабосвязано с шаблоном, то ему можно подсунуть практически любой шаблон). Ну и, конечно, часто используются собственные наработки, качующие из проекта в проект. То есть в этом отношении basis является основой для создания компонент и интерфейса.
Еще, к пример, live update это не только про быстрый и удобный процесс верстки без перезагрузки страницы. Это так же адаптация представления под данные (мало данных одна верстка, много данных – другая) и такая клевая штука как темы. Еще хорошо развита работа с данными, об этом будет в следующей части. Думаю после нее отпадут вопросы о схожести с чем либо… по крайней мере с extjs точно ;)
Кстати extjs достаточно не быстрый, судя по моим экспериментам. Но мы можем сравнить, мне было бы весьма интересно.
Еще в extjs нет разделения логики и представления, нет дружелюбного сборщика (хотя может что-то поменялось?) и много чего еще. С другой стороны в basis.js тоже нет многого из того, что есть в extjs. Но у того фреймворка целая компания, куча людей, которая занимается исключительно его разработкой и развитием. Нам пока приходится только мечтать об этом :) Работа над фреймворком не является основной деятельностью, и сам он является продуктом работы над разными проектами и задачами. Так сказать собрание лучших решений, что получилось найти и различные best practices, накопленные в течении нескольких лет.
Кстати, а про какой генератор документации речь?
Насчет будущего, вижу его светлым и жизнерадостным, я оптимист ;)
basis.js старается не использовать странные стороны js и быть как можно ближе к его идеалогии. Например, года три назад мы отказали от this.inherit() (например, в Ember такой метод называется this._super()) – вызов переопределенного метода, так как поддержание это механизма дорого для производительности. Отказавшись такого хелпера, мы получили буст производительности в 2 раза (сам был в шоке). Сейчас мы пишем так
Длинно, но зато быстро. Да и сейчас редко, когда нужно переопределять методы (для этого тоже было сделано не мало).
ES6 вместе с тем нацелено решать проблемы языка. В частности эту проблему. С ES6 мы сможем писать так:
А те фреймворки, что используются свой this.inherit/super/etc никакого преимущества не получат.
Еще мы смотрим на модульность в ES6. Выглядит так, что мы сможем адаптировать текущую реализацию чтобы
Что касается Dart, то тут затрудняюсь ответить. Я не уверен, что получится подружить реализацию классов basis.js с идеалогией Dart, а на ней многое строится. Но я пока не копал эту тему и возможно там не все так страшно.
Все равно не до конца понимаю, почему dev-версия не может иметь консистентного состояния? Возможно имеется ввиду конечное состояние, которое отдается пользователю, и вы хотите тестировать именно его? В этом случае вы так же делаете сборку, а потом тестируете.
Мелкие правки делаются гораздо чаще и проверяются вручную, прежде чем задача будет выполнена и потребуется тестирование. Вы же не делаете прогон тестов при каждом сохранении файла. Обычно функциональное тестирование проводится на законченных задачах и занимает куда больше времени чем сборка, будь она инкрементальная или нет. Опять же, вы можете прогнать тесты сначала на dev-версии (и это уже покажет проблемы, если они есть), а потом уже на сборке, что можно делать не так часто.
По той ссылке, что я вам привел есть и про сборку. При сборке coffee будет транслироваться в js, этот код будет обернут, проанализирован, сконкатенирован и минимизирован на ряду с остальным javascript. Трансляция coffee->js на клиенте происходит только в dev режиме.
Да, верно подмечено, это похоже на web-components. Но там есть ряд отличий и шаблоны basis.js дают гораздо больше, чем просто инкапсуляция.
Как я уже писал, сборщик basisjs-tools тоже оптимизирует структуру шаблонов при сборке.
Пробежаться у вас вряд ли получится, потому что шаблонизаторы, те что вы имеете ввиду, прозводят функции, которые конкатенируют строки. Вы не можете предсказать результат такой конкатенации, так как там подставляются значения (переменные). Поэтому это одна из главных проблем — узнать на каком элементе, какие классы бывают. А еще, в таком подходе, те же классы часто меняются из представления. Например,
$(this.el).addClass('foo-' + bar + '-' + baz)— вы можете сказать какой класс тут будет в результате? Вам так же не поможет поиск, если вы видите класс в селекторе, вы не сможете его найти в шаблоне, если он динамический, и так просто ответить на вопрос используется ли он.В «нашем» подходе не нужно открывать файлы по одному. Вы просто описываете шаблоны и стили. В basisjs-tools есть команда extract, которая позволяет извлекать факты о вашем приложении. По сути она выполняется перед сборкой, так как сборщик использует эту иформацию, чтобы уже произвести результат. Так вот, вызвав такую команду можно получить список проблем, вам напишут в каком файле и какая проблема. Так как вы разрабатываете постепенно, то так же постепенно и исправляете проблемы и миллиона варнингов вы не увидите. Можно так же использовать плагин для Google Chrome (про который говорилось в статье), тогда не нужно выполнять эту команду, а можно посмотреть все варнинги в Developer Tools -> basis.js -> Warnings. На скриншоте, как раз видно сейчас в проекте 2 варнинга, они как раз про то, что использованы id для которых нет стилей.
Отсутсвие сборки никак не мешает тестированию. Или я чего-то не понимаю?
А зачем его сохранять? Да, код будет eval'ится (через new Function). Так же eval'ится и код всех модулей, на этом построена работа commonjs. Node.js делает точно так же. И, поверьте, в этом нет проблемы.
Когда вы делаете сборку, то в процессе код оборачивается в функции и в собранном варианте уже не будет eval'ится.
Здесь дело не в мифическом выигрыше, а в удобстве. Например, вам не нужно хранить временные файлы (результат компиляции coffeescript), если код не скомпилится вы увидите это в консоли браузера, в панели sources вы видите все файлы ровно так как они располагаются в вашей файловой системе etc.
Если нет какой то функции, и она нужна — ее можно добавить. В вашем примере вотчер нужен только для sass.
Предполагаю, что мы подумаем насчет системы плагинов и тогда можно будет использовать один вотчер для любых файлов и работ, в том числе и для sass. В конечном итоге, проект open source и вы сами можете поучавствовать в имплементации необходимого функционала.
Вы меня не правильно поняли, речь шла о поддержке sass в basisjs-tools, а не о таск-раннерах.
Html подключает javascript, css, изображения и другие файлы. Javascript подключает другие javascript модули и другой контент, такой как шаблоны, словари, json etc, для некоторых вещей свои синтаксические конструкции. Шаблоны — css, изображения, словари, другие шаблоны. И далее…
У вас всегда вся возможная разметка на странице? Речь не про статичные сайты, а про приложения, где динамически генерируются, вставляются, удаляются представления в зависимости от ситуации, а еще добавляются и удаляются классы, меняется разметка. Вариантов состояния разметки настолько много, что вы просто не сможете сделать так, чтобы audit правильно показал что используется, а что нет. Если речь, конечно, не про «Hello world» ;)
Немного добавлю.
Таких тестов, чтоб «бери и пробуй» пока мало. Вот один из них, что я делал для последнего доклада: тест моделей lahmatiy.github.io/lib-compare/ (репозитарий), сравниваются два разных модуля basis, Backbone и Ember.
Livereload и подобные, перегружают страницу, когда меняется какой то файл. С basis.js вам нужно это делать только для javascript файлов. Если вы меняете шаблоны, стили или словари локализации этого делать не надо. Базис перестраивает часть страницы, применяя изменения. То есть в этом случае нет перезагрузки страницы. Это не критично для сайтов, но очень критично для приложений, так как нам нужно сохранять состояние. Я планирую записать скринкаст, думаю из него все станет ясно. А пока можете либо проследовать руководству, и попробовать у себя. Либо поиграться в интерактивном туре, например, на этом слайде: basisjs.com/basisjs/tour/#ui_loose_coupling. Там сверху можно переключать закладки (файлы), код можно менять. Попробуйте выбрать пункт списка внизу, а потом менять файлы *.tmpl или *.css.
Все очень зависит от того про какие размеры мы говорим, для каждого это своя цифра. Для меня большой проект это сотня другая модулей, еще больше представлений, десятки типов данных (моделей), тысяча другая файлов. В такой ситуации важно насколько читаемый код в итоге получается. Насколько просто реструктурировать проект, находить проблемы и понимать откуда «ноги растут» (например, вот кнопка — а в каком модуле она описана, где ее шаблон?).
Очень хорошо сказано :) Правда фреймворку уже 7-8 лет… но он только начинает выходить, так сказать, в массы.