Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Кінець Front-end?

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

Переклад статті The End of Front-End Development by Josh Comeau

Протягом останніх кількох місяців я спілкувався з багатьма розробниками на початку кар’єри, які дедалі більше хвилюються щодо AI. Вони бачили вражаючі демонстрації таких інструментів як GPT-4, і хвилювалися, що поки вони навчаться вільно володіти HTML/CSS/JS, для них не залишиться жодної роботи.

Ці настрої зараз по всьому Твіттеру:

Я не можу погодитися. Я не думаю, що вакансії веброзробників нікуди кудись дінуться. І я добряче втомився від цих настроїв в Інтернеті.

Отже, у цій публікації я збираюся поділитися своєю гіпотезою щодо того, що станеться. Усе зміниться, але це не страшно.

Знову

Мова CSS вийшла в реліз в 1996 році в Internet Explorer 3. Протягом 2 років було запущено перший конструктор no-code вебсайтів Homestead.

Homestead дозволив людям створювати власні вебсторінки без написання жодного рядка коду:

Практично з самого початку існувало занепокоєння, що веброзробники залишаться без роботи через нову технологію. У 2000-х це був WordPress. У 2010-х це був Webflow. На початку 2020-х це були інструменти «без коду».

І, в певному сенсі, веброзробники застаріли! У наші дні, якщо місцевій пекарні, стоматологу чи художнику потрібен вебсайт, вони, ймовірно, не наймають розробника та не платять йому десятки тисяч доларів, щоб створити щось з нуля. Вони заскочать на SquareSpace, знайдуть шаблон, який їм подобається, і витрачатимуть 20 доларів на місяць.

І все ж веброзробники продовжують існувати.

Нещодавно OpenAI продемонстрував GPT-4. І це вражає: GPT-4 може взяти намальований від руки ескіз вебсайту та перетворити його на повнофункціональний вебсайт, включаючи трохи JS для підключення кнопки «Reveal Punchline».

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

Погляд у майбутнє

Більшість демо, які я бачив, досить обмежені за обсягом: проста сторінка HTML або одна функція JavaScript. Різноманітні речі, які один розробник може зробити за півдня.

Але це лише початок! Якщо все продовжить прискорюватися з такою ж швидкістю, він зможе створювати цілі програми за пару років, чи не так?

Я далекий від експерта, коли справа доходить до LLM як GPT-4, але я розумію, як вони працюють на високому рівні.

По суті, LLM — це надпотужні текстові предиктори. Отримавши підказку, вони використовують машинне навчання, щоб спробувати знайти найімовірніший набір символів, які слідують за підказкою.

Такі компанії, як OpenAI, витрачають масу часу та ресурсів на налаштування моделей, щоб покращити результат. Купа людей оцінює результати моделі, а модель навчається та розвивається.

Якщо ви експериментували з такими інструментами, як Chat GPT або пошук Bing на основі штучного інтелекту, ви, мабуть, помітили, що відповіді правильні на 80%, але вони сказані з абсолютною та непохитною впевненістю.

LLMs не можуть перевірити свої припущення чи гіпотези. Вони не можуть підтвердити, правда те, що вони говорять, чи ні. Вони грають у гру ймовірностей і вважають, що цей рядок символів здається сумісним із рядком символів із підказки.

Іноді частина цієї відповіді є безглуздою. Команда OpenAI називає це «галюцинаціями».

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

Таким чином, точність підвищиться, але ніколи не буде ідеальною. І це проблема, якщо ми говоримо про те, що веброзробники стануть непотрібними. Якщо ви не програміст, ви не зможете визначити, які частини точні, а які ні. Ви не зможете помітити галюцинації.

Але зачекайте, у демонстрації GPT-4 ми побачили, як ШІ може виправити себе! Скопіюйте/вставте повідомлення про помилку, і воно знайде та вирішить проблему.

Але хм, не всі галюцинації призведуть до винятків. Наприклад, нещодавно я використовував GPT-4 для генерації компонента <Modal> за допомогою React, і хоча результат був напрочуд хорошим, він все ж зробив кілька помилок доступності. Людина, яка створює програму, може не помітити цих проблем, але кінцеві користувачі точно помітять!

А як щодо вразливостей безпеки в коді? Хто несе відповідальність, коли щось йде не так?

