JS Fest. Роман Якобчук. React, взгляд в будущее

•

0 recomendaciones•660 vistas

Один из самых частых вопросов сегодня: "когда, наконец, умрет React?”. Гадание не мой конек, но мы можем делать предположения основанные на прошлом опыте. В фронтенде технологии обычно долго не живут, все меняется динамично и вчерашний “главный фреймворк” вполне может завтра оказаться на обочине. В этом докладе мы быстренько пройдемся по истории развития React, его современной экосистеме и философии, посмотрим как он распространился на другие платформы: RN, React VR и тд. На каждой из которых есть свои особенности, возможности и ограничения. Под конец мы будем достаточно хорошо видеть картину, чтобы спрогнозировать будущее этой технологии, и возможные новые индустрии для ее применения

Educación

React: взгляд в
будущее
Роман Якобчук, Frontend Guild Lead
linkedin/in/ya-roman github.com/romabelkar.iakobchuk@gmail.com

Hi.
Roman Yakobchuk
Lithuania
Ukraine
Vilnius
Kyiv
Dnipro
Wix Engineering Locations
Israel
Tel-Aviv
Be’er Sheva

1. Что это значит для компании?
2. Что это значит для тебя?

Мы не фреймворк, мы библиотека
Сами придумывайте свою архитектуру
Забудьте ООП, будущее за ФП
Какое тестирование?!

redux-loop
React + Redux
redux-thunk
redux-observable
redux-saga

React + ‘Reactive libraries’
Rx JS
MobX State Tree
MobX

React + ‘Data-driven libraries’
Relay
Apollo + Whatever
Apollo Falcor

Новая библиотека – новые подходы?
Relay
MobX Apollo
Falcor
redux-thunk
redux-saga
redux-observable

• New Core Architecture
• Portals
• Fragments
• Error handling
• Faster SSR
• Reduced bundle size

React is such a good idea that we will spend
the rest of the decade continuing to explore its
implications and applications
“
“
Guillermo Rauch, founder of ZEIT

Немного пофантазируем?
▪ React AR - WiP
▪ React Worker DOM
▪ Desktop Native Apps
▪ React PDF
▪ Hardware/IOT
▪ React Music?!

React 17
▪ Новый Context
▪ Async Reconciliation
▪ New Lifecycle methods
▪ Time Slicing
▪ Suspense

Высокоуровневые инструменты
▪ Expo
▪ Higher-level components in RN
▪ Create React App / CRNA
▪ MobX, Relay

Проблемы?
▪ Много бойлерплейта
▪ Много выбора
▪ SSR
▪ Code Splitting

Thank You
linkedin/in/ya-roman github.com/romabelkar.iakobchuk@gmail.com

Q&A
linkedin/in/ya-roman github.com/romabelkar.iakobchuk@gmail.com

Más contenido relacionado

La actualidad más candente

Что и почему писать на Erlang

Max Lapshin

Максим Лапшин — введение в Erlang

Александр Ежов

Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...

Ontico

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

Илья Аблеев – Zabbix в Badoo: реагируем быстро и качественно

Badoo Development

Сначала несколько слов про предпосылки задачи. 1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут. При первой же попытке параллелизации инстансов работать становится неудобно, нужна 2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище. Помогает собирать файлы логов с разных инстансов или сервисов. Минусы: * Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами. * Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога. * Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать. * Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов. 3. Ок, давайте сделаем все правильно: * для всех логов будет описан формат полей; * события вместо файлов будут храниться в горизонтально масштабируемой БД; * большинство агрегатов будет рассчитано заранее. Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем. Полезные фичи Elastic & Kibana: * мгновенное масштабирование от месяцев до долей секунд; * статистика распределения для каждого поля по любому диапазону и фильтру; * field templates; * significant terms filtering; * geohashing; Несколько кейсов, где Кибана выступает отлично: * Получение списка объектов/пользователей, на которых возникают проблемы; * Трекинг связанных проблем на разных сервисах; * Просмотр сессии конкретного пользователя; * Выявление аномальных пользователей (ботов); * Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей. Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо. * Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие. * LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов. Кратенько об альтернативах, плюсы-минусы: * realtime log readers: LogWatch * LaaS: Splunk Планирование требуемых ресурсов, (не-)линейность масштабирования.

ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)

