Складнощі формошльопства в 2023 році, або про не функціональні вимоги до сучасного фронт-енд застосунку [ukr]

Так, дякую. Так, шановні, всі поїли, всі готові до наступної доповіді. Прокидаємося, тому що, скажу вам чесно, доповідь має бути цікавою, але, можливо, трошечки, зовсім трошки складною. Отже, про мене. Звати мене Віталій Рубан, я працюю в компанії Iterа, комерційного досвіду десь рочків 9, плюс-мінус. З цікавого працював з AngularJS, з React, з Backbone, якщо хтось таке пам'ятає, з Knockout, ну, в общем, з дуже різними речами. І також трошки працював з .NET. От. Ще я автор YouTube-каналу React для початківців, можливо, хтось десь там мене навіть і бачив. Якщо ні, не страшно, нічого особливого ви не витратили.

І сьогодні я вам приніс таку цікаву тему, яка називається «Формошльопи». Підніміть, будь ласка, руки, хто образився на назву. І це неправильно. Знаєш чому? А тому що не треба ображатись, можна просто почекати спікера на перерві. Добре. От. Насправді, жарти жартами, але називати сучасний фронтенд формошльопством... Ні, це далеко неправильно. І зараз ми про це будемо говорити. Тому що сучасний фронтенд в 23-му році, ну і взагалі зараз у нас, він насправді досить складний і вимагає від нас і знань, і навичок. І для того, щоб це проілюструвати, я підготував вам декілька окремих тем, про які будемо сьогодні говорити. Ми поговоримо про багатоекранність. Найпростіший, напевно, виклик, який ми зустрічаємо на фронтені. Ми поговоримо з вами про багатобраузерність. Ми поговоримо з вами про доступність. До речі, хто знає, що таке доступність? От, зразу питаннячко. Ого! Це прям чудово. Ми поговоримо обов'язково про мою улюблену тему, це швидкодія. От. І, звичайно, ми з вами поговоримо ще про таку, на мою думку, найскладнішу річ на фронтенді, це безпека. Це безпека. І для того, щоб проілюструвати краще свою діяльність, я вам покажу, що це. В мої думки, я підготував вам декілька історій, кожна з яких присвячена окремій темі.

І перша моя історія, вона називається «Королівство тисячі екранів». Ця історія сталася безпосередньо зі мною. Навіть не зі мною, а з оцим моїм телефончиком. Телефон дуже простий, Sony Xperia XZ2. От. Нічого такого цікавого в нього немає, окрім того, що він там плюс-мінус новий, 20-й рік. 6,9 дюймів чи 5,8 дюймів екранчик. Але в нього тут розширення екрану 4К. Ну, так заявляє виробник. От. І у мене сталося такий цікавий момент. Мої колеги закинули мені посиланнячко на веб-застосунок, який вони робили. Ну, просто щоб я там подивився, як воно виглядає. Я був в дорозі, подивитися на ноутбуку, як я це завжди роблю, я не зміг. Відкрив в телефоні, і що я бачу? Я бачу, що верстка, яку вони зробили, вона поїхала. Ну, от реально, просто месиво на екрані. Ну, майже месиво, ладно. Але я точно знаю, що хлопці працювали так, як треба, дівчата. Тому що був дизайнер, були брікпоенти, був Mobile First. Ну, все зроблено по науці, все зроблено правильно. Але на моєму екрані чуш. Що трапилось? І з'ясовується. Що незважаючи на те, що в мене 4К екран, ля-ля-ля-ля-ля, в'юпорт 360 пікселів, все. І я став дивитися на цю тему. Мені стало цікаво. Ну, добре, в мене, напевно, просто старий телефон, 20-й рік, так? Але якщо подивитися таку штуку, як статистика по iPhone, ми бачимо, що все насправді тільки веселіше. Тому що виключно лише iPhone, тобто лише один виробник, просто iPhone, вони нам підігнали 10 різних в'юпортів. Ви вдумайтесь, лише в iPhone 10 різних в'юпортів. 8 з яких відрізняються по ширині. А окрім цього, вибачте. У нас ще є маки. В кого маки? Є маки, правильно. Є айпеди. І це ми зараз говоримо тільки про Apple. Ви подумайте. Є iWatch. Ви в курсі, що на iWatch можна подивитися веб-сторінку? Так, кривенько, але якось то можна. І ще є, ну, iBox, то понятно, що не то. Але під iBox-ами, під iBox-ами, я розумію всі інші пристрої, яких насправді дуже і дуже багато. Телевізори. Причому, як від старих моделей, так, вибачте, до 8К. Якісь LCD-панелі, які окремі, яких також ви взагалі не будете знати, що вони і які вони є. Але вони існують.

