«Фронтенд — це просто?»: чому я не обрав бекенд і ні про що не шкодую

Мабуть, чули цю фразу, якщо у вас є досвід у фронтенд-розробці? Цікаво, як ви відреагували: погодились, чи палко почали переконувати співрозмовника у протилежному? Це питання ставить фронтендник Сержіо Вінісіус де Са Лусена. Передаємо йому слово.

---

Перш ніж зосередитися на фронтенді, я 2,5 роки працював із Java та з PHP у Agile-командах. Мені завжди подобався фронтенд. Але я хотів перевірити, раптом бекенд — це те, що мені треба, а вже потім ухвалювати остаточне рішення щодо своєї кар’єри.

Я обрав фронтенд не в останню чергу тому, що дуже люблю, коли мою роботу бачать інші.

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

Коли я починав у 2010 році, jQuery все ще був королем. Фронтенд-розробники вирізали зображення з файлів PSD та оптимізували їх, щоб зробити сторінку якомога легшою. Це підвищувало її конкурентоспроможність для SEO (про це я розповім трохи пізніше).

Раніше ми також робили багато анімацій: завдяки jQuery та іншим бібліотекам це було дуже легко.

Багато людей тоді навіть не знали JavaScript, бо працювали з jQuery. У StackOverflow в усіх відповідях використовували jQuery. А VanillaJS ще був зовсім непопулярним.

Раніше jQuery полегшував життя розробників, але багато людей користувались ним без належного контексту. Вони просто вивчали JavaScript, використовуючи цю бібліотеку.

jQuery став популярним не в останню чергу тому, що він був простим та забезпечував кросбраузерну підтримку, а нам тоді доводилось враховувати Internet Explorer (тут я не маю на увазі IE10 чи IE11, я кажу про IE5.5 і, можливо, навіть більш ранні версії).

Структура коду також була досить простою. Зазвичай існувала папка для зберігання всіх файлів CSS і ще одна — для всіх файлів JS. Було кілька основних порад щодо ефективності, як-от імпортувати CSS у верх файлів HTML, а JS — донизу. Деякі інші методи, наприклад, CSS-спрайт, також були популярними. Ці практики стали використовувати ще більше, коли Стів Содерс випустив книгу «Високопродуктивні вебсайти».

Покращення

Фронтенд розвивається дуже швидко, і це хороша новина. Протягом багатьох років з’явилося багато фреймворків і бібліотек для вирішення різних проблем, які виникали у великих компаній. З часом вони ставали популярнішими (деякі через хайп, а деякі тому, що були дійсно хороші).

Наприклад, однією з найбільших проблем в JavaScript є маніпулювання DOM, оскільки це спричиняє багато непотрібних обчислень у браузері. Це може означати витрати на продуктивність для кінцевого користувача.

Ось простий приклад:

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

ReactJS вирішує цю проблему за допомогою так званого віртуального DOM. Він не оновлює весь список, а зосереджується лише на оновленому вмісті, уникаючи величезної маніпуляції з DOM. Це значно ефективніше.

Пам’ятаєте, я обіцяв розповісти про SEO? Так от, якщо ви працюєте з вебпродуктом, який не є внутрішнім інструментом, SEO має вирішальне значення. Вам потрібно конкурувати з іншими і тому ваш сайт має бути серед перших у результатах пошуку в Google.

Якщо ваші конкуренти починають використовують нові технології, ви повинні адаптуватися, щоб не пасти задніх. Тепер створювати анімації не так просто, як це було з jQuery. А кращий рейтинг у Google є вагомим аргументом. Тому замість створення гарної анімації ви працюєте над тим, щоб швидкість сайту була кращою.

А ще Google оцінює багато показників на основі показників Google Web Vitals, тож окрім швидкості вам потрібно дбати про контент, що відображається на сторінці, та переконатись, що найважливіше справді відображається так, як ви очікували. Також необхідно стежити, щоб зміст не зсувався на сторінці, щоб забезпечити кращий UX. Цей список можна продовжувати ще довго. Наприклад:

• нам потрібно розуміти інструменти, які ми використовуємо (наприклад, пакувальники, такі як Webpack, які дозволяють нам аналізувати та оптимізувати розмір коду JS);
• методи оптимізації зображення;
• струшування дерева;
• техніки побудови.

Все це впливає на продуктивність, і добре, що існують такі фреймворки, як Next.JS, що роблять частину роботи, і завдяки яким нам не треба все запам’ятовувати.

Ми також повинні:

• писати застосунки частинами для можливості повторного використання;
• відстежувати шлях користувачів (ця інформація надзвичайно важлива для збільшення конверсії);
• обробляти переклади та форматувати числа (i18n і l10n);
• писати модульні та інтеграційні тести;
• займатись налаштуванням, бо наші вимоги не збігаються з тим, що підтримує фреймворк, який ми використовуємо;
• транспілювати код (оскільки навіть якщо ми уникаємо підтримки IE, під час спостереження за користувачами виявляється, що деякі з них використовують IE);
• створювати анімації;
• турбуватись про безпеку, доступність тощо.

Зараз можна кілька місяців не працювати з файлами CSS. Я навіть сумую за цим мемом:

Висновок

Якщо ви дочитали до цього моменту та все ще згодні з заголовком, я пропоную вам створити форму на чистому HTML, CSS і JavaScript, і зробити ту саму форму за допомогою фреймворку або бібліотеки JavaScript.

Зробіть їх високопродуктивними, а потім порівняйте весь шаблонний код, необхідний для виконання одного та іншого (і не хитруйте, не використовуйте інструменти CLI). Я майже впевнений, що ви усвідомите, як все змінилося. Для порівняння ви можете використовувати Lighthouse (це інструмент, доступний у інструментах Chrome dev).

Багато розробників, яких я знаю, кажуть, що проблема розробки фронтенду полягає в тому, що вона змінюється надто швидко.

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

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

Автор: Сержіо Вінісіус де Са Лусена

Текст адаптувала Євгенія Козловська