Ontico

Вероятно, многие пробовали использовать решение Zabbix для мониторинга баз данных. Из моего доклада вы узнаете о нашем опыте его применения, и к чему мы в итоге пришли. 1. Штатный Zabbix-мониторинг баз данных: особенности реализации/настройки в промышленных масштабах 2. Преимущества/недостатки решения мониторинга баз данных от Zabbix SIA 3. Преимущества/недостатки существующих расширений Zabbix для мониторинга баз данных 4. Подробнее о расширении DBforBix v2.3 beta: конфигурирование, возможности 5. Доработка DBforBix: сохраняем преимущества и устраняем недостатки штатного мониторинга баз данных Zabbix 6. Варианты развития идеи

Андрей Денисов – В ожидании мониторинга баз данных

Badoo Development

Как устроен NoSQL, Андрей Аксенов (Sphinx)

Ontico

1. Вводная часть: базовые понятия и определения 1.1. Что такое “файл” 1.2. Роль файлов в современном мире, миф о ненужности файлов 1.3. Файловое хранилище АКА файловая система 1.3.1. внутреннее устройство 1.3.1.1. винтажные и журналируемые. зачем нужен журнал 1.3.1.2. плоские и иерархические 1.3.1.3. контроль доступа 1.3.2. POSIX 1.3.2.1. произвольное чтение 1.3.2.2. произвольная запись 1.3.2.3. атомарные операции 1.3.3. bells and whistles 1.3.3.1. сжатие, шифрование, дедупликация 1.3.3.2. snapshots 1.4. кеширование чтения и записи 2. HighLoad - это сеть 2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову” 2.2. протоколы доступа: stateless и stateful 2.3. отказоустойчивость и ее двуличие 2.3.1. целостность данных 2.3.2. бесперебойные запись и чтение 2.4. Теорема CAP 3. Так в чем проблема? 3.1. Берем большую-пребольшую СХД и… 3.1.1. локальный кеш?! 3.1.2. конкурентная запись?!! 3.1.3. Берем OCFS2 и… 3.1.3.1. Как “падают виртуалки”?! 3.1.3.2. И почему так медленно? 3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение 3.2. Берем CEPH/Lustre/LeoFS и… 3.2.1. Почему так медленно?! 3.2.2. Что значит “ребалансинг”?! 3.3. И немного о резервном копировании 3.3.1. Резервное копирование - это не отказоустойчивость 3.4. И снова про атомарные операции 3.5. Так почему все-таки нельзя просто сложить файлы в базу? 4. Что же делать? 4.1. В первую очередь это зависит от того, какова наша задача 4.1.1. А надо ли экономить? 4.1.2. POSIX - нужен ли он? 4.1.3. Большие файлы - нужны ли они? 4.1.4. Атомарные операции - нужны ли они? 4.1.5. Версионирование - нужно ли версионирование? 4.1.6. Насколько большим должно быть наше хранилище? 4.1.7. И собираемся ли мы удалять файлы? 4.1.8. И каков будет профиль нагрузки? 4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть! 4.3. А для остальных - решения нет. 5. Так что же все-таки делать? (заключение) 5.1. искать бюджет 5.2. все-таки сложить все файлы в базу - личное мнение докладчика 5.3. написать свое 5.3.1. не так это и сложно! 5.3.2. но все же довольно сложно

Бинарные (файловые) хранилища- страшная сказка с мрачным концом

Daniel Podolsky

Тема: Как перестать бороться с графиками и начать жить Я расскажу вам про интеграцию Zabbix и Grafana, чтобы вы могли улучшить возможности визуализации данных мониторинга с помощью Grafana. 1. Зачем нужны графики? 2. Как нарисовать 100 графиков за 10 секунд? (Query Editor, Regex, Templating) 3. И что потом с этим делать? ( Max Data Points, Functions, Performance) 4. События – это тоже Time Series (Annotations) 5. Seek & Destroy (Alerting в Grafana) 6. Бонус: Heatmap

Александр Зобнин, Grafana Labs

Badoo Development

Выбираем поисковик умом головы, Андрей Аксенов (Sphinx)

Ontico

RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа. Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”. При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай. На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств... От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :) Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами. Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе. Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной. Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже. Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости. Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях. А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами. Также подробно будут рассмотрены наши победы и поражения в борьбе со статис

RTB DSP на языке Go: укрощение buzzwords

Daniel Podolsky

Erlang for Yandex

Max Lapshin

Доклад Ивана Мельничука на "Съесть собаку"#14: PHP, 20/09/2018 Тезисы: Как начать кастомно логировать приложение при минимальных усилиях; Как выглядит готовый стек логирования ELK; Немного о наболевшем или как доказать заказчику в чем проблема сайта; Google Analytics семплирует данные, а вы можете узнать больше.

Быстрый в имплементации и в работе мониторинг с использованием ELK

EatDog

Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про: • Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем. • Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps. • Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.

Golang в avito

AvitoTech

Тестируем мобильное приложение в суровых реалиях Интернета

SQALab

JS Lab2017, 25 марта, Одесса Виталий Лебедев (Software Developer at DataArt) Практические сложности при разработке на node.js В этом докладе я расскажу, с какими непосредственными практическими сложностями можно встретиться при разработке на node.js, в силу тех или иных ограничений самого node.js, и какие для этих задач существуют возможные решения. Все материалы: http://jslab.in.ua/ Организаторы: http://geekslab.org.ua/

JS Lab2017_Виталий Лебедев_Практические сложности при разработке на node.js

GeeksLab Odessa

Как устроен мониторинг в Badoo

Uptime Community

My talk on LeoFS, Highload++ 2014

Alex Chistyakov

А. Аксенов "Как устроен NoSql", DUMP-2014

it-people

В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени. Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.

«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)

AvitoTech

La actualidad más candente (20)

Что и почему писать на Erlang

Максим Лапшин — введение в Erlang

Continuous Delivery, или волшебная кнопка для релизов по запросу, Денис Яковл...

Илья Аблеев – Zabbix в Badoo: реагируем быстро и качественно

ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)

Андрей Денисов – В ожидании мониторинга баз данных

Как устроен NoSQL, Андрей Аксенов (Sphinx)

Бинарные (файловые) хранилища- страшная сказка с мрачным концом

Александр Зобнин, Grafana Labs

Выбираем поисковик умом головы, Андрей Аксенов (Sphinx)

RTB DSP на языке Go: укрощение buzzwords

Erlang for Yandex

Быстрый в имплементации и в работе мониторинг с использованием ELK

Golang в avito

Тестируем мобильное приложение в суровых реалиях Интернета

JS Lab2017_Виталий Лебедев_Практические сложности при разработке на node.js

Как устроен мониторинг в Badoo

My talk on LeoFS, Highload++ 2014

А. Аксенов "Как устроен NoSql", DUMP-2014

«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)

Similar a JS Fest. Роман Якобчук. React, взгляд в будущее

Введение в redux

Konstantin Melnikov

Как приручить реактивное программирование

DotNetConf

Устройство современного распределенного Object Storage на примере LeoFS, Алек...

Ontico

Фронтенд сказки, Eugene Zharkov

Sigma Software

Среди всех информационных шумов в мире разработки фронтенд-стек на лидирующих позициях. Открываешь Medium или Twitter и поехало, можно только и делать, что читать материалы до конца жизни или пока не уволят. 1000 истин и нужно выбрать что-то свое. Задача не из простых, попробуем её решить?

Фронтенд сказки

Eugene Zharkov

React + Redux. Опыт использования

GDG Odessa

SECON'2016. Мухаметов Андрей, RxSwift && Apple TV - так ли хорошо всё новое?

SECON

Big switch: жизнь после Microsoft

Alexander Byndyu

The last couple of years the technology of containerization via Docker has gained incredible popularity. Many teams already successfully use infrastructure services, staging, testbed in containers, but many people are afraid of using containers to deploy applications in production. The community still lacks success-stories, especially for applications without microservice architecture. The huge number of approaches and recipes does not as well add confidence in what you are doing. This report is about our fears, successes and solutions for the dockerization of the classical monolith in production..

Docker in Production with AWS ECS

Dmitry Kataev

