Фронтенд 2024-го: JavaScript втомився, Angular втрачає позиції та нова ера зрілості

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Привіт, колеги. Мене звати Олександр, і я займаюся фронтендом в компанії Zfort Group. Цього разу маю для вас не тільки дайджест, а ще й деякі думки щодо підсумків і трендів року, що минув, у екосистемі фронтенду.

Намагатися підбити висновки року для фронтендерів — це дійсно завдання із зірочкою. Мультивсесвіт фронтенду настільки різноманітний і багатогранний, що для кожного FE-розробника він виглядає по-своєму. Хтось провів черговий рік, занурившись у React-екосистему та метафреймворки, для когось він пройшов під знаком Svelte, хтось воював з Tailwind, а дехто взагалі працював із legacy-кодом на jQuery і, можливо, тільки зараз починає міграцію на сучасні інструменти. Навіть сам термін «фронтенд-розробка» зараз охоплює настільки широкий спектр технологій та підходів, що часом складно провести чітку межу між фронтендом та іншими областями розробки.

Колись я робив презентацію про один з розділів серед вподобань фронтендерів, і ця ілюстрація з неї мені видається все ще актуальною:

Будь-який огляд подій 2024 року у фронтенді неминуче буде суб’єктивним та неповним, тому одразу після прочитання статті запрошую в секцію з коментарями. Я ж в свою чергу хочу поділитися своїм поглядом на тенденції у світі фронтенду, за якими я спостерігав протягом останнього року, в тому числі готуючи щотижневі фронтенд-дайджести для ДОУ.

І ще кілька дисклеймерів. Працюючи вже більше 15-ти років у сфері фронтенду, я так і не став прихильником конкретного JS-фреймворку. Якщо є можливість виконати задачу без фреймворків або JS взагалі — я обираю саме цей шлях. Деякі думки нижче зумовлені саме цим підходом.

Також трохи про AI. Як і більшість, я активно використовую AI-помічників для поточних задач в контексті розробки, та майже жодного разу не користався ними для написання технічних статей. Але стало цікаво, як бачить підсумки року штучний інтелект, тому я попросив ChatGPT, Claude, Gemini та Copilot сгенерувати варіанти, щоб порівняти зі своїми спостереженнями, а також зрозуміти, хто з них найбільш адекватний. Деякі результати я викладу одразу ж в тексті. Також я попросив AI структурувати текст більш-менш консистентно за розділами, і розставити деякі заголовки. Тому, якщо якийсь заголовок видається вам занадто крінжовим — то не я, то все роботи зробили!

Тож, вйо до ключових подій та тенденції 2024 року, що повпливали на сучасний фронтенд.

CSS: Brave New World. Прискорення еволюції — від десятиліть до місяців

Цей заголовок запропонував Gemini. І хоча про місяці він трохи перегнув, але ідею зрозумів вірно.

Якщо ви достатньо довго працюєте у веброзробці, то напевно пам’ятаєте епічну сагу впровадження Flexbox. Цей шлях почався ще в 2008 році з першої пропозиції, пройшов через кілька повних переписувань специфікації, експериментальні реалізації з вендорними префіксами, щоб нарешті досягти більш-менш адекватної підтримки браузерів лише у 2015 році.

А Container Queries? Перші обговорення почалися ще в 2010-х, але реальне впровадження ми побачили лише в 2023.

З часом процеси прискорилися. Наприклад, рівно два роки тому в блогах розробників chrome та webkit з’явилися пропозиції та голосування щодо вибору синтаксису для нативного CSS Nesting. Вже через рік «інтернет вибухнув» розсипом статей на тему «CSS Nesting is Here». Сьогодні nesting підтримується усіма браузерами, і якщо ви ще не знайомі з фінальним синтаксисом, рекомендую одну з найкращих статей з цього приводу.

Мабуть, єдиною причиною використовувати CSS-препроцесори на сьогодні залишається відсутність нативних міксинів. Але, схоже, цю проблему також буде разв’язано.

Схожа історія з :has — батьківским селектором, якого нам так довго не вистачало в CSS. Це мій персональний фаворит цього року. І хоча «зеленим» в основних браузерах він став ще рік тому, основного розповсюдження :has здобув саме 2024-го. Завдяки ньому на деяких проєктах вдалося суттєво зменшити кодову базу та складність окремих конструкцій шляхом заміни JS логіки на :has правила в стилях. Не можу не порекомендувати декілька вдалих статей на цю тему. По-перше, це інтерактивний гайд, який дає розуміння поведінки та нових можливостей, а також стаття з корисними :has техніками на кожень день.