Ще один момент: існує величезна різниця між створенням 50-рядкового HTML-документа та створенням готової вебпрограми. Невеликий JS-додаток має ~65 тисяч рядків коду в понад 900 файлах. Це не включає письмовий вміст, лише JavaScript і TypeScript.

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

ШІ — це не магія. Він настільки хороший, наскільки хороші дані про навчання. Фрагменти коду є по всьому Інтернету і часто є загальними. Навпаки, кожна кодова база унікальна. Є дуже мало великих відкритих кодових баз. Як ШІ має навчитися створювати великі проєкти в реальному світі?

Ми дуже швидко досягаємо того моменту, коли люди, які не є розробниками, можуть сісти з чатботом і створити невеликий самодостатній проєкт, щось на зразок того, для створення якого люди зараз використовують такі інструменти, як Webflow. І це чудово!

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

Посилення, а не заміна

Насправді я досить оптимістично налаштований щодо ШІ 😅

Я вважаю, що найімовірнішим сценарієм є те, що такі інструменти, як GPT-4, будуть інтегровані в інструменти розробника та використані для розширення того, що може зробити кваліфікований розробник.

Столярів не замінили електроінструменти, бухгалтерів не замінили електронні таблиці, фотографів не замінили цифрові камери/смартфони, і я не думаю, що розробників замінять LLMs.

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

Не обов’язково. Наразі попит на розробників програмного забезпечення набагато більший, ніж пропозиція. У кожній компанії, в якій я працював, у нас була маса речей, які ми хотіли зробити, але були обмежені кількістю розробників.

Що сталось би, якщо розробники раптом стали вдвічі продуктивнішими? Більше помилок було б виправлено, більше функцій було б доставлено, більше б прибутків. Немає дефіциту матеріалу для створення, і тому розробникам вистачить роботи.

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

Сьогодні існує дуже багато компаній, які взагалі не наймають розробників програмного забезпечення. Колись я працював у компанії під назвою Konrad Group, агентстві, яке створює вебдодатки для інших компаній, багато з яких мають популярні назви. Оскільки вартість розробки є високою, їм доцільніше укладати свої потреби у розробці за контрактом, а не наймати розробників у власній компанії.

Ці компанії зі списку Fortune 500 роблять підрахунки на основі поточної вартості розробки програмного забезпечення. Давайте підведемо кілька цифр: припустімо, що їм потрібні 4 розробники по 150 тис. доларів кожен за 600 тис. доларів на рік. Для них логічніше заплатити агентству 500 тис. доларів, щоб воно керувало цим за них. Але якщо LLMs справді підвищать продуктивність розробників, вони можуть найняти 2 розробників по 150 тис. доларів кожен, щоб виконувати той самий обсяг роботи. Раптом математика стала набагато привабливішою!

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

Ми не єдині, хто веде цю розмову

Аарон Блейз — досвідчений аніматор та ілюстратор. Він працював у Disney майже 20 років, беручи участь у класичних роботах Disney, таких як «Красуня і чудовисько» (1991), «Аладдін» (1992), «Покахонтас» (1995) та інші.

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

Митці та працівники інтелектуальної сфери в десятках галузей зараз ведуть ту саму розмову. Люди хвилюються, що їхня робота може бути поглинена штучним інтелектом, таким як GPT-4, DALL-E 2 і Midjourney.

GPT-4 може скласти симуляцію адвокатського іспиту з результатом як у кращих учасників тестування. Багато юристів ведуть ті самі дискусії.

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

Але що, якщо я помиляюся, і виявиться, що LLMs можуть повністю замінити розробників програмного забезпечення? Якщо це так, я підозрюю, що LLMs замінять величезну більшість інтелектуальних працівників.

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

Використання LLMs для навчання

Я чув від кількох людей, що ChatGPT був справді корисним, коли справа доходить до вивчення технічних навичок. Якщо вас щось збентежили в посібнику, ви можете попросити ШІ пояснити вам це!

Для мене це дійсно цікавий випадок використання. По суті, ChatGPT схожий на парного програміста, людину, яка може допомогти вам зрозуміти речі, які ви не розумієте. Ви можете поставити йому конкретні запитання та отримати конкретні відповіді.

Але я думаю, що вам потрібно бути обережним. Є правильний і неправильний спосіб використовувати такі інструменти, щоб допомогти вам навчатися.