І, якщо знову ж таки говорити про розширення, давайте з вами спробуємо зіграти в одну маленьку гру. Подивіться, будь ласка, на цей слайд. На другому місці, за популярністю, у нас з вами розширення 19:20 на 10%. Це звичайний лептоп. Немає питань? Все логічно. На третьому місці у нас 360. Тобто, як виявляється, мій оцей телефончик, він такий популярний. І на четвертому місці 1366. Тепер питається в задачі. А що на першому місці? Ще варіанти? Ну що, дивимось. Unclassified. Ми не знаємо, що на першому місці. Немає цієї інформації. Подумайте про це. Ви деплоєте застосунок, який розкатується на мільярди людей, і ви не знаєте, на чому він буде відображений. Отже, екранів багато. А наші з вами здогадки, як ви тільки що побачили, хибні. Поїхали далі.

Друга історія. Вона називається маленьке віконечко жахів. Хтось здогадався, про що я зараз буду говорити? Гарна спроба, дякую. Ні. Так. Жартую. Будь ласка, підніміть руки, хто радіє ось цьому слайдові. Це добре. Я теж дуже радів. Я був щасливий, я святкував. Знаєте, в чому проблема? Не так сталося, як гадалося. Розказую ще одну історію. Жила-була веб-студія. До речі, оце вже випадок не в Україні, але реальний. Жила-була веб-студія. Їй замовили зробити застосунок. Вони його зробили, протестували, віддали замовнику. Замовник, о, молодці, все хорошо. Проходить тиждень, замовник повертається, каже, слушайте, хлопці, все так класно, все так хорошо. Є нюанс. Застосунок не працює. Все-таки, як не працює? Та там напис такий, your browser is not supported. Як? А що? З'ясовується, що замовник насправді був субпідрядником. А справжність? Служній замовник виставляв вимогу, що воно має працювати на інтернет-експлорері в 22-му році. Звичайно, про це ніхто не подумав, воно не працювало. Почали з'ясовувати, звідки в 22-му році міг взятися інтернет-експлорер як вимога. Знаєте, що з'ясувалося? Добре, з'ясувалася проста історія. Замовник, фінальний замовник цієї штуки, це була велика установа, у якої є певні вимоги. Вимоги до навчання. Відповідно, для того, щоб людей перевезти з експлорера на хром, треба провести навчання. Для цього потрібні гроші зусилля. Ніхто цього не бажав вкладатися, люди сиділи на інтернет-експлорері. Якщо хтось думає, що це така собі фейкова історія, дуже раджу почитати історію про, якщо не помиляюся, японську залізну дорогу. Там взагалі весело. Так от.

Зрозуміло, що ця історія з вами вже, скоріше за все, не повториться. Правда ж? 23-й рік, в 24-му, я дуже сподіваюся, ми взагалі цього не побачимо, чудо техніки. О, та в 25-му вона взагалі загниє десь. Правильно. Правильно. Правильно. На жаль, пальму інтернет-експлорера перебирає Safari. Подивіться, будь ласка, на цей чудовий графік. Цей графік демонструє кількість тестів, які падають в розрізі кожного браузера. Причому. Причому що? Що важливо, це тестування стабільної функціональності. Не експериментальної, а стабільної. Якщо подивитися на цей графік, можна побачити, що Safari впереді планети всієї. На 2500 впадаючих тестів. Але і це не була би проблема, якби не ставлення Safari. Так? Яке у нас там ставлення Safari? Ставлення Safari краще за все демонструє ось цей слайд. Існує відомий баг. Зараз я покажу. Існує відомий баг, точніше є функціональність, яка має працювати. Коли ви клікаєте на чекбокс або радік, він має отримати фокус. Має бути індикація фокусу. Це вимоги accessibility, це вимоги специфікації. В 2008 році цей баг завезли в Safari, відкрили в Safari. На що Safari сказав? Нє, фіксати не будемо. Чому? Як ви думаєте? Чому? Во!