Ну а найкращий підсумок щодо CSS в 2024-му році зробив Google у своєму щорічному CSS Wrapped 2024.

Навіть якщо вам не цікаві нюанси cталізації чи нові можливості браузерів щодо впровадження нативної анімації, рекомендую все одно не ігнорувати статтю, бо окрім апдейтів CSS там можна дізнатися, що Popover API вже також є частиною Baseline 2024. А це означає, що нарешті можна відмовлятися від розсипу JS-бібліотек і компонентів для спливаючих вікон і починати використовувати нативний елемент зі своїм API.

Copilot запропонував декілька прикладів цікавих та корисних вебстандартів, що були прийняти в максимально швидкі терміни, але шкода, що більшість з них були AI-галюцинацією.

Причини прискорення

Трохи думок щодо очевидної зміни у швидкості впровадження нових специфікацій. Як на мене, вона має кілька фундаментальних причин:

  • Уніфікація браузерних рушіїв.

Офіційна смерть IE в 2022 та перехід Microsoft Edge на Chromium став каталізатором важливих змін. Тепер замість чотирьох різних реалізацій кожної специфікації (Gecko, Blink, WebKit, EdgeHTML) потрібно підтримувати три, причому дві з них (Blink та WebKit) мають спільне коріння. Це значно спростило процес тестування та впровадження нових функцій. Firefox (Gecko) продовжує втрачати свої відсотки, тож почав активніше синхронізувати імплементацію стандартів з Chromium-based браузерами.

Через політику Apple оновлення Safari відбуваються не завжди так гладко, як би хотілося розробникам, ба більше — іноді можна почути, що «Webkit — це новий IE», але все ж цю ситуацію не можна порівнювати зі старими часами. Я досі пам’ятаю верстку під IE 5.5 і цей біль трохи іншого рівня.

  • Активізація спільноти вебстандартів.

2024 рік показав, наскільки важливою є роль окремих особистостей у розвитку вебстандартів. Lea Verou, яка очолила кілька важливих ініціатив в W3C, Una Kravets з її невтомною роботою над специфікаціями та пропагандою нових вебстандартів, Tab Atkins-Bittner, вебгік Bramus Van Damme та інші ентузіасти не просто працювали над стандартами — вони змінили сам підхід до їх розробки. Важливим фактором стала їхня активна присутність у соціальних мережах та технічних спільнотах, де вони не лише пояснювали нові специфікації, але й збирали зворотний зв’язок від розробників.

Я вже друге десятиріччя слідкую за такими персоналіями в вебі і не міг не запитати AI з цього приводу. Було цікаво, чи зв’яже він контексти без додаткових підказок. Найкраще вийшло у Claude, а Gemini та Copilot максимально провалилися.

  • Модернізація процесу стандартизації.

Схоже, що W3C та WHATWG нарешті знайшли спільну мову та оптимізували процеси прийняття нових стандартів. Було впроваджено паралельне тестування специфікацій у різних браузерах, швидші цикли зворотного зв’язку, більш гнучкий процес внесення змін у специфікації та взагалі покращилася комунікація між розробниками браузерів та авторами специфікацій.

Tailwind: від суперечок до стандарту

Говорячи про CSS у 2024 році, неможливо оминути Tailwind. Якщо раніше він викликав гарячі дебати у спільноті, то цього року utility-first підхід фактично став мейнстрімом попри велику кількість скептиків (я серед них). Але мушу визнати, що Tailwind v4 виглядає доволі цікаво. Цікаво спостерігати, як Tailwind намагається знайти баланс між збереженням своєї філософії «utility-first» та адаптацією до нових можливостей нативного CSS.

Ну й показово, що великі компанії та фреймворки почали активно інтегрувати Tailwind у свої офіційні інструменти. Qwik, Astro, Next.js, Nuxt, SvelteKit та багато інших тепер пропонують вбудовану підтримку Tailwind прямо з коробки.

А ще цього року CSS отримав новий офіційний логотип.

Інструменти фронтенду: рік швидкості та оптимізації

2024 рік став знаковим для інструментів фронтенду і здається, визначив тренд для наступного року.

JavaScript Runtimes: Еволюція та конкуренція

AI порекомендували приділити увагу оновленням Bun і Deno, але щодо Bun я засумнівався, бо його спалах 2023-му вже не виглядає так яскраво в 2024-му.