Фреймворки: недалёкое прошлое и ближайшее будущее Нам повезло — мы живём в эпоху JavaScript-ренессанса. Ленты новостей пестрят яркими названиями: Angular, Backbone, БЭМ, Polymer, React. Поговорим о том, зачем нам столько инструментов, чем они отличаются и, главное, какой из них выбрать. Андрей Саломатин, MoscowJS Разработчик мобильных и веб-приложений. Увлечён техническими сообществами. Работает со стартапами. Любит опенсорс. С 2014 года занимается организацией митапа MoscowJS.

Фреймворки: недалёкое прошлое и ближайшее будущее

Yandex

Фреймворки: Недалёкое Прошлое и Ближайшее Будущее

MoscowJS

Нереляционный SQL

Andrei Nikolaenko

HighLoad++ 2017 Зал «Сингапур», 7 ноября, 17:00 Тезисы: http://www.highload.ru/2017/abstracts/3069.html Если ещё 10 лет назад движение нереляционных СУБД подчёркнуто называлось NoSQL и ходило под лозунгом «SQL is kludge», то сейчас мы видим, что на SQL можно «поговорить» практически с любыми источниками данных: двигаясь от SQL-подобных диалектов (вроде HiveQL, AQL, CQL), возникла целая плеяда SQL-on-Hadoop, среди которых есть способный просверлиться в самые невероятные нереляционные структуры Apache Drill, а в конце августа 2017 появился даже KSQL — SQL-движок над поточником Apache Kafka. И гордость российского NoSQL-субдостроения — Tarantool — также оснастился SQL-движком, а в мире IMDG (резидентных гридов данных) уже речь идёт не просто о поддержке SQL, а ведётся соревнование между движками за полноту соответствия стандартам SQL-99. ...

Нереляционный SQL / Андрей Николаенко (IBS)

Ontico

CodeFest 2013. Прокопов Н. — Зачем вам нужна Clojure?

CodeFest

Опыт эксплуатации большого проекта на Ruby

Alex Chistyakov

Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что хорошо работающий фронтенд — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но и циферки тоже будут. 1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код. 2) Как измеряли, что примерно стоит брать (исследование популярности). 3) Что рассматривали. 4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи). 5) Два пилотных демо-проекта: цифры. 6) Оценка трудоемкости перехода.

SECON'2016. Сергей Аверин. Javascript-фреймворки:  должен остаться только один

SECON

SECON'2016. Аверин Сергей, Javascript-фреймворки:  должен остаться только один

SECON

Similar a JS Fest. Роман Якобчук. React, взгляд в будущее (17)

Введение в redux

Как приручить реактивное программирование

Устройство современного распределенного Object Storage на примере LeoFS, Алек...

Фронтенд сказки, Eugene Zharkov

Фронтенд сказки

React + Redux. Опыт использования

SECON'2016. Мухаметов Андрей, RxSwift && Apple TV - так ли хорошо всё новое?

Big switch: жизнь после Microsoft

Docker in Production with AWS ECS

Фреймворки: недалёкое прошлое и ближайшее будущее

Фреймворки: Недалёкое Прошлое и Ближайшее Будущее

Нереляционный SQL

Нереляционный SQL / Андрей Николаенко (IBS)

CodeFest 2013. Прокопов Н. — Зачем вам нужна Clojure?

Опыт эксплуатации большого проекта на Ruby

SECON'2016. Сергей Аверин. Javascript-фреймворки:  должен остаться только один

SECON'2016. Аверин Сергей, Javascript-фреймворки:  должен остаться только один

Más de JSFestUA

В далекому 2016 році світ почув про вебкомпоненти, а одна ще тоді не дуже розумна команда, якій приходилось верстати дуже багато, вирішила спробувати те все в продукті, який би допоміг зменшити верстку. Про біди вебкомпонентів відомо всім, але про те, як вижити і дійти з альфи до стабільної версії знають не багато. Використання lit-element & lit-html і вирішення наболілих проблем, ось справня ціль моєї доповіді. Happy end обіцяю.

JS Fest 2019/Autumn. Роман Савіцький. Webcomponents & lit-element in production

JS Fest. Роман Якобчук. React, взгляд в будущее

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a JS Fest. Роман Якобчук. React, взгляд в будущее

Similar a JS Fest. Роман Якобчук. React, взгляд в будущее (17)

Más de JSFestUA

Más de JSFestUA (20)

JS Fest. Роман Якобчук. React, взгляд в будущее