Привет! На этой неделе с вами я, @vslinko. Давайте знакомиться.

Моя история началась 13 лет назад. Мне показалось скучным в очередной раз переустанавливать винду на своем домашнем компьютере.

Один школьный друг поделился со мой волшебным CD, на котором был какой-то дистробутив линукса. Это изменило всю мою жизнь.

Около полугода я пытался настроить интернет от моего провайдера, который работал через PPTP. В итоге я познал скрипты на bash.

Я выложил этот скрипт на локальный форум, где собрал много разного фидбека. Это был мой первый опыт вклада в Open Source :-)

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

Если бы не шальная мысль в подростковой голове, я бы не занимался последние 10 лет веб разработкой.

Несколько лет назад я переключил свое внимание с бекенда и девопса, на фронтенд и работу с командой.

Сейчас я руковожу группой front-end разработки в компании ЦИАН, где передо мной стоят несколько больших задач.

Кроме того, в прошлом году у меня был первый опыт публичных выступлений на IT конференциях и мне это очень понравилось.

Три моих доклада были про две технологии от компании Facebook (нет, не React), с которых я и начну неделю.

На презентации GraphQL я подумал: "я же пытаюсь сделать тоже самое". Единый endpoint, который одним ответом отдает только нужные данные.

Вокруг этого же можно сделать декларативный API доступа к данным, который не будет тормозить, как, например, REST. И тут они показали Relay.

Все это выглядит очень красиво, рекомендую посмотреть youtube.com/watch?v=UBGzsb… и попробовать graphql-swapi.parseapp.com

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

После появились проекты, для которых G&R хорошо подходили: куча сущностей, переписать с нуля, гарантировать простоту поддержки долгий срок.

Как и любые технологии, решая одни проблемы они создают новые: высокий порог входа, много boilerplate, различные ограничения (нет подписок).

Есть легковесная альтернатива для Relay под названием Apollo. dev-home.apollodata.com

Жертвуя некоторыми оптимизациями мы получаем библиотеку с простым API.
Настораживает только то, что Apollo разрабатывает команда Meteor.

Уже начала появляться инфраструктура вокруг.
Сначала появился GraphQL as a Service reindex.io

Недавно Apollo начали рекламировать инструменты для аналитики: популярность полей, время ответа запроса/поля apollostack.com/optics

Github открыл свой API через GraphQL developer.github.com/early-access/g…

Скоро будет первая конференция по GraphQL graphqlsummit.com

Кстати, ближайшие 3 дня будет 54я встреча комитета TC39.
@chicoxyzzy обещал постить интересности
github.com/tc39/agendas/b…

Не будет лишним разбавить хайповый тред докладом @listochkin о том, как не гнаться за хайпом youtube.com/watch?v=xPFRUM…

Закончился рабочий день. Самое время продолжить разговор о GraphQL/Relay/Apollo.

Пожалуй самые популярные вопросы по этой теме — кому и нафига это нужно? Поделюсь ссылками на видео, так будет эффективнее.

Вот это видео может помочь вам понять, что делает GraphQL youtube.com/watch?v=Wq02BN…

А это видео может помочь вам понять, что делает Relay youtube.com/watch?v=oPSuva…

Про Apollo я нашел только такое видео youtube.com/watch?v=u1E0Cb…

Например Glimmer 2 движется в сторону увеличения знания о шаблоне. О нем мы поговорим в одном из следующих дней.

Немного по планах на следующие дни: Typescript/Flow, React/Angular2/Glimmer2, SSR, моя работа в ЦИАН, UX, саморазвитие и планирование

Забыл упомянуть об отличной алтернативе от Netflix — Falcor. Жаль только, что о нем перестало быть слышно youtube.com/watch?v=z8UgDZ…

Всем привет! Сегодня я хочу высказать свое мнение о таких языках, как TypeScript и Flow. youtube.com/watch?v=9PTa9-…

Я специально хочу сделать акцент на том, что Flow это такой же отдельный язык программирования, как и TypeScript.

Цель существования данных языков — добавление в динамически типизированный JavaScript немного статической типизации.

Я выделяю две задачи, которые решает статическая типизация — валидация корректности на уровне типов и увеличение дисциплины кодирования.

С точки зрения валидации корректности Flow, объективно, сильнее. Примеры можно посмотреть у @vkurchatkin github.com/vkurchatkin/ty…

Не смотря на это, я выбираю TypeScript по трем причинам: строгость, легкость и тайпинги.