Не можу не погодитися з Claude. На жаль (або на щастя), у мене не було досвіду практичного застосування Bun на реальних проектах, але виходячи зі своїх спостережень можу констатувати, що у 2024 році для масового впровадження нових JavaScript runtime необхідно щось більше, ніж просто швидкодія. Хоча Bun 1.0 став помітним релізом у 2023 році, у 2024 він залишився експериментальним для багатьох команд, тоді як Node.js продовжує домінувати в продакшені.

Квітневий реліз Bun 1.1 приніс декілька корисних апдейтів, включно з «Windows Support». Я спробував, і маю констатувати, що принаймні у мене bun все ще має проблеми з компіляцією на Вінді (так, фронтендери на вінді все ще існують).

У той час як Bun продовжував вражати бенчмарками, але залишався експериментальним для більшості, Deno показав, що майбутнє веброзробки може бути не лише швидким, але й безпечним та зручним. Deno 2.0 став однією з найважливіших подій року для інфраструктури фронтенду. Замість гонитви за абстрактними показниками продуктивності команда Deno зосередилась на вирішенні реальних проблем розробників, нарешті додавши повноцінну підтримку npm-екосистеми та package.json.

Це був важливий крок, який прибрав основний бар’єр для імплементації Deno в реальних проєктах. Особливо приємно, що разом з рантаймом еволюціонує і вся екосистема Deno — Fresh, JSR, чи Deno Deploy, який став повноцінною альтернативою традиційним платформам розгортання. Також показова активність ком’юніті та навіть офіційного блогу Deno, який існує не просто «для галочки», а є джерелом дійсно цікавих статей, які регулярно потрапляють до щотижневого дайджесту.

Vite: революція у швидкості розробки

З моєї бульбашки виглядає так, що Vite стає новим стандартом серед інструментів веб розробки. Vite 5.0 був справжнім проривом рік тому, завдавши тренд на 2024-й, а свіжий реліз 6.0 ще раз підтвердив серйозність намірів. На ViteConf цього року був продемонстрований графік зростання популярності, який дійсно вражає.

Ба більше, в State of Frontend 2024 в розділі Building Tools Vite показав безпрецедентне співвідношення used/liked, що само по собі вже показово. Особливо якщо порівняти з webpack.

Інші інструменти

Chrome DevTools цього року як завжди отримав багато оновлень, але вони усі виглядали рутинними апдейтами і нічим цікавим не запам’яталися, окрім AI assistance panel. Але, як зазвичай це буває у Google:

Також Google оновив Lighthouse до версії 12, додавши нові метрики для оцінки Core Web Vitals та прибравши PWA-панель.

Playwright і Cypress продовжили конкурувати за звання найкращого інструменту для E2E-тестування. Playwright представив вдосконалену систему запису тестів, а Cypress додав підтримку мультибраузерного тестування в реальному часі. Ну а Vitest став де-факто стандартом для тестування у Vite-проектах, пропонуючи максимальну швидкість та сумісність з Jest API.

Закінчити цей розділ хочу проєктом, який має повпливати на екосистему фронтенду у наступні роки. VoidZero обіцяє революціонізувати розробку на JavaScript. Нова компанія, заснована Еваном Ю, творцем Vue.js та Vite, вже отримала $4,6 мільйона початкового фінансування. Мета VoidZero — створити відкритий інструментарій, який охоплює всі етапи розробки JavaScript-застосунків, включно з парсингом, форматуванням, лінтингом, бандлінгом, мініфікацією та тестуванням.

Особливістю є використання єдиного абстрактного синтаксичного дерева (AST) для всіх завдань, що зменшує дублювання процесів та підвищує ефективність. Для досягнення високої продуктивності інструменти розробляються на Rust, що в теорії має забезпечити швидкодію та безпеку пам’яті. Мені здається, що цей проєкт має усі шанси відбутися, бо окрім фінансування він вже має команду з core-розробників Vite, Vitest, Rolldown та Oxc включно з самим Еваном.

Загалом VoidZero прагне спростити та об’єднати процес розробки JavaScript-застосунків, пропонуючи єдиний високопродуктивний інструментарій для розробників, тому я буду тримати кулачки за них.

До речі, доволі показові відповіді різних AI-чатів на питання, що вони знають про VoidZero. Copilot не зрадив собі, згалюціонувавши повну маячню. Claude цього разу зазначив, що не має актуальних даних щодо новин, що відбулися в жовтні. ChatGPT видав непоганий шмат знань з посиланнями, але деякі з них були не робочі. Gemini ж цього разу показав себе найкраще, вивівши і новину, і аналіз події та передбачення на майбутнє.

