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

Розповідати про щось абстрактне легко і прикольно – і розумним можна прикинутися, і перевірити тези ніяк не вийде – це ж абстракція. У світі, де кожен перший тепер "ШІ-візіонер" я хочу поговорити з вами про ШІ максимально предметно на прикладі своєї роботи – GitLab.  І це ідеальний приклад, поки всі розповідають про світ рожевих поні – greenfield проєкти, де все пишеться з нуля, я хочу поділитися досвідом хардкорного brownfield – що де і як на проєкті, що існує багато років. Ми поговоримо про те: - Як ми дружимо (або скоріше ні) штучний інтелект та джаваскрипт - Мої налаштування та секретний соус для агентської розробки - Які мої досягнення на пару з Опусом (улюблена моделька) - Скільки коду на джаваскрипті я пишу руками - Що заважає нам отримати оту міфічну х10 продуктивність і що я з цим роблю Я сподіваюся, що з цього case study кожен вийде з розумінням, а що саме зробити на своєму проєкті, щоб покращувати життя вже просто зараз.

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

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

Як залишатися успішним у світі, де AI змінює індустрію? У цій доповіді ми розглянемо дослідження та практичні приклади, що допоможуть зберегти стабільність кар’єри й навчитися ефективно використовувати AI для власного професійного розвитку.

<p>JavaScript та Golang — це два різні світи, які часто перетинаються в сучасних проєктах: перший домінує у frontend-розробці та швидкому прототипуванні, тоді як другий — у високонавантажених сервісах та мікросервісних архітектурах. <p>У цій доповіді я поділюся власним досвідом переходу з JS на Go, порівняю підходи до асинхронного програмування, архітектури додатків, роботи з базами даних та інструментів. Ми розглянемо не тільки відмінності, а й спільні риси, які допомагають розробникам легше адаптуватися між цими екосистемами.</p>

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

В цій доповіді Дмитро розповість як створив DSL мову для парсінга HTML сторінок, яка використовується для WEB скрапінга. Поговоримо про алгоритми дерев, оптимізацію JS-коду, DOM, а також спробуємо це все на прикладі live coding.

Під час дискусії ми поговоримо про можливості JavaScript, найкращі практики та сучасні тенденції разом із досвідченими експертами.

Розповім про деякі проблеми, з якими стикаються сучасні креативні розробники