Строгость. Во Flow можно получить данные о покрытии кода типами. В TypeScript можно обязать писать типы и запретить использовать тип any.

Легкость. TypeScript чуть ближе к другим, уже популярным, языкам; у него лучше документация, и он написан не на OCaml.

Тайпинги. В TypeScript есть развитая инфраструктура описания типов для популярных пакетов из npm. Не нужно тратить свое драгоценное время.

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

Flow или TypeScript? Команда, которая имеет большой опыт работы с типами, зависимость от babel, знание OCaml — Flow. Иначе — TypeScript.

Важно! Статическая типизация не заменяет тестирование и наоборот. Тесты для бизнес-логики, типы для согласованности интерфейсов.

.@jsunderhood можно добавить, что в Flow гораздо сильнее type inference и поэтому требуется гораздо меньше аннотаций

В любом случае сделать PR с обновлением зачастую проще, чем написать тайпинги с нуля.

@jsunderhood Flow изначально не поддерживал Windows, но они добавили поддержку месяц назад

“RegExp Unicode Property Escapes” перешли на stage 2. github.com/tc39/proposals…

Об этом был отличный доклад на @frontend_union. Очень советую посмотреть после того, как его опубликуют.

Напоминаю, что сейчас идет встреча комитета TC39, который занимается развитием ECMAScript. github.com/tc39/agendas/b…

@jsunderhood изменения тут github.com/tc39/proposal-…
чеклист тут github.com/tc39/proposal-…

Всем привет! Не смог, к сожалению, сегодня уделить ни минуты рабочего времени вам. Сейчас исправим.

Сегодня я хочу поговорить о React, Angular 2 и Glimmer 2. Даже не о них, а о подходах к работе с мутациями DOM.

Есть две парадигмы работы с изменениями: императивный (описываем алгоритм) и декларативный (описываем результат, к которому нужно прийти).

Императивный подход эффективен, но сложность поддержки алгоритма растет нелинейно по мере роста бизнес логики.

Декларативный подход гораздо удобнее, но в наивной имплементации он совсем не эффективный.

Это было одной из selling point React. Вы описываете компоненты декларативно, React генерирует VirtualDOM и супер эффективно его применяет.

На самом деле проблемы все еще остаются. Сравнение двух деревьев очень затратная операция.

Одно из решений — shouldComponentUpdate. Костыль для исключения некоторых веток дерева из сравнения.

Этот костыль можно свести к унифицированной функции сравнения, используя immutable data, например ImmutableJS.

Проблема в ImmutableJS в том, что при изменении одного значения меняется хеш у всех родителей, что инициирует рендер с самого корня.

Второй рецепт — инициировать изменение как можно ниже в дереве компонент, но на это должна быть заточена архитектура приложения.

Почему костыли? Смешивание бизнес логики и хуков для оптимизации в одном юните ухудшает поддерживаемость.

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

К сожалению, я не успел посмотреть на то, как эта проблема решается в Angular 2, удалось найти только статью blog.thoughtram.io/angular/2016/0…

Судя по этой статье, все очень похоже на React. Интересно как в Angular 2 применяются обновления в рамках одного компонента.

Соответственно компонент который владеет массивом пойдет вызывать ренден у всех дочерних.

Про обновление компонент. Даже если обновляется один компонент, React должен получить новое дерево, сравнить со старым и обновить DOM.

Кажется, что оптимизировать этот момент можно сопоставив изменяемое значение с конкретной операцией над DOM.

Достичь этого можно глубже понимая свои шаблоны. Мы знаем, что у нас есть переменная "name" и что она выводится как текст у DOM ноды.

Имея это знание, можно составить список необходимых операций над DOM без сравнения двух деревьев.

Одни из тех, кто копает в эту сторону, это команда Ember в рамках проекта Glimmer 2. github.com/tildeio/glimmer

Обязательно посмотрите это видео про Glimmer 2! youtube.com/watch?v=vL8sCi…

Попробую кратко. Шаблон компилируется в промежуточное представление, "wire-format", который разбит на блоки (root, if, each, etc).

Каждый из блоков состоит из инструкций (открыт тег, задан аттрибут, закрыт тег, etc). Каждый из блоков знает о используемых переменных.

Из этого представления генерируются две подпрограммы. Первая для первоначальной отрисовки. Вторая для эффективного применения обновлений.

Подпрограммы представляют из себя дерево операций (опкодов), каждая операция привязана к части DOM дерева и к части дерева данных.

