Компромісні коди блядь
Наша робота передбачає арбітраж, що називається компромісом. Це питання визначення позитивних і негативних моментів рішення та оцінки балансу. Таким чином ми обираємо рішення, яке найкраще відповідає (принаймні на наш погляд) нашим потребам.
Однак у нашій галузі існує система догм. Ми більше не прагнемо поставити компроміси в перспективі і порівняти їх, а боротися зі "школами думок", кожна з яких розробила аксіоми (принцип не продемонстрований, а використаний як основа для міркувань).
Після чергових дебатів щодо сучасних технологій, що використовуються в інтерфейсі, спростованих захисниками деяких з цих аксіом, я спробую обґрунтувати наш підхід і пояснити його компроміси.
Ідея тут полягає в тому, щоб зробити зрозуміти чому ми використовуємо ці підходи та технології, в якому контексті, і нікому їх не нав'язувати. З невеликою удачею ця стаття змінить деякі виступи з "nimportawak (sic)" на "це не для мого типу проекту".
Спочатку Інтернет розроблений як комплект документів: кожна сторінка одна. З кожною навігацією ми запускаємо новий цикл життя сторінки: ми закінчуємо поточну сторінку, ініціалізуємо наступну.
Ця модель дуже проста і дозволяє дуже правильно використовувати переважно статичні сторінки.
У нас є сторінка, яка подається у форматі HTML, таблиця стилів, яка подається в CSS. І це все. Ми дізнаємось, що їх потрібно розділяти (в ім'я принципу поділу проблем, якщо такий зіпсується, потрібно запропонувати деградований досвід.
З роками вимоги користувачів стали вищими: на них потрібно було відповідати сторінками більш інтерактивний та техніки часткові перезавантаження сторінки (життєвий цикл сторінки досить дорогий). Тож ми почали додавати обмежений інтелект з невеликою кількістю JS, зокрема деякими інтерактивними цеглинками, завантажуємо кінець сторінки за допомогою AJAX.
Ці прийоми дозволили кардинально покращити досвід перегляду веб-сторінок користувачі: у нас менше даних для завантаження, ми відображаємо те, що люди хочуть бачити швидше (все одно буде трохи мляво завантажувати нову сторінку, як тільки ви збільшите масштаб на Картах Google). І воно тут перший компроміс:
- ми завантажуємо більше даних при початковому завантаженні сторінки (JS),
- Але це дозволяє нам завантажувати менше даних про послідовні завантаження.
Потім відбувається розповсюдження мобільних платформ. Щоб охопити користувачів, Інтернету вже немає THE платформа, але A платформа серед інших. Тоді компаніям стає стратегічно цікавим розпочинати розробку загальних баз у форміAPI, на які будуть підписані кілька клієнтів на різних платформах.
Тоді фронт-енд зазнав безпрецедентних змін: ми почали творити реальні додатки, більше немає документів, до яких випадково прищеплюються деякі функції. Потім ми набуваємо більш досконалі інструменти, засновані на шаблонах, вже перевірених в інших областях програмного забезпечення (наприклад, MVC). Пройшли часи файлу JS, який ініціалізує 3 плагіни jQuery для створення каруселей.
Тоді ми починаємо мислити категоріями погляди. Ми також отримуємо певну незалежність від задньої панелі, ми можемо генерувати наш інтерфейс безпосередньо з JS.
Нам більше не обов’язково вчитись, як працює внутрішній стек, його організація, мова шаблонів: ми стаємо майстрами своїх стеків.
Ми охоплюємо нові питання, такі як маршрутизація, отримання даних та створення інтелектуальних кеш-пам'яток клієнтів. Потім з’являються фреймворки, що пропонують рішення для них (Angular, Ember і Backbone, щоб назвати декілька).
Тоді React надходить із унікальним підходом до своїх конкурентів: компоненти. Ми створюємо по одному для кожного багаторазового блоку програми.
Компонент - це чорний ящик, який приймає параметри (пропси), може мати локальний стан і який описуватиме інтерфейс у будь-який момент часу.
React також поставляється з JSX, розширенням JS, яке дозволяє описувати його інтерфейс у формі, що нагадує HTML (XML), але без обмежень (таких як необхідність серіалізації атрибутів). Зберігаючи знайомство з HTML (і доречність такого синтаксису для представлення дерева елементів), JSX реагує на зростаюче розчарування "безлогічними" шаблонами, які змусили створювати допоміжні засоби та трансформувати дані вище за течією.
Повністю абстрагуючись від DOM і пропонуючи нам просту концептуальну модель ((props, state) => UI), React дає можливість створювати розширені інтерфейси, простіше і, перш за все, у ремонтопридатному способі: поведінка компонента, що є в поєднанні з його розміткою нам більше не потрібно переходити між файлом HTML та JS для їх синхронізації. Ізоляція компонентів допомагає запобігти небажаним крайовим ефектам.
Тому HTML та JS розміщені, їх редагування об'єднано. Сюрприз: ми зрозуміли, що це був більш продуктивний спосіб робити щось і що ми були менш схильні дозволяти старому коду гнити в нашому кутку.
Ця проблема залишається з CSS: все ще можна написати код CSS за допомогою небажаний вплив на компонент, відмінний від цільового. Існують війни за специфіку, візуальні регресії та відсутність видимості наслідків змін. Якщо ви успадковуєте код, який вам не відомий або більше не знайомий, файл ризик чогось зламати високий.
Прийомиутеплювач "ручні", такі як BEM, набирають популярності. Потім ми уникаємо езотеричних селекторів, і ми робимо це простим, використовуючи методологію розбиття, виконану паралельно з нашими компонентами (імена класів мого компонента Button мають префікс Button), що є більш ремонтопридатним. На розсуд розробників, ця методологія залишається предметом помилок, необхідно перевірити, чи не використовується та не порушує існуючий простір імен.
Потім приходять рішення, що автоматизують цю ізоляцію, делегуючи завдання машині, а не людині: модулі CSS та CSS-в-JS. За допомогою цих прийомів, помилка більше не може перевищувати обсяг її компонента. CSS, який не використовується на даному маршруті, ніколи не вводиться: мертвий CSS усувається за замовчуванням (практично неможлива проблема і, принаймні, не автоматизована, із традиційною таблицею стилів).
CSS-в-JS повернути стиль до компонента, за своїм обсягом. Тепер наш компонент містить свою розмітку, стиль та поведінку.
Вже було сказано, що такий підхід порушує розділення проблем, але це бачення виходить з постулату, що потрібно імперативно кодувати документи та забувати про компонентний підхід. Постулат, який ми забули переоцінити з точки зору розвитку, як це робиться. У контексті програми, розділення розмітки, стилю та поведінки зводиться до накладення непотрібного технологічного розділення, яке може в ім'я "належної практики" негативно вплинути на досвід розробників та користувачів.
Для цього вже немає жодної причини, крім "ностальгії за старими добрими часами", мова йде про рефлекси, придбані в той час, але ніколи не розглядаються в перспективі. Запитайте когось, чому це неправильно, вони скажуть "РОЗДІЛЕННЯ КОНЦЕРІВ!" Запитайте його, чому він навряд чи вийде з чимось відчутним.
Підхід CSS-in-JS не створює проблем, коли програма повністю управляється на стороні клієнта. Але це може дратувати програми, які відображаються на стороні сервера: CSS буде відсутній на початково завантаженій сторінці HTML, і у вас буде FOUC (Flash Of Unstyled Content). На щастя, переважна більшість рішень CSS-in-JS пропонують вилучення стилів під час візуалізації сервера. Він витягує критичні стилі зі сторінки та додає їх до візуалізації згенерованої програми. Ви завантажуєте менше CSS, і програма на стороні клієнта бере на себе завантаження та ін'єкцію правил за потреби.
Кожне рішення має свої компроміси. Візьміть у якості прикладів час завантаження різних підходів і запишіть їх буквами від A до F (A найшвидший, F найменший):
Кожне з цих рішень може відповідати вашим потребам. Документ надаватиме перевагу початковому завантаженню, а програма - навігації в ньому. Ніщо не є ідеальним, це (і, мабуть, буде ще довгий час) вирішення, який компроміс ви готові зробити.
Сьогодні ми пишемо додатки з технологією, що розвивається в повному обсязі, спочатку призначена лише для створення документів.
Ми виступаємо проти консерватизму деяких, хто відмовляється бачити модель "відверненою" від використання, як це планувалося 20 років тому. Але ми повинні нагадати їм, що ми хочемо зробити додатки корисними для наших користувачів, легшими, швидшими, які виходять за рамки, спочатку заплановані підходом до документів, і що ми хочемо мати можливість робити їх зараз, тому що нашим користувачам не надто турбуватися, оскільки функція повинна існувати у стандартах для розробників, щоб використовувати її. Якби Dulux Valentine продавав лише основні кольори, ви думали б кричати на людей, які роблять їх стіни зеленими, змішуючи жовтий і синій ?
Тож ми експериментуємо, ми перенаправляємо використання, ми створюємо речі, ми користуємось API, не призначеними спочатку для цього, ми постачаємо додатки, здатні робити те, чого ми не уявляли можливим в Інтернеті кілька років тому. Завдяки всім цим підходам і, знімаючи вагу застарілих правил, ми робимо це швидше, робимо це краще, робимо це більш чисто.
І знаєш що? Це не ламає мережу. Це не ламає ваші сторінки. Він не менш доступний. Він просто використовує стандартні веб-інструменти, які ми маємо, щоб зробити більше. І це також допомагає керівництву W3C, показуючи їм, що певні рішення використовуються для вирішення певних питань, які безпосередньо не вирішуються стандартами.
Вам особисто не потрібні ці підходи? Щойно ці потреби з’являться, ви дізнаєтесь, що вони існують, просто зрозумійте Чому їх встановлюють, які питання вони вирішують, які їх компроміси. Можливо, вони вам все ще не подобаються, але принаймні ви їх зрозуміли, і вони стануть додатковою альтернативою доленосному дню. Коли вам буде достатньо струн для лука, ви зможете грати на арфі.