А тому, що ми знаємо краще, нашим користувачам так зручніше, коли їх ткнули в специфікацію і спитали, ну подождіть, вибачте, а як же вимоги? Відповідь була абсолютно геніальна. Ви просто неправильно читаєте специфікацію. Все. І от це велетенська проблема. Саме відношення. Не те, що в нас там є якісь тести, які падають. Бог з ним. Їх би починили. Їх би виправили. Але от це ставлення, що ми ігноруємо вимоги специфікації, от це проблема. А якщо ми зараз з вами подумаємо, що у нас, вибачте, є не лише Safari, у нас є інші рушії, і вони мають свої власні проблеми, то викликів стає ще більше. Тому що браузерів багато, і вони роблять те, що вони хочуть.

Історія №3. Три кола ада. Хто знає, що таке ада? Так, раз, два, три. Перша програмістка, гарний варіант. Перед тим, як перейду на наступний слайд, розкажу маленьку предісторію. Моя компанія ITERA, норвежська компанія, ми історично працюємо на норвежський ринок, зрозуміло. І от Норвегія була одна, напевно, із перших країн, які сказали, що хлопці, ми вас дуже любимо, але публічні веб-сторінки мають бути доступними. Якщо вони недоступні, ми вас дуже любимо, але ви заплатите нам штраф. Нормальна історія, але Норвегія не дуже великий ринок. Нікого це особливо не торкнуло, Бог без ним. Але пройшов час, і до нас прийшла Америка. До нас прийшла Америка, яка сказала, тепер у нас власний Americans with Disabilities Act. Відповідно до якого, шановні, ви зобов'язані для усіх публічних та державних сайтів дотримуватися вимог доступності. Доступності WCAG за стандартом AA. Якщо ви цього не робите, 75 тисяч доларів за перше порушення. 150 тисяч доларів за друге порушення. І як вишенька на вашому торті, кожен штат має право додавати власні штрафи на свій розсуд. І Америка не була б Америкою, якби це не стало застосовувати на практиці. На сьогоднішній день вже були подані позови проти Amazon. Domino's Pizza, Nike та інших сайтів. Знову ж таки, можна поставити питання. Ну, слухай, ну то роби сайти доступними. В чому проблема, правда? Правда. Але є нюанс. WCAG стандарт, відповідно до якого ми маємо розробляти наші застосунки так, щоб вони були доступними.

По-перше, на мою особисту думку, не дуже зрозумілий. Чесно. Я витрачаю багато часу. Витрачав. Намагаючись розібратись, що саме конкретно від мене хоче цей проклятий WCAG. Це перше. Другий нюанс полягає в тому, що вимоги WCAG є прості. Достатньо прості. Ну, наприклад, всі ми знаємо цей класичний приклад. Всі зображення мають містити текстовий варіант. Для того, щоб якщо людина не може через певні вади побачити це зображення, вона могла їх хоча б почути. Додаємо Alt. Ми перемогли. Ура! Ми Accessibility. Супер.

