FrontEnd

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

В докладе разберем базовые составляющие фреймворков и сравним их индивидуальные особенности.

Это поможет быстрее изучать новые технологии.

Видеть разницу и оптимально выбирать стэк.

А главное — аргументированно холиварить на тему “какой фреймворк лучший”!

В своем докладе я хочу показать, как можно при помощи HTMX и пары строчек кода заменить тяжеловесные React и Vue.

Этот доклад можно рассматривать как продолжение прошлогодего доклада. Только теперь я полностью сосредоточусь на практике.

– Проблема props-drilling;

– Как не стоит решать проблему через контексты;

– Правила работы с контекстами;

– Фабрика провайдеров и хуков;

– Утилиты для безопасной работы с контекстами;

– Пример организации компонентов с разделением ответственности и использованием утилит;

– Преимущества: типобезопасность, разделение ответственности, легкая масштабируемость.

Доклад о том какие существуют популярные заблуждения есть в сообществе и что с собеседованиями по JS не так:

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

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

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

В большой компании где много команд, которые работаю над одним продуктом в монолите, надо выбирать единый путь.

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

Как мы это сделали, какой путь прошли, что выбрали, и какие выводы получили. Вот об этом и будет доклад.

Во время разработки web-приложения часто встает вопрос о использование библиотеки компонентов. Что делать: писать свою или взять готовую? Если писать свою, то это долго и дорого. Нужно решать проблемы, которые до вас уже решили разработчики готовых библиотек. Если взять готовую, то в библиотеку сложно вносить точечные фиксы, так как компоненты закрытые.

Headless подход - это золотая середина между этими двумя подходами.

Доклад про подход Atomic CSS в верстке и разработку инструментов

Кратко вспомним базу - почему Atomic CSS. Рассмотрим популярные решения для работы в этом подходе и сравним их с моим изобретением - mlut. Разберем проблемы известных инструментов и посмотрим, как я решил их в своем. Будут интересные архитектурные решения, технические детали и немного хардкора

Те, кто занимается версткой, смогут по-другому взглянуть на Atomic CSS и возможно, взять в работу новый инструмент. А те, кто пишет системный код и тулинг - получить вдохновение и перенять нестандартный опыт

- Обзор инструментов для создания нового проекта

- Разбор плюсов и минусов

- Обзор современных архитектур, и почему FSD не панацея

- Обзор современных UI-библиотек, и когда свои велосипеды нужны

- Обзор подходов к работе с системой контроля версий