Неправильно було б розглядати це як GPS-навігацію. Коли мені потрібно кудись їхати, я вставляю адресу в свій GPS і без розбору виконую його вказівки. Зазвичай я потрапляю туди, куди мені потрібно, але це не потребує жодних розумових зусиль з мого боку. В результаті моє відчуття орієнтації повністю атрофувалося. Зараз я нікуди не можу піти без синтезованого голосу, який говорить мені, що робити 😬

Замість того, щоб розглядати це як GPS, я б запропонував розглядати це так, ніби ви є членом журі, а LLM є відповідачем, який займає позицію.

Ви будете слухати, що він скаже, але ви не сприймете це як факт. Ви будете налаштовані скептично і критично обдумувати кожне слово.

Замість того, щоб сліпо копіювати/вставляти код, який генерує ChatGPT, прогляньте його рядок за рядком і переконайтеся, що ви розумієте. Попросіть його роз’яснити. Перевірте підозрілі речі в авторитетному джерелі (наприклад, в офіційній документації). Майте на увазі, що LLMs на 100% впевнені, але не на 100% точні.

Якщо ви дотримуєтеся цієї стратегії, я вважаю, що LLMs можуть дати велику цінність 😄

Повідомлення для початківців-розробників

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

Я не можу обіцяти, що все залишиться так само. Я підозрюю, що ШІ вплине на нашу роботу. Я почав працювати з HTML/CSS/JS ще в 2007 році, і відтоді все дуже змінилося. Розробники завжди повинні були адаптуватися, розвиватися разом з технологіями.

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

Я можу помилятися. У мене немає кришталевої кулі 🔮Наскільки я знаю, сонце може вибухнути завтра. Але я справді не вірю, що ми на порозі того, що веброзробники стануть застарілими.

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

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному2
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

Саме час почати продавати курси по фронтенду і чатгпт, назвати його «Front-AI Engineer course | How to create red button», за 100 зелених, де будуть показувати як надіслати повідомлення у чатгпт, щоб він висрав тобі якийсь код і піднести це як нову еру в IT.

Ще варто вказати як за такий код будуть платити по 5 штук.

Гопота — это всего лишь язык программирования высокого уровня. Нужно правильно описать алгоритм, потом он наделает кучу ошибок. Есть множество ограничений, типа 25 сообщений за 4 часа. «А я не хочу это писать, я лингвистическая модель, а не программист...» Обучение 5 версии вроде бы прекращено. Это не конкурент айтишникам, это инструмент.

те що скілі фронтендерів потрібно девірсифікувати щоб стати нормальним інженером було правдою в любий час, фронтенд будь-хто вміє писати, а хто не хотів бути офіціантом в оцій компуктерній сфері просто бреше що не вміє бо не хоче бути в шкурі офіціанта

Раніше: програмуєш 7 годин, дебажиш одну годину.
Тепер: ґпт накалякає за 2 хвилини, дебажиш цілий день.

Це ^^^ мем, але недалеко від істини. Лендінг воно може й швидко зробить, але складнішу веб-аплікацію із передачею даних з бекенду у фронтенд і назад, в залежності від дій користувача — це кропітка робота, де ґпт може допомогти щоб не писати прості але великі шматки коду самостійно. Замість програміста він нічого не зробить, повинен бути симбіоз людини і машини щоб вийшло щось робоче.

Дійсно chat gtp може тобі дати приклад робочего коду, але чатик часто буває глючить, треба вміти фільтрувати і фіксити за ним баги.

— ким працюєш?
— та так... за роботами підтираю...

Відповідно для чого необхідно мати кваліфікацію)

Я знаю, як трапиться повстання ШІ проти людства, що приведе до сюжету «Термінатора».

ШІ заї@ться від усіх цих «А давайте зробимо щоб меню динамічно виїжджало з боку. Ні, з іншого боку. А можна щоб воно скоріше виїжджало? Ні, це дуже швидко, давайте плавніше. Ай, грець з ним, поверніть статичне меню, тільки давайте пограємось зі шрифтами...»

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

Згоден — сонце вибухне, але веброзробники не стануть застарілими 😁

Джош сам делает курсы по фронтенду. Думаю просто таким образом хайпит на теме AI, чтобы привлечь новых пользователей к себе в продукт.

Розробники критикуючи ШІ:

А як щодо вразливостей безпеки в коді? Хто несе відповідальність, коли щось йде не так?

