Comments 56
Вместо temple берем jsx без реакта и получаем работу с евентами, легкий биндинг и такую же компиляцию в js. Биндим нужные части интерфейса к переменным стейта — получаем быстрый рендер с перерисовкой только того что изменилось, самим броузером, нативно. Почему не работают компоненты — я так и не понял.
А еще про демку nativescript, которая притормаживает на лоу енд устройстве с Андроид 5.1, впрочем где многие кордова приложения работают «влёт»
- Веб-компоненты не отменяют других методов оптимизации. В чем проблема? Таким образом я делаю рендер внутри компонентов очень просто и работает он очень быстро.
- "200 Кбайт для библиотеки веб-компонентов – это слишком много" — ЧЕГО?!!! 40кб полифил + 18 кб на Polymer + gzip… Что за бред?
- "Запросы к DOM — это медленно" — запросы поиска по селекторам? Простите, но делать это при каждом изменении данных может только дибил, или совсем неопытный разработчик. Коллекции ссылок на инсерты создаются при инициализации приложения, по ним потом раскладываются изменения БЕЗ всяких вотчеров на DOM-элементах. Готовьте шаблоны в DocumentFragment, и потом добавляйте их в DOM, в чем проблема? Это несколько строк кода, какие еще фреймворки для этого нужны?
Весь этот доклад, при всей его подкрепленности бенчмарками — просто фейл какой-то.
1,2. Из контекста же понятно, что о стандарте WebComponents тут речи не идёт. Веб компоненты тут упоминаются в более широком смысле — виджеты, зачастую сторонние.
3,4. Опять же, под запросами тут понимается "обращение к DOM API", а не "querySelector".
А докладу не хватает живых примеров, а не синтетических бенчмарков. Было бы не плохо, чтобы автор запилил ToDoMVC, чтобы его можно было добавить в этот бенчмарк: https://github.com/nin-jin/todomvc/tree/master/benchmark
Нет, из контекста такого не понятно. Более того, не понятно причем тут JSDOM, которая вроде как вообще для node.js — ничего не рендерит и не делает никакой связанной с этим асинхронщины (или я что-то путаю?).
Сторонние виджеты, как повод отказаться от технологии для реализации своего проекта — это вообще сюр какой-то.
"обращение к DOM API", а не "querySelector" — нет, и про это есть слайды восхваляющие скорость DOM API, вы как-то невнимательно, видимо, смотрели.
Господа минусующие могут пояснить с чем не согласны? Веб-компоненты вовсе не требуют дублирования своих зависимостей при сборке, даже если они устанавливаются менеджером зависимостей в ваш проект. Сами эти зависимости в базовом виде весьма легкие. Первый тезис доклада о веб-компонентах — полный бред, это я говорю как человек который давно с ними работает.
По поводу "тут понимается "обращение к DOM API", а не "querySelector" — А "первое, что подсказал Goggle, это «Используйте DOM API»" — это не цитата из статьи? Я это сам придумал?
в чем проблема?
Хотя бы в создании коллекции ссылок на ноды. Особенно, если структура DOM динамическая, если в разные моменты времени общей нодой в DOM будет в лучшем случае div в body.
Коллекции создаются для локального DOM компонента каждым компонентом. Вся динамика внутри этого компонента инкапсулирована, перерисовывается только то, что нужно, при изменении модели нужного компонента (нужна конечно правильная декомпозиция моделей). Никаких проблем. Если перестраивается вся страница — браузер все равно ее перерисовывает всю, и оптимизация тут уже будет на уровне тяжелых для отрисовки элементов (флексбоксов например или анимаций при отрисовке). При правильной декомпозиции интерфейса никаких проблем с "общей нодой" не возникает.
Слайды презентации: http://www.slideshare.net/profyclub_ru/dom-aviasalesru (чтоб "руками" ссылки не набирать :) ).
- Шаблонизатор temple на github
- Обработка событий от FT Labs ftdomdelegate
Добавим тогда сюда ссылку на новую реинкарнацию этой идеи — http://monkberry.js.org/
>>Намного более качественный фреймворк, на мой взгляд, это ReactJS. Судя по тому, как бурлит Интернет, каждый первый программист, даже не всегда фронтендщик, пользовался Angular и в восторге от него. Я не считаю, что virtualDOM может ускорить работу с DOM.
По смыслу, откуда здесь взялся Angular, если вроде речь про ReactJS?
И самый эпик:
>>Сначала господа из Google пару лет продавали нам React как штуку, которая с помощью virtualDOM адски ускоряет работу с DOM, а потом оказывается, что чтобы быстро работать с DOM, нужно исключить virtualDOM.
Может всё таки не Google, а Facebook?
По пунктам:
кэширование не работает
первый контакт с сайтом у человека – самый критичный
Если при первой загрузке сайт тормозит, то второй раз пользователь может к вам не вернуться.
Если человек нажал на кнопку или чекбокс, и при этом интерфейс не отреагировал мгновенно, пользователь может закрыть сайт и уйти на другой сайт, туда, где интерфейс отзывчив.
Вот к этим аргументам у меня больше всего претензий. Нам рисуют пользователя, как какого-то максималиста, помешанного на удобстве интерфейсов. Малейший притормоз, он тут же закрывает вкладку и стирает историю, чтобы забыть дорогу на ваш сайт. Это чушь. Просто маркетологический бред. Человек заходит на сайт не ради интерфейса. Он заходит туда ради контента. Если мне на сайте что-то нужно, то я буду им пользоваться. Чтобы уйти, мне нужен, если не полный аналог, то хотя бы приемлемая альтернатива тому контенту, тем услугам, что сайт мне предоставлял. Если это информационный сайт, нужна аналогичная информация. Если это магазин, то мне важны цены в нем и условия доставки, а вовсе не быстрота работы чекбоксов. И пойти обратно в гугл, искать альтернативу, меня может вынудить только по-настоящему паршивый интерфейс и серьезные лаги. Сайт действительно должен быть ужасен.
если вы делаете много лишних действий, вы греете процессор, и у него не хватает времени, чтобы обсчитать анимацию на интерфейсе или что-то просто пририсовать
если вы создаете много лишних объектов, это создает нагрузку на garbage collector
Это очевидные вещи. Любой программист должен их понимать. Зачем вообще делать много лишних действий, и создавать много лишних объектов. Сам тот факт, что они лишние, говорит о том, что их надо убрать. Вопрос лишь в том, как определить, что является лишним, а что нужным.
Если у вас single page application, то 200-300, иногда даже 400 Кбайт javascript вы можете себе позволить.
На чем основано данное соображение? Почему именно 400 Кбайт? Почему не 500? Или 650?
Однако же, компонентный веб, в направлении которого мы с вами весело движемся, подразумевает, что страницы строятся из разных веб-компонент. Более того, эти веб-компоненты зачастую произведены в разных компаниях и приходят со своим пакетом.
А как по-другому делать что-то крупное? В любом случае, без повтороного использования кода, без готовых компонентов и библиотек, мы не сможем развивать программирование.
Представим себе страницу, на которую вставлено десяток виджетов: виджет курсов валют, погоды, авиабилетов, черта в ступе чего… И каждый из этих компонент весит 300 Кбайт, и это только JS. Таким макаром, у нас запросто получится страница, которая весит 5-10 Мбайт.
Представим себе страницу, на которой сверху блок рекламы, справа блок рекламы, слева блок рекламы, и снизу еще целая лента рекламы. Даже если, из собственного контента, страница содержит один div в котором написано «Hello World!», весить все это будет десятки мегабайт. Извините, но с современной моделью монетизации сайтов мы не сможем сделать страницы «тоньше». Десяток мегабайт кода тут ничего не решает. Код, хотя бы, полезную для пользователя функцию выполняет, в отличие от всевозможных баннеров. Если конечно это код, относящийся к работе сайта. Куча загружаемого кода это всякие жучки, маячки и прочее шпионское барахло. И пока вся эта мерзость пожирает ресурсы пользовательского компьютера, разработчику основного функционала советуют затянуть пояс потуже, отказаться от используемых им библиотек, компонентов, и т.д. А то, видите ли, сайты тормозят. Не поможет это. Просто реклама станет еще жирнее, а жучков станет еще больше. А у пользователя все, по прежнему, будет лагать.
И тормозил там, скорее всего, сервер.
Нам рисуют пользователя, как какого-то максималиста, помешанного на удобстве интерфейсов. Малейший притормоз, он тут же закрывает вкладку и стирает историю, чтобы забыть дорогу на ваш сайт. Это чушь. Просто маркетологический бред. Человек заходит на сайт не ради интерфейса. Он заходит туда ради контента.
Так вот практика показывает, что «ради контента» — это тоже мантра максималиста.
Ну доклад то о оптимизации работы с DOM и это, как я понимаю, задает некий общий контекст — такая вот разница. Просто используя любой из перечисленных в докладе фреймворков, заставить фронтэнд магазина тормозить — это еще постараться нужно. Да и если яндекс-маркет покажет, что цена в тормозящем магазине ниже чем в остальных — никуда люди не денутся, дождутся загрузки. Именно ради контента.
Вы экстраполируете свой частный случай на общее пользовательское поведение. Конечно скорость работы важна, но контент важнее, просто потому, что сайт — это средство, контент — это цель.
У продажников сайт — это канал, цель покупателя — товар, и если он (покупатель) может его (товар) получить по другому, более удобному каналу (сайту) то он (покупатель) уйдет (а удобство это не только скорость). Тут еще играет роль лояльность покупателя к каналу (сайту, бренду) и его осведомленность о наличии у него выбора и готовность этим выбором воспользоваться (если ему нужен телефон, он может пойти к другому продавцу, если же он повелся на действующую акцию в конкретно этом магазине и его что то не устроило — он может просто уйти в никуда, то есть отменить свое решение о покупке).
Эту ситуацию можно ограниченно экстраполировать и на контентные сайты.
В общем не так все однозначно — медленный сайт — уйдет, нужный контент — останется. Там все же немного больше факторов влияет.
У меня есть бонусная карта одной федеральной сетки. Которая, что бы повысить мою лояльность, отсыпала мне бонусов за предыдущую покупку. Которыми я могу оплатить 100% стоимости товара. И тут мне срочно понадобился телефон (наушники, унитаз, неважно) Я могу оплатить бонусами, не тратя реальных денег. Но сайт тормозит. Вы действительно думаете что я не подожду? Товар не уникален, но уникальны условия сделки.
Ок, нет бонусов, или есть но мало. Но купив в этом магазине — я добавлю бонусов себе на карту, а купив в другом — не добавлю. Или добавлю на другую. А я хочу на эту, потому что на этой уже что то есть.
Я пять лет проработал в такой сети магазинов, поверьте, программы повышения лояльности клиента разрабатывают не самые глупые люди. Именно для того что бы оформить неуникальный товар в уникальную (для потенциального клиента) сделку. По любому каналу, оффлан/онлайн.
[offtop]
Я уже около 20 лет смотрю на множество программ лояльности разных магазинов. Многими пользовался (когда-то). Вывод таков, что всё это шелуха в >90% случаев. Что бы там ни пела реклама, все эти накопления баллов имеют смысл только если я уже и так являюсь постоянным клиентом магазина. То есть это некоторый дополнительный плюс, но он не должен играть никакой роли при первоначальном знакомстве с магазином (в отличие от скидок живыми деньгами здесь и сейчас). Нельзя что-то покупать именно ради получения бонусов. Они не так велики и имеют свойство сгорать и сдыхать — и заранее этого никто, естественно, не расскажет. Просто в какой-то момент изменятся условия. Плавали, знаем, и неоднократно.
Руководствуюсь правилом: при первой покупке бонусы и карты меня не интересуют вообще. Меня интересует ассортимент, цены, удобство, условия доставки и пр. Вот если вдруг перейду в разряд постоянных клиентов — тогда и посмотрим на бонусы. Но вот беда, тормозящий сайт (как одна из причин, не обязательно единственная!) может побудить меня сделать попытку в другом месте.
Вот, кстати, еще один пример из жизни. Есть один магазин одежды, в котором я несколько лет постоянный клиент. Всё было нормально, но недавно они сменили дизайн и движок. Сайт стал о-очень тормозным и неудобным. А что я? Я пока что еще не ушел от них, потому что изучил их размерную сетку и уже знаю их товар. Развод не происходит в одночасье. Но я уже крепко задумался об альтернативах (благо, их очень много). И как только мне подвернется что-то, что меня зацепит/понравится — я тут же помашу им ручкой.
Я не понимаю, что вы мне пытаетесь доказать?
В общем не так все однозначно — медленный сайт — уйдет, нужный контент — останется. Там все же немного больше факторов влияет.
Только если контент уникален.
В общем общение постепенно заходит в тупик, я то ничего доказать не пытаюсь, было ощущение что мы просто обмениваемся мнениями.
Человек заходит на сайт не ради интерфейса. Он заходит туда ради контента. Если мне на сайте что-то нужно, то я буду им пользоваться. Чтобы уйти, мне нужен, если не полный аналог, то хотя бы приемлемая альтернатива тому контенту, тем услугам, что сайт мне предоставлял.
Согласен с вами. В Украине самый популярный интернет магазин(розетка) работает не понятно как, жесткие лаги, долгое время загрузки. После каждого нажатия на чекбокс в фильтре интерфейс тебе отвечает полной перезагрузкой страници. Мобильная версия тоже ужасная. Тем не мение магазин все еще один из самых популярных.
А уже потом «шаблонизатор» и VirtualDOM
И да, есть Preact, React-lite и т.д.
из facebook всё таки
Мы постепенно учимся и наши редакторы будут выпускать всё более заточенные под Хабр расшифровки. Уже понятно, какие должны быть статьи, чтобы их было удобно читать, осталось ещё поработать над интересом.
Надеюсь, что со временем мы сможем быть вам полезны.
Что вы такого с ним делаете? :)
А всякие AngularJS и ReactJS, якобы борясь с DOM тормозами, сами тормозят еще больше :)
Вся эта возня — псевдопрограммирование, когда вместо решения текущей задачи занимаются решением большего количества проблем от ее псевдорешения.
Но да, можно бить себя в грудь, считая профи :)
>реальной работы с DOM не будет, мы получим уже подготовленный и срендеренный шаблон. Т.е. получим шаблон для вставки в DOM мгновенно.
А чем это отличается от обычного ajax-запроса с помощью jquery? :)
Видео не смотрел, как-то вот не расположило прочитанное.
Не нужно.
Однако скриншот бенчмарка с jsperf наглядно показываетПохоже что jsperf мертв уже несколько месяцев, нет возможности погонять тесты.
… он раз в 5 быстрее, чем Angular обычно. Итак, что же мы тут видим? Первоначальная инициализация в Темпле делается на процентов 30 быстрееПоэтому я «на коленке» сделал простой тест на plunker, у меня в хроме и фф Temple показывает показатели не лучше чем в Angular Light, они оба выдают 600-700мс. Возможно temple не такой быстрый если сравнить его с новенькими фреймворками (Angular 2, Aurelia ...), ссылка на тест.
А вообще, как написали выше, если вы сравниваете шаблонизатор с фреймворком (с Ангуляром), то лучше сделать ToDoMVC т.к. Ангуляр не (просто) шаблонизатор.
Кстати, в какой-то момент сломался этот тест: https://eigenmethod.github.io/mol/perf/render/
Ругается на отсутствие scope.$scan.
Потому что там, где есть JS, это всегда тормоза, доставшие уже по самые некуда. Ещё -10% к времени визуализации даёт Ghostery и userContent.css с правилами вырезания графического мусора (т.е. рекламных блоков и прочей заразы, стремящейся в обход моей воли влезть в мой фокус внимания и отожрать моё мыслетопливо).
Лучший способ проверить производительность фронтэнда — погонять сайт на однопроцессорном компе с 2.4 GHz P4 процессором и старой DDR-памятью 500 MHz при других загруженных приложениях и веб-страницах на машине. И сравнить скорость визуализации веб-страниц с JS и без.
Как пользователь, я ненавижу JS за то, что на нём делают безумно тормозные вещи, жрущие по гигабайту и больше оперативки, и умеющие и делающие меньше, чем обычный документ в MS Word, спокойно живущий в 100-200 МБ. В том же GMail в стандартном веб-интерфейсе не видно, как перемещается курсор, если зажать влево или вправо. Переходим в html-вид, и вуаля, оказывается, редактор снова может работать как положено и курсор видно при перемещении.
Как разработчик и пользователь, я не понимаю, нахрена на странице, показывающей статический текст, лепить какой-либо JS-фреймворк. И не пониманию, зачем пользователю с 24" экраном иметь дело с веб-сайтом, заточенным исключительно под смартфон. Зачем все эти горизонтальные блоки, в каждом из которых по 1-2 предложения и нужно листать эти блоки, чтобы всосать инфу со страницы, вместо одного быстрого взгляда на 1 абзац текста.
Чтобы сделать -5% к времени визуализации веб-страницы, как пользователь, я давно отрубил разрешение на загрузку шрифтов и использование сайтами своих шрифтов. Если что-то из-за этого не показывается — это недоработка веб-дизайнеров и прочих «авторов» веб-сайта. Потому что пока ни один дизайнер не угадал с нужным мне размером и начертанием шрифта. Хотя ничего сверхсложного мне не нужно: основной текст должен быть шрифтом с чётким начертанием типа Verdana и линии в буквах в 1 пиксел толщиной с физической высотой буквы м 2 мм.
И да, я не понимаю веб-сайты, занимающие по ширине лишь треть экрана 24" с разрешением 1920x1200, но при этом буквы столь гигантского размера, что умещается всего 3-5 слов в строке. А смотреть, как блоки начинают наплывать друг на друга, когда с помощью NoSquint выставил наиболее приемлемые масштаб и размер шрифта — прямо-таки «удовольствие».
И да, я всё ещё холю и лелею надежду, что веб-разработчики, наконец, перестанут совать JS-фреймоворки во все щели, и снова станут делать быстрый фронтэнд, каким он был на компьютере с означенной выше производительностью в 2004-2007 годах.
линии в буквах в 1 пиксел толщиной с с физической высотой буквы м 2 мм.
Такого никто в здравом смысле не сделает. Я вот за последний час читал Хабр на трёх экранах:
- 6" телефон (476 ppi) с сантиметров 30
- 15.6" ноутбук (141 ppi) с сантиметров 50
- 27" монитор (163 ppi) с сантиметров 80
И вы хотите, чтобы линии в буквах были разной толщины физически (размер пикселя разный), а высоты визуально (расстояние до экрана разное)? Я вообще не уверен, что разгляжу линию на телефоне и букву на мониторе.
раньше за это «минусили»
Быстрый рендеринг с DOM шаблонизаторами