Є менш прості. Наприклад, ваша веб-сторінка, веб-застосунок має бути доступний не лише за допомогою мишки, а й, наприклад, за допомогою клавіатури. Причому повністю доступний. Хтось перевіряв от ваші SPA-ки, ваші складні застосунки на клавіатуру? Одна, дві, три. Перевіряли. Дуже добре. Молодці. Але це, як виявляється, за статистикою роблять не те, що не кожен десятий, а навіть менше. А є взагалі веселі речі, з якими я особисто, наприклад, стикався. Скрінрідери знаєте, що таке? Знаєте. І от в мене був просто чудовий досвід, коли ми виправляли наш застосунок під наратор. Це скрінрідер для Windows. Після чого ламався скрінрідер під Mac. Ми виправляли скрінрідер під Mac, після чого ламався наратор. Обалдєнний експірієнс. І я з жахом думаю, а що було б, якби в нас був би ще й третій? Тоді просто простіше б було. Треба було би повіситись. Таким чином, доступність на сьогоднішній день для нас, по факту, обов'язкова. Інакше нас будуть просто штрафувати. А працювати з нею, на жаль, не настільки легко, як би нам хотілося.

Четверта історія. Називається 100-бальний шторм. Взагалі, я довгий час був на іншій стороні цієї історії. Але, ну, так сталося. Так от, колись дуже давно наші з вами веб-застосунки, веб-сторінки, не було застосунків, господи. Вони були маленькі. Контенту було мало. Джаваскрипту було мало. Зображення були малюсінькі. Ну, оптимізовані. Це зараз можна кинути 5 МБ, якось воно там загрузиться. І це тільки перше зображення. А раніше все було простіше. Відповідно, сторінки працювали так швидко, як вони могли. В тебе гарний нетворк? Воно працює гарно. В тебе поганий нетворк? Ну, ти будеш сидіти і чекати, поки воно порядочку, цей JPEG, чи що там, воно вантажиться. Пройшов час. Ми всі виросли. І хтось розумний з сфери e-commerce, тобто продажів онлайн, він подумав. Слухайте, а що буде, якщо ми з вами, наприклад, оптимізуємо нашу сторінку, і вона буде вантажитись трошки менше часу? Можливо, чисто теоретично, люди будуть менше чекати і будуть більше купувати. Як вам така думка? Можливо? Можливо.

Один з таких кейсів – це Trainline Великобританія. Продаж залізничних квітків. Які сказали, що, ви знаєте, хлопці, ми тут порахували, нам 0,3 секунди принесло 8 мільйонів фунтів стерлінгів. І всі такі – вау! А потім прийшов Walmart, який сказав, знаєте, хлопці, ми тут трошечки теж порахували, одна секунда – це 2% до конверсії. Враховуючи обсяги продажів Walmart, нам би з вами вистачило на те, щоб придбати HIMARS, власний, приватний. І тоді e-commerce почав задумуватись і казати, що, шановні, так давайте, давайте всі робіть, будь ласочка, швидкі застосунки, давайте. Це ж гроші, це ж добре, давайте. А як людина, яка не технічно може виміряти чи швидкий застосунок чи ні? Сидіти з телефончиком заміряти секунди? Ну, таке, таке.

І тут приходить в Google і кажуть, пожалуйста, пожалуйста. Lighthouse 100 балів. Все, в тебе 100 балів – ти молодець. В тебе 95 балів – ти такий собі молодець. В тебе 80 балів – ти взагалі не молодець, пішов отсюда. Гівноти, а не самурай. І тут розробники, які це почули, побачили, відчули. Відчувай, відчувай, хто знає. Вони відчули. Я не хочу казати, що позаду цієї фігури. Чому? Чому такий біль насправді? Тому що, по-перше, наші SPA-ки, Single Page Application, вони взагалі не дружать з Lighthouse. Lighthouse. Три з п'яти метрик Lighthouse орієнтовані на те, як швидко користувач побачить ваш контент. Три з п'яти. Ще одна метрика орієнтована на те, скільки часу буде зайнятий мейн-фред. В SPA ми всі чудово розуміємо, що нам спочатку треба завантажити бандл, потім його розпарсити, потім його виконати, потім відмалювати. Весь цей час ми ніфіга не бачимо. Lighthouse стає червоним. Так, звичайно, у нас є Next і інші такі міксовані варіанти, але чистий метрик Lighthouse. У SPA це взагалі не про Lighthouse.