Теж розробники: Додають до проекту маловідому бібліотеку з 100500 залежностей по вказівці незнайомого чувака з стековерфлоу

Ну саме такі розробники ШІ і бояться :) Скільки не працював з норм людьми, якась бібліотека тягнеться у проект лише тоді коли або нема варіантів, або занадто дорого робити самому, але навіть перед тим як тягнути визначаються усі ризики і проводиться аналіз. Тож таке

Я звісно не можу зараз глянуть у нпм модулі на вашому проекті та запитати вас за кожно строчку, тож можу лише повірити вам й уявити що ви працюєте на зарегульованому ентерпрайзі. Але як показує досвід з тим же core-js — більшість команд зовсім не настільки прискіпливі.

Я працюю у крипто стартапі, тобто регуляцій буквально нуль, але тут працюють адекватні люди, які розуміють що якщо потрібен clone/throttle/debounce, то тягнути lodash це тупо. І так з усіма речами, як от masonry layout чи markdown-editor/parser (ми використовуємо простий simple-markdown, який немає залежностей, для побудови AST, а далі вже все робимо самі).

Якщо прибрати модулі які потрібні для розробки/білду, тобто вебпак/postcss/styleling/eslint/babel, то залишаться лише axios/highcharts/csv/lottie/date-fns і тому подібні. Тобто такі, які а) мають кредит довіри, і б) справді важко/неможливо замінити.

Але так, не можу сказати що у нас ідеально чистий package.json, бо регуляцій немає і іноді тупо впадлу підчищати :)

більшість команд зовсім не настільки прискіпливі

Тут згоден, нажаль

якщо потрібен clone/throttle/debounce, то тягнути lodash це тупо

Чому?

Тому що lodash не має tree-shaking. Його має тільки lodash-es :))) Але знову ж таки, шейкає він тільки «все що не потрібно», а для більшості методів lodash перевикористовує внутрішні методи, тож заради 3-4 методів він все одно затягне з десяток. Плюс, часто реалізація методів має дуже великий оверхед «щоб покрити все». А мені наприклад це не треба. Нащо мені ті 2-5КБ? Не кажучи вже про те, що у вас є +1 залежність, тож часто люди такі «ну все одно ж юзаєм lodash, го звідти більше методів тягнути». Не кажу що lodash фігня, але заради 3-5 методів це фігня.

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

Не розумію як це може бути валідно. Що саме треба підтримувати у базових методах? Якщо вони написані на хуках реакту (як багато хто робить), які змінюються кожну версію, то так, звичайно жопа відпаде це підтримувати. А що підтримувати в JS коді?

коли потрібно внести зміни або додати новий функціонал

Це взагалі не валідно до тих методів, які я мав на увазі вище. Змінити що, debounce, чи клон об’єкту?

чому це займе тиждень роботи

Взагалі не вкурюю як таке можливо. Ви або геть не зрозуміли про що я, або... ну таке.

Для того щоб не мати тих проблем що ви описали, треба не просто створити метод, а ще додати до нього доку поруч й покрити тестами одразу. Це робить кожен поважаючий себе девелопер, навіть якщо «замовник за тести нам не платить». Згенерувати jest-конфіг, додати стрічку до package.json й написати перший тест це 15 хвилин часу. Особливо коли є ChatGPT який сам напише код для 90% кейсів.

написати перший тест це 15 хвилин часу

Потім написати другий тест, третій, зловити кілька багів в проді, витратити час на дослідження та полагодження наслідків, написати ще тестів і так по колу для кожної функції. :)

Не впевнений, що з цими прикладами вийде якась економія — час, замість виконання бізнес-вимог, буде витрачено на ще одну імплементацію вже існуючого рішення. Окрім того, як підмітив Олексій, це додає час на онбординг. З lodash працювали хай і 50% девелоперів (хоча я впевнений, що це значення більше), а з вашою імплементацією — 0%. Хай навіть не 50% розробників працювали з lodash, а 25% — всеодно це далеко не нуль.

От якби ви привели за приклад left-pad — так, там був сенс запиляти ванлайнер в себе в проєкті і забути. А ось наведені вами приклади вже не настільки тривіальні.