JavaScript-екосистема: рік консолідації та оптимізації

2024 рік став для JavaScript-екосистеми роком пошуку балансу між інноваціями та стабільністю. Якщо у CSS ми спостерігали прискорення еволюції, то у світі JavaScript відбувалася більш виважена трансформація з фокусом на продуктивність та спрощення розробки.

React: прогрес ціною ускладнення

Server Components, які стабілізувались у 2024 разом з React 19 та Next.js 15, стали, мабуть, найбільш обговорюваною подією року в цій підмножині фронтенду. Пам’ятаю доволі значний проміжок року, коли розділ «React» в щотижневних дайджестах скадався з суцільного потоку статей про серверні компоненти. Проте, на відміну від попередніх великих оновлень React, цього разу спільнота зустріла зміни з певною обережністю. Server Components запропонували дійсно інноваційний підхід до оптимізації, але ціною значного ускладнення ментальної моделі фреймворку, що створює нові виклики для розробників. Мабуть, React цього року був одним із небагатьох елементів в екосистемі JS, які обрали такий шлях розвитку.

Тому показово, що багато розробників відкладає міграцію на Server Components, віддаючи перевагу перевіреним клієнтським рішенням. Це призвело до певної фрагментації спільноти: частина команд повністю перейшла на новий підхід, тоді як інші залишаються з «класичним» React, обравши стратегію «wait and see». Ну а хтось продовжує шукати сенси. Обидва підходи мають право на життя, і така диверсифікація може бути корисною для екосистеми в довгостроковій перспективі. З іншої сторони, комусь такі зміни можуть взагалі не зайти, бо в світі JS з’являються більш цікаві і, що важливо, простіші рішення.

Angular та Vue: революція чи еволюція

Цікаво спостерігати, як «старші» технології можуть не просто відроджуватися, а й задавати нові тренди. Angular, який дехто вже списав з рахунків, продемонстрував, як традиційний enterprise-фреймворк може адаптуватися до сучасних вимог веброзробки. Впровадження сигналів в Angular запропонувало простішу та інтуїтивнішу модель реактивності, яка при цьому забезпечує кращу продуктивність. Angular 18 та 19, що вийшли протягом цього року, стабілізували сигнали та додали корисних фіч типу інкрементальної гідрації та standalone-компонентів. Парадоксально, але тим не менш, вакансій більше не з’являється, спільнота залишається відносно невеликою, а більшість знайомих ангулярщиків за останній рік змінила стек.

Якщо мене ставлять перед вибором: React, Vue чи Angular, я завжди обираю Vue. Тому не може не радувати, що Vue продовжує потрохи еволюціонувати, зберігаючи при цьому простоту та елегантність. Реліз Vue 3.5 цього року не приніс революційних змін у Vue, але зробив роботу з фреймворком ще зручнішою. Цей оновлений реліз додав кілька суттєвих покращень, що стали особливо помітними в масштабних проєктах. Оптимізували систему реактивності, покращили SSR та деякі функції, та й таке. Екосистема Vue також в схожому стані. Ніби покращення інструментів відбувається, Vue Router, Pinia, Nuxt регулярно оновлюються, але водночас анонсований Nuxt 4 так і не вийшов.

Повернення до основ: Web Components та HTMX

Одним з найцікавіших трендів року стало зростання популярності «мінімалістичних» підходів до веброзробки.

Web Components нарешті отримали достатню підтримку браузерів для серйозного використання. Останні півроку спостерігаю дебати між тими, хто вважає, що за вебкомпонентами майбутнє, і тими, хто вважає, що це утопія. Але краще за усіх сказав Nolan Lawson в статті «Web components are okay». Так, вони наразі не можуть повноцінно замінити класичний JS чи фреймворки, але це не проблема, якщо не ставити її за мету.

Ну а HTMX продемонстрував, що не усі проєкти потребують складної архітектури. Його підхід «JavaScript за необхідності» виявився дуже привабливим для таких, де пріоритетом є простота підтримки та швидкість розробки. Показово, що навіть великі компанії почали експериментувати з цим підходом для певних типів проєктів. Щось є в концепті HTMX таке невловимо олдскульне, тому кожен раз, коли я хочу розім’ятися на черговому пет-проєкті, одна рука тягнеться до HTMX, а інша вже підключає jQuery. (жоден AI з першого разу не зтягнув цього приколу).