Дальше запускается виртуальная машина, которая эти опкоды выполняет. Переменная изменилась — меняем текст; нет — завершаем выполнение.

Есть интересный проект MobX.
Следим за изменением только того, что используются. Ре-рендерим только тех, кто подписан на изменения.

Ссылка не влезла mobxjs.github.io/mobx/

Он решает проблемы shouldComponentUpdate и ImmutableJS, которые я озвучил ранее, но не решает проблему обновления одного компонента.

Итересный экскурс в историю React до публичного релиза. facebook.github.io/react/blog/201…

@jsunderhood как и ванговал. стейдж 3
github.com/tc39/proposals…

@jsunderhood нужны, но очень ограничено, потому что явная асинхронность почти никогда не нужна, а когда нужна, от нее надо быстро избавиться

@jsunderhood если есть асинхронные источники данных, которые выдают несколько значений - обзерваблы делают жизнь сильно проще.

@jsunderhood Мне не нравятся Observable как абстракция. Мне кажется они усложняют код.

@jsunderhood поэтому я буду рад, если observables останутся в userland. Загружать все остальное Symbol.observable тем более смысла мало.

@YodaPunk @jsunderhood есть еще github.com/basisjs/basisjs slideshare.net/basisjs/dom-27… @basisjs

И еще один все понял про шаблонизаторы. habrahabr.ru/company/oleg-b…

After good discussion we reached consensus to bring Rest/Spread Properties to Stage 3 at TC39! sebmarkbage.github.io/ecmascript-res…

Сегодня, к сожалению, не смогу уделить вам много времени. Накидывайте ссылки на интересные статьи, видео и темы, буду ретвитить.

@jsunderhood книга по ng2 angular-2-training-book.rangle.io

@jsunderhood дебажим ноду и клиент параллельно через chrome devtools blog.hospodarets.com/nodejs-debuggi…

Всем хороших выходных! Сегодня я хочу рассказать о том, чем я занимаюсь в компании ЦИАН.

Для тех, кто не знает, ЦИАН — это российский классифайд про недвижимость, который отмелил в этом году свое 15-летие.

Понятное дело, что продукт с такой историей имеет большое количество написаного кода и широкий набор разнообразных архитекрурных решений.

В том числе это касается и клиентской части. И одна из моих больших задач — привести frontend в порядок.

Для того, чтобы что-то сделать лучше, необходимо понять что на самом деле происходит.

Один из отличных источников знаний о том, что чувствуют пользователи — Navigation Timing API developer.mozilla.org/ru/docs/Web/AP… pic.twitter.com/mKh5fmzVyT

Мы собираем метрики самых популярных страниц Navigation Timing API, отправляем через бекенд их в StatsD и выводим графики в Grafana.

На основе этих данных можно разобрать из чего состоит время загрузки страницы. pic.twitter.com/j7z7bAOPqJ

И выявить разные аномалии. Например, некоторые страницы по ночам начинают работать медленнее, а некоторые, наоборот, быстрее. 😯

Следующее, что мы собираем, это активные версии ассетов. Таким образом можно понять, как быстро сбрасывается кеш у… twitter.com/i/web/status/7…

Вот так должен сбрасываться кеш при правильном подходе. 💪 pic.twitter.com/x7fkBMflCm

А правильный подход такой. Про Cache-Control: immutable можно почитать тут: bitsup.blogspot.ru/2016/05/cache-… pic.twitter.com/X0reZaVgUi

Еще с клиентов очень полезно собирать необработанные исключения. Для этого мы используем Sentry sentry.io

Вот классический пример из жизни проекта. pic.twitter.com/1xJTWAXldN

Проанализировав наши данные, архитектуру и требования мы определили список горящих проблем, сформировали цели (которых хватит на пару лет)…

…и выбрали основу для нашей архитектуры. В основе лежат три технологии: React, как инструмент для универсального рендеринга (нам важно SEO)…

…Node.js, который обеспечивает серверный рендеринг и добавляет асинхронности в систему; TypeScript для лучшего контроля за качеством кода.

Одна наших из целей — сделать общую библиотеку компонент. На эту тему есть великолепный доклад от @mr_mig_by youtube.com/watch?v=gfO2i9…

Мы движемся в этом же направлении. За основу взяли github.com/sapegin/react-… от @iamsapegin и заточили под TypeScript. pic.twitter.com/jKSww3YkXL

Кроме этого сейчас я прорабатываю концепцию "микросервисов" на фронте.
Разделяй и властвуй.

