FrontEnd

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

Я расскажу о том, как мы в Cloud изменили стандартные подходы к проектированию приложения...

Из доклада вы узнаете:

* какие боли несет в себе микросервисный подход;

* как не создать микросервисный монолит;

* оптимизации, оптимизации и еще раз оптимизации;

* как работать с консистентностью и Bus-фактором;

* как следить за качеством;

Приходите, скучно не будет.

Доклад основан на реальных событиях.

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

Я расскажу, как мы разрабатываем свою библиотеку компонентов на основе хуков React Aria.

Как пишем доступные компоненты: от простых кнопок до монструозных календарей.

Как легко переопределить часть поведения, но оставить остальное нетронутым.

Мы знаем термин Web3 уже 9 лет. Мало кто не слышал о блокчейне или криптовалютах. Считается, что это новая эпоха развития Интернета, его третья версия.

Но готовы ли мы, как разработчики, к этой новой эпохе?

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

- Что такое Web3, чем он отличается от Web 2.0?

- Как написать Web3 приложение?

- Примеры Web3 приложений

- Что изменяется во фронтенд-разработке?

- Какие есть готовые решения / библиотеки (wagmi, web3)?

А что если я скажу, что можно сделать SPA приложение с SSR без помощи Next.js и React или других подобных фреймвоков. При этом в браузер пользователя можно не тащить мегабайты JS. И все будет работать очень быстро и динамично.

В своем докладе я сравню 2 подхода: классический SSR на базе NextJS и подход на основании библиотек типа HTMX или Turbo Hotwire. Разберу плюсы и минусы разных вариантов. Будет интересно.

Оптимизация web-приложения является важной частью его разработки, о чем многие, к сожалению, забывают. Быстрый сайт дает приятный пользовательский опыт, увеличивает конверсию и экономит ресурсы машины. Но когда разработчиков спрашиваешь об оптимизации, очень часто, в лучшем случае, можно услышать что-то о мемоизации или минификации кода. Однако это только вершина айсберга.

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

В докладе будут затронуты такие темы как:

- Оптимизация изображений и других медиа файлов

- Оптимизация оптимизаторов картинок

- Виды рендеринга страницы и как их выбирать

- Ленивый паттерн (но не разработчик)

- Алгоритмы сжатия файлов

- Разделение кода

- Виды кэширования для различных задач

- Оптимизация данных для пререндеринга

- Оптимизация мультиязычных сайтов

И многое другое.

Часть 1.

- Таймеры в HTML5: взгляд изнутри

1. Приветствие и краткий экскурс в тему

2. Что такое Realm

3. Что такое Environment и его связь с Realm

4. Кратко про Event Loop HTML5: как работает Macrotask Queue и как заблокировать Main Thread

5. setTimeout - алгоритм его работы

6. setInterval - алгоритм его работы и почему он плох для работы с анимациями

7. Почему важно использовать clearTimeout и clearInterval

8. Заключение, плавный переход к queueMicrotask

Часть 2.

- Из макро в микро: создаем асинхронный код с помощью queueMicrotask

1. Кратко про queueMicrotask

2. Кратко про Event Loop HTML5: как работает Microtask Queue

3. Как работает queueMicrotask - очень подробно

4. Кратко про requestAnimationFrame

5. Когда лучше использовать requestAnimationFrame вместо queueMicrotask

6. Кратко про requestIdleCallback

7. Когда лучше использовать requestIdleCallback вместо queueMicrotask

8. Заключение

Как-то раз я захотел написать приложение, но хоть я и умел писать более-менее сносный бэкенд, делать этого не хотелось. Вспомнил, что можно хранить данные на стороне фронтенда (например, в IndexedDB), но хотелось, чтобы приложением можно было пользоваться с нескольких устройств, а также взаимодействовать с другими пользователями. Так что чистый IndexedDB не подошёл.

В итоге я вывел для себя несколько критериев того, что хочу видеть:

1. Сервер раздаёт только статику, либо он очень тонкий.

2. Все данные хранятся только на клиенте.

3. Использовать приложение можно с нескольких устройств.

4. Можно взаимодействовать с другими пользователями.

В докладе расскажу, как я решал сопутствующие проблемы и к каким решениям пришёл.

Скоро появятся