До речі, щодо приколів. Якщо ви відкриєте офіційну сторінку htmx в X, то побачите нескінченний потік сарказму та мемів.

Інші гравці: фокус на продуктивності

2024 рік показав зростаючий інтерес до альтернативних рішень:

Solid.js та Qwik продовжили демонструвати, що можливо створити сучасний фреймворк з вражаючою продуктивністю «з коробки». Особливо цікавим є їхній підхід до оптимізації первинного завантаження та гідратації.

Svelte цього року також заслуговує на особливу увагу. Реліз Svelte 5 з новою системою рективності runes став великою подією (у вузьких колах). Це оновлення не просто додало нові можливості — воно переосмислило сам підхід до управління станом у фреймворку. Хоча у мене не було можливості доторкнутися до цієї магії на проєктах, приємно бачити, як росте екосистема Svelte. З’являється все більше бібліотек та інструментів, оптимізованих саме під цей фреймворк, що робить його все більш привабливим для серйозних завдань.

Висновки щодо JS

JavaScript-екосистема у 2024 році показала ознаки не тільки зрілості, але й «втоми від складності». Спостерігається тенденція до пошуку простіших, але не менш ефективних рішень. React, залишаючись домінуючим фреймворком, ризикує втратити частину користувачів через зростаючу складність. Angular намагається модернізуватися (і мені особисто подобаються останні зміни), але стикається з викликами legacy-коду та складної екосистеми. Vue балансує між стабільністю та потребою в інноваціях. HTMX та Web Components показують, що існує реальний попит на альтернативи складним SPA-рішенням. Спостерігається тенденція до пошуку «золотої середини» між можливостями сучасних фреймворків та простотою традиційного вебстеку.

AI у фронтенді: від хайпу до практики

2024 став роком, коли AI-інструменти у фронтенд-розробці перейшли від стадії експериментів до реального практичного застосування. Якщо в 2023 ми в основному говорили про GitHub Copilot та його конкурентів як про «розумне автодоповнення», то в 2024 AI-асистенти стали повноцінними учасниками процесу розробки.

Але тема таких інструментів в нашому фронтендерському світі — це зовсім інша розмова, яка варта окремої статті, тому просто поділюся деякими спостереженнями за цей рік, не заглиблюючись в деталі і конкретні мовні моделі. Мій персональний фаворит серед безкоштовних версій розумних чатів в контексті розв’язування поточних фронтендерських задач цього року — Claude від Anthropic. При чому я маю на увазі не тільки і не стільки рефакторинг поточного коду в межах IDE, скільки створення реальних робочих рішень з нуля.

Та й в межах роботи з цією статтею він показав себе краще за своїх конкурентів. Єдина проблема — це база знань, яка обмежена весною 2024. Ну і дещо куций контекст в безкоштовній версії. На друге місце я ставлю ChatGPT, який демонстрував стабільний результат цього року. Стабільно середній. Свою роботу ця робоча конячка робила, але, зазвичай, далеко не з першого разу.

Наступний в моєму рейтингу йде Gemini. AI від Google суттєво покращився за останні місяці й схоже, що в 2025 це буде дісно топ. Ну а Copilot.. Гадаю, тут багато хто мав справу з GitHub Copilot і розуміє можливості цього інструменту. Але Microsoft Copilot, який Microsoft намагається інтегрувати в свою екосистему вже більше року, це щось. Час від часу він допомагає мені з імейлами та документами в різних форматах, але коли діло доходить до технічних моментів чи коду, то біда. Не впорався цей Copilot і зі статтею. Я вже забув, коли останній раз бачив стільки галюцинацій та дивних рекомендацій.

Висновки: шлях до зрілості

Підсумовуючи рік, можна відзначити, що фронтенд входить у нову еру зрілості й продовжує еволюціонувати з акцентом на продуктивність та простоту. CSS вийшов на крейсерську швидкість імплементації нових стандартів, здобуваючи потужні можливості з кожним апдейтом браузерів. JavaScript-екосистема почала рух від фрагментації до консолідації, де різні інструменти та фреймворки знаходять свої чіткі ніші та вчаться ефективно взаємодіяти один з одним.

Особливо важливо відзначити тенденцію до «розумної» оптимізації на рівні інструментів розробки. Замість того, щоб перекладати відповідальність за продуктивність на розробників, сучасні фреймворки та компілятори беруть цю роботу на себе, дозволяючи розробникам зосередитися на бізнес-логіці та UX.

