Ванільна веб-дієта

Розгромна розсилка

Щотижня ми надсилаємо корисні інтерфейсні та UX-методи. Підпишіться та отримайте Контрольні списки розумного дизайну інтерфейсу PDF доставляється у вашу поштову скриньку.

дієта

Примітка редактора: Це вступна стаття про книжкова ідея опублікувати журнал Smashing Magazine разом із Крісом Хайльманом. Перевірте, що ми пропонуємо як ідею, - пояснивши спосіб переглянути спосіб побудови веб-сайтів, щоб переконатися, що вони є більш стрункими та надійними для майбутнього. В кінці статті ми попросимо вас заповнити коротке опитування, щоб продемонструвати свій інтерес.

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

Чому так? Хіба роки веб-розробки та пропаганди ефективності роботи Yahoo, Google та багатьох інших не мали плодів і дали нам зрозуміти, скільки коштує кожен запит HTTP? Якщо дивитись на кінцеву продукцію, то це не здається таким чином.

Причини для ожиріння

Є кілька причин, чому наш Інтернет знаходиться на пухкій стороні, і більшість із них насправді можна змінити нам як розробникам.

Ми не розвиваємося в реалістичних середовищах

Ймовірно, головна причина полягає в тому, що ми, як розробники, працюємо на швидких і великих комп'ютерах, підключених до жирової лінії, і вперше хтось тестує нашу продукцію на повільних з'єднаннях під час забезпечення якості (QA). І оскільки якісний контроль - це перше, що потрібно втратити, коли терміни не дотримуються, іноді цього взагалі ніколи не відбувається.

Вчепившись у минуле

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

Відмінності браузера

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

Охоплюючи хаос та відзначаючи відмінності

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

Мій браузер - це не світ?

У гіршому випадку ми намагаємось досягти цього, блокуючи всі браузери, які нам не подобаються, і з гордістю проголошуючи, що "всі користуються браузером X, а хто не - ворогом сучасної мережі". Це, звичайно, просто бреше нам самим і базується на швидкоплинній концепції "сучасної мережі". Багато найстрашніших веб-продуктів, що існували там, були побудовані роки тому, щоб працювати лише в Internet Explorer (IE) 6, який на той час був бджолиним коліном. Немає значення, в якому крутому обладнанні є гарячий провідний браузер, який зараз гарячий - ми знову робимо ту ж помилку, якщо створюємо лише один браузер, а інші блокуємо.

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