Друге. Нестабільні, погано прогнозовані умови. Що мається на увазі? Сьогодні ваш замовник сидить в офісі і вибирає собі нову клавіатурочку. Завтра цей самий замовник їде до себе на дачу, і в нього замість Wi-Fi 3G. І там, і там має працювати добре. Але є нюанс. Більше того, дивіться, фізику, закони фізики також чомусь досі ніхто не зміг відмінити. У нас є таке поняття. Дорогі клетенці, якщо ваш веб-сервер знаходиться в Києві, а ваш замовник, вибачте, в Кеннеда, то в Кеннеда він отримає відповідь від серверу, як би ви не хотіли, через певний проміжок часу. І це взагалі не бореться, окрім як перенесенням. Але це не завжди можливо.

Далі. Це взагалі парадокс. Парадокс нашого улюбленого фронтенду. Кожна наша наступна фіча, так чи інакше, скоріше за все, сповільнює наш код. Просто тому, що ми даємо більше коду, його треба довше парсити, довше виконувати. Плюс залежність. Хто знає, що буде, якщо додати весь лодаж в застосунок одразу, то і знає, як це працює. Плюс. Ну, давайте чесно. Плюс. Залежність від бекенду. Ви, особисто, витратили величезну купу часу і вилизали ваш застосунок до близько.

Або запит в базу йде три секунди. За товаром. Все. Що б ви не робили, ви можете хоч битись головою об стіну, це нічого не змінить. Ви будете повільним. Просто тому, що не формошльопи, трошки не формошльопили. І зверху до цього у нас замовник, який каже, що? Правильно, я хочу 100 балів. І мене взагалі не гребе, що ти там мені розповідаєш і що там той чувак розповідав на сцені. Все чесно. Ні. Таким чином. Закони фізики, які ми не можемо обійти, плюс особливості фронтенду. Це ще один дуже суттєвий виклик, коли ми говоримо про сучасний фронтенд.

І тепер, напевно, найскладніша історія за сьогодні. І взагалі найскладніша історія, яка у нас є. Це на мою особисту думку. Історія №5. Небезпека – це безпека. Будемо говорити з вами про те, що взагалі у нас відбувається на фронтенді з точки зору безпеки. З точки зору сек'юріті. І почну я з демонстрації декількох дуже цікавих сторінок. Я думаю, вам сподобається. Знаєте такий магазин, як Макдональдс або кафе? Знаєте, так? Як ви думаєте, яка кількість відвідувачів відвідує сторінку Макдональдса на пошук закладів? Ну, в день. Ну, ладно, в тиждень. Ну, так. Мільйон. Хорошо. Помилився трошечки. Мільярд. Ні, ну не так багато. Шістдесят вісім. Мільйонів. Шістдесят вісім мільйонів свого часу відвідували ось цю сторінку, в якій була Reflected XSS.

Хто не знає, що таке Reflected XSS, це вразливість, яка виникає, коли ваша веб-сторінка отримує певні дані з URL, і цей URL містить якийсь код, який тоді виконується в імені цієї сторінки. Тобто ваш код, який ви впихнули в URL, виконується від імені самої сторінки. І ось це чудо техніки було знайдено для шістдесяти вісім мільйонів. Красиво. Правда, там був AngularJS. Хто зараз мені хоче сказати, що AngularJS це говно і в сучасності такого не буває? Ага, молодець. Просто що говно. Правильно. Я можу в цьому ключі згадати класну таку штуку.

Таку бібліотечку, дуже маленьку, і майже ніхто не користується з вас, я впевнений. Але згадаю, називається React DOM. Да, React DOM, шістнадцята версія, 16.0, 16.4. Не просто Reflected XSS, яка вважається плюс-мінус, що таке. Stored XSS, тобто зберігаєма XSS, яка з'являлася, коли ми працювали з Server-side-рендерингом. Можна знову ж таки сказати, та ладно, слухай, що то React, господи, то ж формашльопи якісь писали. Згоден. Взагалі не буду сперечатись. Два роки тому головна сторінка Google, головна сторінка Google примітивна Reflected XSS, яка чудово працювала. Питання є, а мають бути.