В сторону микросервисов на фронте активно копают @ZalandoTech с проектом mosaic9.org
По ссылке много крутых материалов по теме.

Долгое время я не понимал, чем занимаются UX спецы. Рекомендую youtube.com/watch?v=q4d376…
UX, MVP, Customer Journey, User Stories, Wireframing.

Внезапно, UX перешел для меня из разряда магии в набор простых техник, помогающих проанализировать то, что я делаю, как фронтендер.

Как вы, фронтендеры, получаете новые знания? У меня есть два источника: доклады/подкасты/твиттер и рабочие эксперименты.

Признаюсь. Книги (техническую литературу), я практически не читаю. Слишком крупный формат. Предпочитаю статьи и лекции в интернете. А вы?

Основные новости про фронтенд вне JavaScript я узнаю из подкаста Веб-стандартов. soundcloud.com/web-standards

Отличный подкаст про программирование от @filipovskii — @podcastcode codepodcast.com

Подкаст про JavaScript (давно не выходил) @RadioJSPodcast radiojs.ru от @filipovskii @bashmish и @KSDaemon

Мой любимый подкаст про технологии (не фронтенд) devzen.ru

Подкаст в стиле интервью с интересными людьми @SDCast_podcast sdcast.ksdaemon.ru от @KSDaemon

@jsunderhood, вот эти две в первую очередь читать: ozon.ru/context/detail… и ozon.ru/context/detail…

Сильно оффтопная тема за жизнь для выходного дня.

Хочу поделиться несколькими техниками, которые помогли мне осознать мои стремления, добавить немного смысла и проанализировать ситуацию.

Дисклеймер. Все что будет дальше не претендует на уникальность и на то, что поможет каждому. Это только мой опыт, которым я хочу поделиться.

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

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

После я составил список того, чем бы я больше всего гордился, если бы смог воплотить это в жизнь.

Эти упражнения позволяют вытащить наружу свои _настоящие_ стремления и приоритеты.

Так как все со временем меняется, в том числе и мировоззрение, я повторяю это упражнение раз в 6-12 месяцев.

По мере кристализации картинки в голове можно составлять список целей, которые позволят воплотить эту картинку в жизнь.

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

На самом деле это основы управления компаниями, примененные к личной жизни. Это позволило мне, заядлому пофигисту,… twitter.com/i/web/status/7…

Я смог определиться с карьерой, начал путешествовать и выступать на конференциях, сбросил 30 килограмм, закрыл долги и научился копить.

Кстати, о деньгах. Раньше я тратил все деньги, которые у меня были, и даже больше, не понимая, как так происходит.

Было несколько попыток начать вести бухгалтерию, но все их них проваливались, пока я не начал использовать простейшую таблицу в Excel.

Это позволило привить привычку записывать мои траты по категориям. Через несколько месяцев я смог проанализировать ситуацию.

Осознав, куда уходят деньги, я ввел бюджетирование, плавно перераспределяя деньги по категориям.

Оказалось очень просто отказать себе в спонтанной покупке, понимая откуда у тебя это желание и помня, что у тебя есть более важная цель.

Ledger — супер мощная консольная улилита для ведения бухгалтерии. Для гиков самое то! ledger-cli.org pic.twitter.com/ByELj8FDsg

Еще я хочу немного поныть о том, какие люди приходят на собеседования. Многие из них технически прокаченные ребята, но мотивации…

Большинству важны только технологический стек и заработная плата. Такие люди легко могут исчезнуть в самый неподходящий момент.

Многие говорят от том, что им нужна сильная команда и им хочется развиваться. Это отлично, но это не самое главное для разработчика.

И очень редкие персоны говорят о том, что задача разработки — решать проблемы бизнеса. И для этого необходимо понимать чем живет бизнес.

Это очень хорошие критерии, помимо технических навыков, для градации людей на junior, middle, senior.

Если вам важен результат вашей работы и вы понимаете зачем существует бизнес, то мы очень ждем вас у нас в команде. hh.ru/vacancy/179272…

@roman01la @jsunderhood и учиться нужно всем, даже опытным.

При этом можно легко удовлетворять свои потребности в развитии, зарплате и остальном.

@icelabaratory @jsunderhood у одного рабочего спросили - что ты делаешь? - "кладу кирпичи". А другой же ответил - "строю собор".

Для тех, кто только начинает выбирать я рекомендую попробовать как можно больше вариантов деятельности. Только так можно понять что ближе.