Нещодавно Superhuman (раніше Grammarly) запустила Superhuman Go — AI-асистента, який працює поруч із вами на кожній платформі. Щоб його створити, нам було потрібне масштабоване рішення, яке підтримує необмежену кількість агентів, динамічно формує інтерфейс користувача та виглядає однаково на всіх підтримуваних десктопних і мобільних платформах. Приєднуйтеся, щоб дізнатися, як ми знайшли рішення для цього інноваційного продукту

Ще десять років тому ми тягнули в проєкти бібліотеки та фреймворки не від хорошого життя. Це був єдиний спосіб вижити в часи «бравзерних воєн» і не потонути в спагеті-коді. Фреймворки стали нашим порятунком, і ми до них звикли. З того часу веб змінився, а наші звички — ні. HTML, CSS та JS зробили величезний стрибок вперед, але ми продовжуємо автоматично тягнути мегабайти абстракцій, щоб просто відрендерити список товарів, і гордо називаємо це «сучасним стеком». Настав час поставити собі незручні питання: • Що насправді вирішує фреймворк сьогодні, окрім нашого страху залишитися наодинці з чистим JS? • Де межа, за якою «комфорт розробника» стає безглуздим тягарем для продукту? • Чи не став фреймворк просто зручною ширмою, за якою ми ховаємо небажання знати, як працює платформа? Я не закликаю видалити React завтра (хоча…). Але я прагну розібратися: чи досі фреймворки вирішують реальні технічні проблеми, а чи ми створюємо черговий Hello World на реакті просто тому, що вже не вміємо інакше?

Багато хто вважає архітектуру на фронтенді мемом. І, чесно, підстави для цього є. Але ми все одно її будуємо — на реальному продукті, в реальній міграції. Ця доповідь про те, як ми переводимо великий e-commerce з Clojure-моноліту на окремий frontend: тонкий клієнт, React як UI бібліотека, а Next.js як деталь системи — не ядро. Наскільки це виходить насправді, де реальність розходиться зі схемами та початковими планами. Без канонічних рецептів — живий досвід із живого продукту.

Турбо-гайд по найгарячіших оновленнях Chrome DevTools за 2024-2025 роки, які кардинально змінюють підхід до фронтенд-розробки. Ми детально розглянемо інтеграцію штучного інтелекту Gemini, який тепер є вашим особистим супер-аналітиком у Performance Panel. Окрім AI, ми зануримося у посилений аналіз продуктивності, включаючи розширену підтримку Core Web Vitals та калібровані пресети обмеження ЦП, що дозволяють перетворити боротьбу зі "слизьким" LCP на чіткий детективний процес. Окрім хардкорного налагодження, ми охопимо нові можливості для стилізації та зручності, а саме scroll-driven animations та покращеної роботи з CSS Nesting, Autofill та багато інших плюшок. Детально подивимось на MCP, тому що хто не знає, що таке МСР, тому не заплатять в 2026 році.

У добу AI код може писати будь-хто — навіть ваш тімлід чи пекар. Але хто подбає про його якість? У цій доповіді ви дізнаєтесь, чому TDD досі критично важливий, як відрізнити хороший тест від поганого, навчити AI писати код правильно з першого разу та чому дисципліна й архітектурне мислення рятують нерви й проєкти.

Доповідь про те, як підвищити продуктивність розробника за допомогою AI-інструментів у Cursor — від автоматизованого читання та написання коду до створення AI-«колег» і побудови наскрізних пайплайнів розробки.

У багатьох проєктах хуки стали рефлексом: їх додають автоматично, навіть там, де вони не потрібні. Але кожен зайвий хук — це додаткова складність, і часто — без вигоди. У цій доповіді разом з вами спробуємо розібратися, коли хуки не потрібні та як писати простіший та зрозуміліший код без зайвих use*.

Пам'ятаєте часи, коли ми тиждень налаштовували Webpack до того як написати перший рядок кода? А що зараз? Зараз збірка глибоко інтегрована з фреймворком. Чи ви взагалі маєте уявлення яка конфігурація Vite у вашому Next.js чи Remix.js застосунку? Вам це потрібно? Що нам заважає позбутися збірки? Викинути її до дідька? Подивимося?

Чому сучасні фреймворки вкотре намагаються переосмислити реактивність — і до чого тут signals? У цій доповіді ми подивимось на signals як на спробу дати JavaScript-розробникам інструмент точкової реактивності без зайвого коду, проксі чи мемоізації. Задача, яку вони вирішують, стара як сам фронтенд: як оновлювати лише те, що потрібно — і робити це передбачувано. Ми розберемось, як працює цей підхід, які фреймворки його вже впровадили, і що означає поточна пропозиція в TC39. А головне — чи signals справді розв’язують проблему, чи просто створюють нову точку складності з іншим синтаксисом.

Ця доповідь — як легка, але дуже знайома екзистенційна криза фронтендера. Ми почнемо з простих маніпуляцій DOM, пройдемо через jQuery, SPA, React, і завершимо роздумами про server-side rendering — не без допомоги одного треду з твітеру, який раптово виявився мудрішим за більшість підручників.