До всього цього зверху треба накрутити ще ось таку цікаву штучку. Окрім того, що в нас є проблеми з софтом, з нашими залежностями, з якимись, з фреймворками, з чимось іншим. У нас ще є варіація рушіїв, про що я вже згадував. У нас є не тільки Chrome з V8, у нас є Safari, у нас є Firefox. І всі вони мають індивідуальні, унікальні вразливості. Ось ця штука працювала тільки в Firefox. Але вона там працювала! Вона там працювала. І як ви розумієте, знайти ось цю штукенцю і пофіксити її дуже і дуже складно. А до всього цього зверху. У нас приходять отакі цікаві штуки. У нас приходить проблема з екосистемою в цілому. І не хотілося б мені говорити якихось дуже гучних слів, але на мою думку вона дуже близька до стану зламана байдизайн. Чому? Тому що, перше, false positives. Буквально живий приклад. Три дні тому у мене на почту падає лист від гітхаба. Ой, шановні, ми знайшли вразливість у вашому застосунку. Дивлюсь. Babel. Babel якийсь під пакет. І тут думаю, ну Babel. Що це таке Babel? Ну трансформація коду працює в білд тайм. Ну наче білд тайм не страшно. Ладно. Потім такий, стоп, почекай. Трансформація коду. Тобто він бере твій код, перетворює на інший код.

А може, це вразливість у момент перетворення? Можливо, він генерує для мене вразливий код? Так, коротше, я не хочу цим займатися. І це проблема. Ми не можемо нормально... Ні. ...правильно, зрозуміло, просто, чітко розуміти, ми маємо вразливість чи ми не маємо вразливість. Коли нам NPM каже, "шановний, у тебе 9 критичних", що це значить? Да хер його знає, що це значить. Друга проблема. Відсутність контролю за оновленнями. Підніміть руки, у кого є приватний артефакторій. Ну давайте. Раз, два, три, чотири. Сергію, я тобі не вірю. Це проблема, оскільки кожна собака може трошки модифікувати open source, яким ми всі користуємося, а більшість наших пакетів це open source. І ми можемо отримати дуже цікаві наслідки. Тому що коли ми робимо апдейт, наприклад, того самого React, або, вибачте, просто господа, create React App, React Script, то що він робить? Він оновлюється не лише сам. Він оновлює всі підзалежності. І підзалежності підзалежностей. Скажіть, будь ласка, хоч раз хтось відслідковував весь цей ланцюг? Одна людина, дві людини, ну, дві людини, три людини. Це вже непогано. Це насправді добре. Але ви подумайте про цю історію. Ми робимо апдейт і ми не знаємо, що туди прилетіло. Просто ми не знаємо. Єдиний вихід - чекати санітарний час. Тобто ми беремо і говоримо, все, пацани. Ми оновлюємося через рік. Просто через рік. Чому? Тому що ми сподіваємося, що за цей час, якщо є вразливості, вони будуть знайдені. Це вихід? Та це фіаско, а не вихід. Далі.

Відсутність розділення прав по пакетах. Теж цікава штука. Всі знають, що коли ви робите NPM install, то та залежність, яка встановлюється, може, наприклад, прочитати ваш диск або вийти в інтернет. Або прочитати ваш диск. І вийти в інтернет. І добре це на вашій локальній машині. Бог з ним. Там нічого немає. Але якщо на білдсервері? Це цікаво? Дуже цікаво. Але дуже сумно. До цього всього, знову ж таки, накручується останній пункт. Взагалі вишенька на торті. Self XSS і життєздатність. Натискайте F12. Вставте код, який вам відправив Вася, Петя, Саша, тому що це призведе до того, що ви отримаєте 100 доларів на телефонний рахунок. І аккаунт. Але у вас немає аккаунта. Боротися з цим неможливо. Що б ви не робили? Нічого. Єдиний вихід - спробувати блокувати F12, але і це не завжди працює. Повірте мені, хто хоче відкрити, відкриє. Ну, за 100 доларів я б теж відкрив, зрозуміло. А ще вище. У нас є розширення.

