Выпуск 22: В гостях Василика Климова

Долгожданный выпуск. Побили рекорд по времени подкаста. Пообщались с Василикой про ее работу и опыт выступления на MoscowJS, опыт в политике и его связь с веб-разработкой, зарплаты российских разработчиков и возможность переезда за границу. Обсудили интересные доклады с последних конференций JSConf в Будапеште и FrontendConf в Москве. Было много холиваров на тему Twitter’а, английского языка, методологий разработки и многого другого. Разумеется, не прошли мимо последних громких новостей – объединения io.js и Node.js и возможного объединения Underscore.js и lodash. По традиции рассказали много пиков, которые обязательно вас заинтересуют. Все как вы любите!

Скачать выпуск (mp3, 50 MB)
  • Dmitry

    Не понимаю, что за шумиха вокруг bower и npm.
    Bower хорош для фронт либ, плагинов jquery допустим. А npm более нодовская вещь. И то и то активно используется сообществом. Поглядите на гитхабе.

  • Ivan Voischev

    Сделайте для каждого moscowjs запись докладов офлайн для тех кто хочет озвучить свой доклад на английском 🙂 будет очень круто!

    • Есть канал на YouTube. Легко можно добавить субтитры или скачать и сделать английскую дорожку.

  • scoped модули можно и бесплатно использовать. При паблише надо указать `–access public`. И получим `@user/module` (при условии, что name в package.json прописан такой же).

    Дока: https://docs.npmjs.com/cli/publish

  • Нужно фоном какую-нибудь музычку запускать. Будет веселее.

    • menix

      не надо музычку, мне во фронтфлипе их фон мешает.

    • я категорически против фоновой музыки, а вот заставку вероятно рано или поздно сделаем 🙂

      • Да что угодно сделайте, нужно чем-то паузы заполнять. А то выходит какая-то теотральная радиопостановка, где все замирают и ждут ответной реплики героя 🙂

        • есть технические подкасты, где это не так? ради интереса
          я вроде много слушаю и привык к этому, поэтому слушаю на 1.5x или 2x и не парюсь
          как бы темы то технические, не хочется быстро чушь молоть, нужно подумать, вспомнить иногда + задержки Skype

          • Мендяев Николай

            Вырезание тишины в аудасити есть – попробуйте. Ну вроде во всех вырезают спасибо товарищу умпутуну с его ТиПЗ.

          • Вообще я как-то зря игнорировал эту технику. Надо будет сделать в ближайшем выпуске и посмотреть, как оно порежется автоматом. Спасибо.

  • Konstantin

    Ребята на http://conf.rollingscopes.com/. Делали живой перевод с русского на английский для зарубежных ребят. Что бы им не было скучно.

    • Такой вариант тоже возможен и вполне подойдет для начала.

  • Nick Zhivotvorev

    Ура, Лика в radioJS) Вы его вчера на MoscowJS писали? )))

    • в туалете 🙂 там тишина и никто не мешал

  • bearded

    По описанию типичный Substack: http://www.youtube.com/playlist?list=PL818E3E69FFE55295
    Удивлён, что никто из ведущих не знаком с другими его докладами.

  • Ура, наконец-то новый выпуск!

    Давно не писал комментарии, но я не смог сдержаться )

    Не запоминать конкретную “карточку” или что-то еще – это не бред. В этом случае не нужно хранить оригинальные данные. Достаточно сделать хеш (засолить/пересолить) и хранить его, и сравнивать хеш от новых данных с известными. Вот и вся “магия”.

    По поводу доклада Антона Виноградова. Они опираются на БЭ, и было утверждение, что это лучший вариант для идеи. Хотя утверждение спорное. А насчет React было обратное, что вероятно можно, но сложно. Основной поинт, почему БЭМ – потому что там все описывается не деклативно, и можно получить на выход и html, и svg, и все что угодно. В случае с React мы как бы описываем конечный html и не можем получить что-то другое. Хотя по факту это не совсем так. Да, описывается html, но он превращается в абстрактную структуру известную как Virtual DOM. По факту из нее можно получить не только DOM, но и все что угодно. По сути так обеспечивается изоморфность в React, в одном случае на выходе генерируются DOM ноды, в другом – строки. Но проблема не только в получении svg из html, но и переборе состояний. В случае с БЭМ вроде как есть известные модификаторы и можно перебрать (сгенерировать) состояния, да и сам деклативный подход к этому располагает. В случае с React разметка генерируется javascript’ом и предсказать возможные состояния без его исполнения невозможно, что крайне затрудняет перебор состояний, если не делает его невозможным. Но это проблема не только React, а любой шаблонизации, которая связана с использованием javascript или любого императивного языка для получения конечной разметки.

    Еще меня удивила реакция на доклад Бориса Каплуновского про их DOM шаблонизатор. Когда я рассказывал про эти подходы года два назад, реакция была спокойной. Сейчас же вызывает восторг. Видимо популяризация DOM шаблонизации тем же самым React’ом и остальными сделало свое дело и люди стали проявлять к ней больше интереса 🙂

    Тем не менее, после вашей дискуссии появилось сильное желание сделать доклад – “Никто не знает про DOM-шаблонизацию”. Потому что многие тезисы являются заблуждением. Давайте по порядку.

    Производительность: быстрее React в 3 раза. Тут конечно, за что купили – за то продали. Но тем не менее. Начнем с того, что большинству опытных разработчиков очевидно, что micro benchmark’и – это конь в вакууме. И когда сравнивается одно с другим нужно учесть, что код выполняется в неестественной среде, и в боевом окружении будет немного иная картина. И так же все зависит от браузера. Но в любом случае, сравнивая важно сравнивать одинаковую функциональность, что в тестах Бориса не совсем так. В его докладе три теста сравнения: создание DOM фрагмента, обновление с полным изменением всего и обновление без изменений.

    Создание. Если говорить про Temple, то он лишь создает DOM фрагмент и возвращает интерфейс к нему. Это все, что он делает. Например с событиями он не работает, это уже делается вне шаблонизатора и затраты на эту работу не попадают в тест. Наверняка делается еще что-то, что так же в тест не попадает. Так же в нем нет поддержки старых браузеров, и разруливания работы с ними. Но в React, например, делается все необходимое, в том числе для работы с событиями, и после этого никаких манипуляций больше не требуется. Тем не менее, в Chrome и Firefox разница между Temple и React не такая радикальная, меньше 1.5 раза. А вот в Safari – да, те самые 3 раза. Я еще добавил в тест basis.js. Он работает схожим образом с Temple, но делает все необходимое. В Chrome они на равне, в Firefox basis.js немного быстрее, в Safari basis.js проигрывает Temple в 2 раза. В целом можно заключить, что в Safari cloneNode медленнее чем createElement/createTextNode (что странно), в остальных браузерах наоборот (как и должно быть). Тест: http://jsperf.com/init-temple-vs-react/3

    Обновление с полным обновлением значений. На этой задаче React явный аутсайдер, это его ахилесова пята. Превзойти его не сложно. Так как, на каждую смену состояния вызывается метод render, который сначала генерирует новый фрагмент Virtual DOM, затем этот фрагмент сравнивается с уже известным и только после этого вносятся изменения в DOM (если нужно). Да можно использовать хаки и оптимизировать сравнением, но это не сильно поможет и явно “не спортивно”. В Temple изменения сразу прокидываются в DOM, так как для каждого значения уже сгенерирован код, который описывает что должно быть изменено в DOM фрагменте. Как результат – Temple выигрывает значительно (от 10 до 100 раз в зависимости от браузера). basis.js делает практически тоже самое, только в нем есть дополнительная логика, например обработка значений (если значение особо типа, “шаблон” может сам подписаться на его изменение), что дает оверхед и в результате проигрывает Temple в Chrome и Safari (в 2-3 раза). Но, как ни странно, немного выигрывает в Firefox. Тест: http://jsperf.com/hard-update-temple-vs-react/2

    Обновление без изменения значений. У React те же проблемы, поэтому его результаты предсказуемы. В Temple не хнанится информация об уже записанных значениях в DOM. Поэтому когда приходит значение, даже которое уже есть в DOM, то это приводит к тем же действиям что и при установке нового значения. Браузеры по большей части не делают оптимизаций, когда в DOM вносится значение, которое в нем уже есть (например, если в атрибуте указано значение “foo” и мы пишем в атрибут это же значение, это равносильно присвоению нового значения со всеми вытекающими). Поэтому затраты те же, что и при полном изменении данных. basis.js хранит значения, которые записывает в DOM, а когда приходит новое значение делается сравнение с тем, что было записано ранее. Если значения совпадают, то действий над DOM не происходит (вообще не трогается DOM). Как результат в этом тесте basis.js абсолютный лидер во всех браузерах (обгоняет Temple в 2-20 раз). Тест: http://jsperf.com/soft-update-temple-vs-react/2

    В реальных приложениях данные постоянно обновляются с сервера. На чаще всего они меняются неначительно, либо не меняются вовсе. Тут стоит заметить, что, например, в basis.js в случае если данные не изменились, то до шаблона дело даже не дойдет – понимание что не нужно ничего менять появится намного раньше, еще на уровне данных.

    “Temple быстрее React из-за малой глубины вызовов”. Очевидно, что дело не в глубине вызовов (размере стека), а просто React делает гораздо больше работы. В частности необходимо создать Virtual DOM (больше действий, дополнительная память etc) и делать сравнение (обход, сравнение, замена etc). И только после этого делать или не делать операции над DOM. В Temple нет Virtual DOM, в нем поэлементно создается фрагмент (для каждого экземпляра шаблона, это важный нюанс), и возвращается карта методов, которые точечно меняют необходимые узлы. Никакого Virtual DOM, сравнения, поиска, определения дельты – это делает его быстрее. Шаблонизатор basis.js делает все тоже самое, только в нем еще есть дополнительная логика и информация. И проигрывает он Temple скорей из-за этого, чем из-за большей вложенности. И еще один важный нюанс, basis.js создает поэлементно только эталонный DOM фрагмент, а дальше он клонируется (cloneNode(true)) при создании экземпляра шаблона – это позволяет нивелировать оверхед дополнительной логики и не сильно отставать на создании от Temple (а в некоторых браузерах даже выигрывать).

    “Temple генерирует Virtual DOM…”. Как я писал выше, Temple не имеет Virtual DOM и в нем нет такого понятия как render (как и в basis.js). Соответственно нет необходимости в сравнениях и какого либо сложного рантайма (он вообще не нужен). Если говорить про Glimmer (Ember.js), то там ситуация немного сложнее. Да, они ввели понятие Virtual DOM, как некоторый stage, из которого потом можно получать и DOM, и html (в виде строки). Но механизм его несколько иной, там нет сравнений как в React. И для определения изменений используется другая модель (шаблоны описываются деклативно, без js), которая базируется на концепциях самого Ember (computed properties и пр.). Хотя в случае с Glimmer могу ошибаться, так как еще не до конца разобрался в механизме его работы (он только вот недавно стал стабильным). Но про Glimmer по большей части говорили верно.

    “В Angular могли бы применить такой подход…”. Кажется это архитектурно невозможно. В разметке используется вкропления кода, а так же директивы (по сути внешний код), которые делают непредсказуемой финальную разметку. То есть без исполнения всего “навешанного” кода мы не знаем, что получится и не можем это как то оптимизировать. Так же проблема Angular, что он постоянно взаимодействует с DOM напрямую (даже “инструкции” берет из него), а это большой оверхед. Virtual DOM тут вряд ли поможет, так как многое завязано на особенности DOM, но кажется это возможно. Но в таком случае получится более дорогой аналог React, с теми же проблемами.

    Еще хочу заметить, что DOM шаблонизация – это не только производительность. Про это у меня уже было несколько докладов (http://www.slideshare.net/basisjs/), но пока меня не слышат 🙂 Это непаханное поле для адаптивных представлений (когда разметка подстраивается под данные и форм-фактор динамически), оптимизаций как итогового результата (сборки), так и самого процесса разработки и много чего другого. Для сложных приложений нужны инструменты, а практически все текущие шаблонизаторы ничего на этот счет не предоставляют. У React и Ember есть плагины для Chrome, которые предоставляют некоторую информацию, но этого явно недостаточно. У basis.js есть инструменты, которые позволяют получать практически полную информацию о шаблоне, понимать откуда что пришло и почему это выглядит так как выглядит, с быстрым переходом к исходнику и т.д. и мы активно развиваем это направление. Еще есть наследование шаблонов, изоляция стилей, live update (обновление шаблона без перезагрузки страницы), локализация, темы, анализ и т.д. Сейчас работаем над тестированием. Чтобы все это уметь, шаблонизатор должен быть устроен определенным образом. И некоторые моменты безусловно его замедляют, но не так радикально, если сравнивать с плюсами.

    У Temple нет ничего кроме создания DOM фрагмента и расстановки значений в него – это крайне мало. Работает только с DOM, потому с изоморфностью сложнее. Основная фишка – он предельно прост и потому для определенных задач вполне может подойти (например, для мобильных приложений самое то, наверное). Но он явно не серебренная пуля.

    • Воу!) у Ромы накопилось!)

    • очень круто, что не поленился так подробно все пояснить и бенчмарки дописать, спасибо!

    • Кстати вот еще один еще один проект заявляющий, что быстрее React http://jsblocks.com/

      У него не так много тестов, но наконец-то добрались руки их посмотреть. Авторы предлагают для сравнения два теста на “большой” таблице (500 строк 12 колонок). Первый замеряет создание и заполнение таблицы, а второй 10 полных обновлений этой таблицы. Сравниваются сам jsblocks, а так же React и Angular. Я по обычаю добавил Basis 🙂

      Вот какие у меня цифры получились:

      === initial load
      angular – 980ms
      react – 460ms
      jsblocks – 360ms
      basis – 35ms

      === syncing changes
      angular – 3700ms
      react – 1500ms
      jsblocks – 1000ms
      basis – 120ms

      Тут стоит заметить, что второй тест для Angular составлен не правильно, в нем не используется setTimeout как для других. С использованием setTimeout результат получается ~5000ms. Но с “оптимизацией” (если добавить track by $index, по следам вот этой статьи http://blog.500tech.com/is-reactjs-fast/), то результат лучше чем у jsblocks – 900ms 🙂

      • У нас в проекте везде track by model.id, что не только быстро, но и надежно.

        Проблема бенчмарков в том, что автор свой код оптимизирует по максимуму, а код на чужой библиотеке использует влоб… Надо какие-то соревнования что ли проводить, где авторы фреймворков будут сами писать бенчмарки под заданные кейсы.

        За счет чего basis на порядок быстрее?

        • Тут сложно возразить. Часто авторы тестов выбирают удобный для себя кейс, на котором их “велосипед” выглядит особо эффектно. По этой причине я стараюсь не делать собственных тестов, а примыкаю к чужим, проверяя свой фреймворк в тех условиях, которые предлагает автор(ы) теста. Обычно basis выигрывает. Иногда нет – это хороший повод залезть в профайлер, разобраться в причинах, попробовать найти решение (возможно не сразу). Так делаются быстрые по быстродействию решения – постоянный профайлинг, соревновательный момент, изучение лучших решений, их применение, оптимизации, эвристики, etc.
          Это частично ответ на твой вопрос – почему на порядок быстрее. Еще часть ответа в моем первом комментарии. Но полноценный ответ превратится в очередной комментарий-статью 🙂
          Но если кратко, тот же basis не пытается быть супер умным и за тебя решать все проблемы. Универсальные решения всегда плохи тем, что работают хорошо лишь в усредненных (и обычно простых) случаях. Так работают, например, React и Angular. Но разработчик обычно знает чего хочет, какого рода данные и что нужно получить. Но его расслабляют “умные” фреймворки.
          Basis – это тупой “робот”, который отстраняет разработчика только от совсем уж “простой” работы. Основную работу делает разработчик сам – объясняет что он хочет. И чем детальнее он это сделает, тем будет быстрее. А лучший результат будет в том случае, когда разработчик понимает как это все работает под капотом. Потому basis немного сложнее, чем популярные фреймворки – он заставляет постоянно думать. Это можно считать минусом, и в то же время плюсом. Если “думать”, то получаются более удачные решения, и, как результат, более производительные.
          Секрет очень простой: “ложки – не существует… не ложка гнется, все обман, дело в тебе…”. Стоит быть ближе к базовым технологиям, и тогда открывается мир богатых возможностей без ширмы в виде препроцессоров, транспилеров, фреймворков etc. Понимая возможности и особенности (плюсы и минусы, сильные и слабые стороны) базовых веб-технологий можно сделать что угодно гораздо более производительнее, чем то же изображая в терминах практически любого (“модного”) фреймворка.

  • Bill Bool

    Дайте ссылку на тот видео доклад.

  • Алексей Муров

    Быть не может новый выпуск

  • Dmitry

    Ребят, вам надо более тематически вести диалоги, разбить подкаст на стандартизированные порции, секции с соответствующими хедером, ибо так всего почучуть жопой с одной лужи в другую. И быть поживей, ато как спермотозоиды во льду, слишком много аааа, ууу буууу. Веселей, громче! Музыкальные переходы добавьте, а то водой хоть в уши брызгай

    • Мы работаем над этим. Это не так просто, как может показаться.

  • Ivan Strelkov

    По поводу нестабильных тестов на Ruby: их можно и на JS писать. Когда я разбирался в причине нестабильности тестов на WebDriver, в 99% случаев она заключалась в отсутствии ожидания какого-либо из элементов. Это относится к любому языку, не только Ruby.

    • waitFor тут не при чем. Речь идет о headless WebKit-браузере PhantomJS, драйвер к которому или сам браузер (что вероятнее) глючат. Кстати, возможно скоро пригласим одного из core-разработчиков PhantomJS в гости, чтобы дать возможность объяснить, в чем проблема, защищить продукт.

      • Ivan Strelkov

        Возможно, что и ни при чем. Но, судя по тому, что Василика упомянула задержки и sleep как костыль, дефект в тестах именно такого рода.

        Если дело в PhantomJS – его можно заменить реальным браузером и Capybara здесь ни при чем.

        Как бы там ни было, в подкасте прозвучал призыв писать тесты на JS и аргументом со стороны Василики, как мне показалось, было то, что тесты на Ruby работают нестабильно.

        Мысль, которую я пытался донести – язык не влияет на стабильность.

  • menix

    мужики, я методично переслушал все выпуски и вынужден сказать, что это был один из худших. сколько человек вас уже слушает, интересно? понятно, что аудио слушается в дороге, без особой концентрации, но из первых 38 минут я узнал интересного только то, что бывают фронтендеры-коммунисты. про конференции тоже слабо, потом уже пошло более по теме.
    не переживайте, правда, в девзене все намного хуже – ведущие спихивают друг на друга обсуждение топиков в прямом эфире и обсуждают статьи, которые не читал ни один из них.
    спасибо вам, каждый раз слушаю вас с пользой!

    • Ровно держаться не всегда получается, бывают выпуски затянутые, бывают не очень подготовленные. Возможно не того все ждали полтора месяца, но дальше будет лучше, это я вам обещаю.

  • LeusMaximus

    По поводу темы “как уследить за новостями”, вот есть интересные ресурс
    http://uptodate.frontendrescue.org/