_Mozilla/5.0 (Macintosh; Intel Mac OS X 10_82) AppleWebKit/536.5 (KHTML, як Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5

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

Бібліотеки - це майбутнє

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

Вбудований резерв

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

Смерть тисячею плагінів

Зловживання абстракцією коду в ці часи поширюється. Ми використовуємо бібліотеки та конвертери, які дозволяють нам писати найменшу кількість коду, щоб досягти великої кількості. Це пов’язано з ціною. Три рядки, які ми пишемо абстрактною мовою, можуть перетворитися на десятки після перетворення на зрозумілий для браузера код. Дуже спокусливо використовувати 20 невеликих скриптів на наших сторінках, коли всі вони складають лише кілька рядків, але це становить масу HTTP-запитів та генерованого коду, який задихає браузер. Оскільки ми ніколи не бачимо цей код, це, здається, не є нашою помилкою - ми просто написали найменшу кількість коду. Безумовно, додавання ще одного сценарію з лише п’ятьма рядками коду не може змінити ситуацію?

Отже, тут нам слід почати більше думати про те, що ми робимо зараз. Ми стали залежними від абстракцій для найпростіших речей і дотримуємося культу додавання безлічі допоміжних інструментів, оскільки вони роблять речі набагато простішими і потрібні для того, щоб продукт міг підтримуватись і міг рости. Багато найкращих практик веб-розробки були знайдені та визначені великими компаніями, яким доводилося створювати продукти, що підтримуються в різних країнах та командах, і які повинні відповідати запитам мільйонів користувачів. Те, що є найкращою практикою для домашньої сторінки Yahoo або Gmail, не обов'язково повинно бути тим, що робить ваш менший продукт найбільш ефективним.

Джонатан Снук має чудовий приклад цього, коли розповідає про свій підхід SMACCS до написання CSS. Він зазначає, що майже кожен продукт починається з файлу reset.css, але після закінчення видалення цього файлу не виявляє ніякої різниці, оскільки для елементів, які ми використовуємо, ми визначаємо поля, відступи та розмір.

Ванільна дієта для Інтернету

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

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

Принципи ванільної веб-дієти:

Швидкий приклад: додавання відео на веб-сайт

Візьмемо простий приклад: додавання відео на сторінку. Наше мислення, обумовлене та обтяжене роками веб-розробки, може бути таким:

  • Відео HTML5 приємне, оскільки воно є рідним для браузера, елементи управління є легкодоступними, і я міг створити власні елементи керування за допомогою API JavaScript, що входить до нього.
  • Однак у попередніх версіях IE не відтворюється жодне відео HTML5, тому мені потрібно додати резервну копію Flash.
  • Крім того, не всі браузери підтримують MP4, тому мені потрібно мати відео у двох форматах, MP4 та WebM, а також OGV, якщо я хочу підтримувати ще старіші Firefox та Opera.

Маючи це на увазі, ми, мабуть, отримаємо відеопрогравач від GitHub і використаємо його. Відеоплеєр був би досить розумним, щоб розпізнати, що підтримує поточний браузер, і записати Flash-відео або власне відео. Це не допоможе з проблемою підтримки кодеків та браузера, якщо ми також не використовуємо програвач, який виявляє це і надсилає правильний формат, наприклад Vid.ly.

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

  • Якщо я працюю в старому браузері, чи хочу я завантажити бібліотеку JavaScript, щось виявити і отримати програвач Flash? Що робити, якщо у мене немає Flash? Я завантажив бібліотеку даремно, і досі не можу дістатися до відео взагалі.
  • Якщо я працюю в сучасному браузері, я завантажив бібліотеку, і якщо у мене увімкнено Flash, то я отримаю програвач Flash зі всім споживанням пам'яті та накладними витратами на ініціалізацію (надається, це не багато, але на моєму MacBook Air для Наприклад, вентилятор в основному запускається через Flash).

Ванільний дієтичний підхід до цього був би наступним:

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

Чи занадто багато роботи, щоб мати відео у двох форматах? Чудово, використовуйте один і перемістіть посилання з тегу відео - таким чином, ви пропонуєте можливість завантажити відео всім, хто має нестабільні зв’язки:

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

Інший приклад: розгортаються новини

Багато разів ми використовуємо бібліотеку JavaScript, щоб мати деякі заголовки, які при натисканні або перевертанні показують деякі абзаци під ними. jQuery’s show () і hide () призначені для цього, і існує безліч плагінів, які дають нам цю функціональність.

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

Тепер, щоб зробити їх згортанням і розширенням плавним способом, все, що нам потрібно зробити, це застосувати деякі CSS:

Тут ви можете побачити деякі принципи в дії. Старіші версії IE не розуміють максимальної висоти та непрозорості, тому вони ніколи не застосовуватимуть стилі, які приховують вміст. Значно більша максимальна висота станів наведення та фокусування гарантує, що браузер розширює вміст до кінця (він завжди буде переходити до реальної висоти, єдина проблема, яку ви матимете, коли вміст перевищує 200 пікселів, тому на це потрібно вказувати тому, хто підтримує код). Перехід однієї секунди гарантує, що браузер робить це плавно, а не просто показує вміст. Веб-переглядачі, які не підтримують переходи, все одно відображають і приховують вміст. Ви також можете додати переходи з префіксом браузера. Firefox та IE10 вже скинули префікс для переходів, і інші будуть слідувати.

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

Коли користувач натискає заголовок, ми хочемо додати клас show до розбірного елемента, а потім видалити його наступного разу, коли користувач клацне. Для цього нам потрібен лише один обробник подій у документі. Щоб видалити та додати клас, ми могли б змінити властивість className, але новіші браузери мають набагато гнучкішу реалізацію classList. Ми перевіряємо те, що ми використовуємо в операторі if, і в кінцевому підсумку отримуємо не так багато коду:

Старіші версії IE не розуміють addEventListener (), тому це не буде виконано, оскільки ми перевіряємо його наявність. Якщо classList підтримується, ми застосовуємо обробник клацань до документа. Потім ми перевіряємо і перемикаємо клас show, щоб викликати зміну CSS, використовуючи classList кожного разу, коли клацається елемент із активатором класу.

Зараз ось ідея: я планую написати про це книгу, видану разом із журналом Smashing Magazine. Я справді вірю, що можна багато сказати про речі в HTML5, які зараз нам дають браузери, і які дозволяють писати простий та ефективний код для випуску прагматичних продуктів, а не додавати багато коду, який нам просто не потрібен ми хочемо досягти.

Якщо вам цікаво, швидко заповніть опитування нижче або напишіть нам коментар, і ми продовжимо.