Знову ж таки, приклад з практики. У мене є дуже маленький блок. Він там входить в клуб 64 кб, якщо не помиляюсь. Суть в тому, що він мініатюрний, і в нього немає javascript зовсім. Ну от, мені не треба. І оскільки в мене його там немає, я вирішив, що я буду дуже винахідливий. Я використовую, є такий класний хедер, раджу подивитися, хто не знає. Content Security Policy. Це хедер, який встановлює дозволені джерела ресурсів. Ну, і ви можете сказати цій веб-сторінці, що ця веб-сторінка може використовувати javascript виключно з такого самого домену. Або виключно інлайновий javascript. Ну, взагалі, все, що ви придумаєте, майже все можна. Ну, я його виставив, звісно, в нано. Тобто ця сторінка не має права виконувати javascript взагалі. Все класно. Відкриваю свою сторінку, і мені приходить яке-то оновлення. Ой, оновлення. Chrome Extension. І що б ви думали? Правильно, javascript працює прекрасно від цього Chrome Extension. І виконується в контексті моєї сторінки. І з цим нічого не можна зробити. Ось така от історія. Таким чином, сторонній код, різноманіття браузерів і ручне втручання. Без нього немає. Це ще один цікавий і, на мою думку, дуже серйозний виклик у сучасному фронтенді. До всього цього. Ми ще з вами сьогодні не говорили і, можливо, навіть не встигнемо поговорити про прогресивні веб-застосунки і кишені.

І якщо мова йде про мікросервіси, на щастя, ми вже приблизно зрозуміли, коли їх потрібно використовувати, навіщо, які плюси та мінуси. Проте, зараз деякі люди намагаються впроваджувати мікрофронтенди просто через те, що це є у моді. Прошу вас, не робіть цього. І, знову ж таки, ми ще не говорили про роботу з часом. Таким чином, для тих, хто пише веб-застосунок, який повинен коректно працювати з декількома часовими зонами, особливо тим, хто перетинає ці тайм-зони, тепер, думаю, це стало більш зрозумілим. Для тих, хто не розуміє, є така чудова країна як Франція. Знаєте, чим вона особлива для нас? Там 12 часових поясів в межах однієї країни. Ви просто сідаєте на автобус, їдете з одного міста в інше, і ви можете перетнути два часових пояси. І весь цей час ваш веб-застосунок повинен працювати коректно і відображати правильний час.

Звісно, для всіх цих проблем ми маємо відповіді. Є гнучка верстка для різних екранів. Є інструменти для перевірки роботи веб-сторінок на різних браузерах. Ми можемо використовувати різні браузер-стеки для тестування. Є інструменти для перевірки доступності, які не просто вказують на проблему, але і показують, чому і як це виправити. Якщо ви ще не використовували Wave, раджу обов'язково спробувати. І це безкоштовно. Для оптимізації швидкодії також є інструменти, такі як Lighthouse від Google, WebPageTest, які дозволяють перевірити роботу веб-сторінок з різних точок світу.

Щодо безпеки, тут все трошки складніше. Є інструменти для аналізу залежностей, такі як npm audit, статичний аналіз коду (SAST) за допомогою SonarCube, і динамічний аналіз коду, який, на жаль, може бути дорогим. Якщо ви серйозно ставитеся до безпеки, обов'язково проводьте тест та інші заходи. Завершуючи, я хочу сказати, що я не намагаюся вас налякати чи показати, що фронтенд - це щось неймовірно важке. Просто хочу, щоб ви розуміли, що для успішної роботи у сучасному фронтенді потрібно багато знань і зусиль. Необхідно розуміти не лише як працює конкретний фреймворк, але і як узагальновано працює весь фронтенд. Від моменту написання коду до того моменту, коли користувач відкриває сторінку.

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