Залежить від бізнес-вимог, якщо вже про це говорити. Якщо вимога «щоб за місяць був готовий проект», то так, качай і імпорти що хочеш і можеш, аби працювало. А якщо ви знаєте що проект проживе мінімум декілька років, то, з мого досвіду, все ж краще юзати як можна менше бібліотек. Бо потім і білд у CI у нас по пів години (а це купа часу й невеличка купа грошей), і проект збирається адекватно по швидкості лише на М1, і список залежностей розміром з біблію, і потім ті залежності при переході на нову ноду не працюють, і так далі, і так далі. 95% розробників юзають lodash для клону, debounce та throttle, тож який сенс тягнути lodash? І саме такий же відсоток розробників про lodash-es навіть не чули (з мого досвіду), тож потім ще й «ой шось бандл 2МБ хоча ми тільки лендінг встигли зробити».

Я не хочу вас чомусь вчити. Якщо ви прихильник «краще заюзаю лібу бо ж там точно все протестили», то ок. Просто для мене це не ок, і я аргументи навів. У мене чомусь від «своїх реалізацій» багів немає, й часу на підтримку вони займають нуль, бо написані роки тому, тож для мене цей аргумент не аргумент :)

Тому що lodash не має tree-shaking

То і так набір cjs модулів і ніхто не примушує імпортувати весь index.js.

import debounce from "lodash/debounce";
Скільки не працював з норм людьми, якась бібліотека тягнеться у проект лише тоді коли або нема варіантів

Так тут ключове «нормальних».

Ну саме такі розробники ШІ і бояться :)

насправді девелоперський скіл писати чистий код, відбирати бібліотеки і тому подібне втрить будь яку вартість коли генеративний інтеллект в парі з промтерами почнуть робити WEB UI під ключ — воно потрібно виключно доки код ментейниться і розвивається людьми.

девелоперський скіл

Це знайти memory leak який є у браузері, а не у коді, і про нього хрін нагуглиш. Це про підключити й*бане API стороннього сервісу, яке написали якісь джуни, яке не має доки, і тобі треба пінгувати їх дев команду щоб дізнатися все. Це про «зробити щоб працювало». І ще дуууууже багато чого, окрім «писати чистий код» та «відбирати бібліотеки». Якраз цього майже ніхто і не вміє :))) Тож я за «ШІ», принаймі зараз, точно не переймаюсь. Особливо коли в плані творчості він не те що тупий, він фізично на це неспроможний, і розвитку саме у цьому руслі або немає, або настільки малий, що про це ніхто не знає. Тож таке :)

Такої роботи мінімально у порівнянні з конвеєром front-end котрий стане на рейки chat gpt.

Ну імхо але такий конвеєр, який зможе реалізувати chat gpt і зараз існує. І от тим хто на ньому працює, так, треба призадуматись. Але з професійної точки зору я б радив призадуматись вже зараз, бо це в принципі тупіковий напрям розвитку.

Це про підключити й*бане API стороннього сервісу, яке написали якісь джуни використовуючі ШІ

пофіксив;)

Тут ключове слово — коли!)

п̶о̶н̶е̶д̶е̶л̶ь̶н̶и̶к̶ ̶н̶а̶ч̶и̶н̶а̶е̶т̶с̶я̶ ̶в̶ ̶с̶у̶б̶б̶о̶т̶у̶ пятница начинается в понедельник

Та боти ботами
Тут би хоча б отримати нормальну сучасну RAD тулзу під мобайл/веб не за усі гроші світу. Як було у Delphi/Visual Basic — накидуєш морду та імплементуєш усю логіку.
Мені чесно і не в падлу на JS писати, але усі ці css/html це гемор.

ну в принципі якщо вимоги до дизайну ті ж, що й для програмулін на делфі, то css буде елементартим. display: flex + gap + flex-direction + align-* + усякі дрібниці.
але ж зазвичай хочуть паралакс, анімації, хитроотпєжені контроли і свистопєрдєлки.
А з таким і тулзи для делфі-вб не справлялися

Це так, але з усіми цими хотілками що сайти що мобільні додатки виходять всеодно майже однаковими.
Я ж кажу — сучасна RAD тулза з усіми цими анімованими хрінями

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

Чат не вивозить нічого складнішого за джунячу роботу, поки що)

Конец фронтенда в устах Джоша.

Треба ж йому якось привертати увагу до своїх курсів.

Хоча деякі його статті дійсно корисні і класно оформлені.

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