2025 рік обіцяє бути не менш цікавим. Перш за все — фронтенд-розробка нарешті перестає бути «диким заходом» вебтехнологій і перетворюється на зрілу галузь з усталеними практиками та чіткими напрямками розвитку. Проєкти на кшталт VoidZero можуть стати каталізаторами подальшої стандартизації та спрощення інструментарію, а зростаюча роль AI-інструментів продовжить трансформувати процес розробки.

👍ПодобаєтьсяСподобалось39
До обраногоВ обраному10
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дуууужжжее гарна стаття! Дякую

Прочитав статтю і пішов перевіряти чи це справді Dou. Незвично хороша стаття

Дякую. Сам час від часу перевіряю, чи ми на ДОУ, бо трохи дивно не бачити срачів в коментах :)

Стаття топ, дякую за роботу!

Дякую, дуже гарний підсумок 2024 FE року!

Та JS в цілому норм мова. Не нормальним є підхід «JS first», коли робота над проектом починається не з дизайну, верстки, стилізації, а з написання JS коду. При цьому підходові решта є вторинним. HTML та CSS не стоять на місці та розвиваються, це примушує розробників JS-фреймворків постійно випускати нові версії. Хоча рішення лежить на поверхні, інвертуйте підхід, використовуйте JS за прямим призначенням, як скриптову мову для інтерактивних речей. Тоді весь процес розробки буде в 5 разів дешевшим, а коду буде в 10 разів менше.

Я написав першу версію свого власного фреймворку ще до React’а. В мене тільки три роки тому з’явилася друга версія, яка нічим принципово не краща за першу, просто переписана (навіть не мною) на сучасний модульний підхід. Нещодавно я вніс перше розширення функціональності, бо захотілося трошки синтаксичного цукру. А Реакт зробив за цей час вже 19-ту спробу стати кращим.

Зараз я спостерігаю, як один проект переписують на «сучасні» технології. Коду стало в рази більше. Багів — тьма. Те, що робило півтора розробники зараз роблять троє в чотири рази довше. Це пряме порівняння підходів, в якому сучасне з тріском програло «легасі».

AI-інструменти у фронтенд-розробці перейшли від стадії експериментів до реального практичного застосування

Олександре, цікаво почути два-три приклади «створення реальних робочих рішень з нуля» з вашого досвіду.

Один з останніх кейсів, яким можу поділитися, це створення плагіну «Text to speech». Клієнт забажав такий функціонал для свого сайту, для сторінок і модулів різного типу, зі специфічними побажаннями для деяких з них. Через дуже лімітований час і бюджет спершу на думку прийшло використання вже готового плагіну, по робити кастомний функціонал з нуля, з урахуванням усіх побажань клієнта точно не вкладається в дедлайн, навіть якщо точно знаєш як це зробити технічно. Але після години гугління зрозумів, що жоден плагін не покриває потрібний функціонал. Тому вирішив піти шляхом колаборації з AI. Я склав детальний промпт, де в подробицях зробив опис функціоналу і рекомендації, як саме я би це робив. Майже одразу AI (Claude) згенерував мені майже все що потрібно, і далі ми вже з ним працювали над нюансами. Після того, як функціональна частина була готова (на це пішло 3-4 години, і ще 2 на тести), я запитав AI, що б він порекомендував мені ще додати до плагіна. На подив, першою рекомендацією було «попрацювати над UI/UX», і далі ми вже робили з плагіна конхвєтку в візуальному плані.
Можливо, цей приклад не архітектурного рівня чи софтверного інженірінгу, але, як на мене, це win-win кейс. І клієнт отримав бажаний функціонал з максимальною кастомизацією під нього і швидше, ніж планувалося, і мені самому було цікаво створювати щось нове в колаборації з ШІ

дякую за огляд. щодо інструментів стандартизації не можна не згадати вдалий реліз Biome півроку тому, який дозволяє забути про eslint, prettier i зоопарк їхніх плагінів.

згоден, Biome цікава тулза, але якось повз мене пройшла, з дефолтних лінтерів або ще не мігрував, або вже OXC

Дякую за статтю. Було цікаво почитати.

Дякую за цікаву статтю та регулярні дайджести

В своїх проєктах надаю перевагу TypeScript без каркасів

Стаття дуже класна. Дякую 👍

Підписатись на коментарі