Прогресивне удосконалення порівняно з додатками на одній сторінці

Я щойно повернувся з конференції в Бостоні під назвою Event Event .

Дійсно популярною темою серед ораторів була ідея прогресивного вдосконалення - вміст сайту повинен містити HTML, а JavaScript слід використовувати лише для покращення поведінки.

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

Про це особливо проникливо розповів Джеремі Кіт .

А як щодо веб-додатків на одній сторінці, таких як "Backbone" та "Angular"? Весь дизайн, що стоїть за цими рамками, начебто підштовхує розробника до переміщення вмісту з HTML і до чогось на зразок JSON API.

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

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

Потім з’являються відвідувачі з відключеними сценаріями, але вони знають, у що вони потрапляють. Я не бачу, чому розробники повинні нахилятися назад для цих відвідувачів, окрім примітки "Вам потрібен сценарій для цього сайту". Якщо ми це дозволимо, то чому б також не задовольнити відвідувачів з відключеною CSS? Як щодо зображень відключених? Це основні веб-технології. Вони не повинні сподіватися, що вони матимуть повністю функціональний досвід в Інтернеті, коли збираються збирати та вибирати шматки.

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

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

Ідея прогресивного вдосконалення та SPA не є взаємовиключною для цих дурних односторінкових веб-сайтів додатків. Вам просто потрібен javascript для узгодження контенту (тобто заголовка Accept), щоб вони отримували ресурс JSON, що Javascript у SPA може виводити себе замість попередньо виведених сторінок HTML. Проблеми з подібними SPA-адресами веб-сайту очевидні, вам потрібно виконати повторне виконання візуалізації веб-сайту як на сервері, так і на клієнті.

Для справжніх веб-додатків, тобто таких, які справді повинні бути SPA, оскільки вони не вписуються в стандартний шаблон запиту / відповіді; прогресивне вдосконалення набагато складніше для справжніх додатків, оскільки вони справді просто використовують браузер як технологічну платформу для написання програми на портативному рівні. Мова сценаріїв - важлива частина справжнього веб-додатку, а не лише одна, яку можна додатково зафіксувати для вдосконалення. Деякі методи прогресивного вдосконалення все ще можуть працювати (наприклад, замінити флеш-відео / аудіо на <video>/ <audio>тег), але справжні веб-програми вимагатимуть JavaScript як базової лінії.

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

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

Ви робите веб-додаток з управління персоналом для конкретної компанії? Вам не потрібна витончена деградація, і SPA може бути простішим у створенні. Компанія може застосувати використання певного браузера, тому у вас може бути менше тестів.

Чи створюєте ви загальнодоступний веб-сайт для асоціації з вимогами доступності та потребами видимості пошукової системи? Потім розгляньте можливість побудови HTML на своєму сервері. Або зробити SPA із статичною версією, залежно від вашого бюджету.

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

Якщо ви використовуєте структуру SPA, я думаю, що дозволити Javascript - це дані. Однак Javascript, який ви пишете, щоб покращити свою сторінку, повинен бути достатньо розумним, щоб вирішувати будь-який HTML, який може створити рамка.

Ви також можете скористатись іншими методами PE, такими як використання останніх функцій CSS для недавнього випуску веб-переглядача або деградація HTML5 до HTML4.

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

• Толерантність до помилок у ситуаціях, коли HTML-файл завантажується повністю, але посилання на скрипти не вдається повністю завантажити завдяки мережевій підключеності, яка випадає та вимикається (можливо в мобільних мережах)
• Потенціал для покращення сприйнятої продуктивності при початковому завантаженні сторінки (за рахунок скорочення часу початку рендерингу)

Візуалізація на стороні сервера (це стосується користувачів, а не лише SEO-причин) та різання гірчиці - це дві методи, які допомагають будувати прогресивно розширені програми для однієї сторінки із сучасними рамками JS на стороні клієнта.

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

На момент написання, React.js та Ember (з майбутнім FastBoot) - це два, про які я знаю, які мають або намагаються зробити рендеринг на стороні сервера громадянином першого класу; сторінка, надана на сервері, як і раніше працює SPA, коли вона розбирається в браузері клієнта.

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

Я переконаний, що для цього потрібно дві речі:

1) налаштування всіх ваших посилань як стандартних посилань на запит / відповідь при початковому завантаженні, нехай ваша система / бібліотека SPA потім замінить їх оновленою (інтерактивною) версією, як тільки браузер завантажиться, а механізм JS виявить, що підтримка SPA доступна. Це справді є прогресивним посиленням; JS завантажується поверх існуючого веб-сайту html, і це краще для пошукових систем, допоміжних технологій та старих браузерів.

і

2) Сервер повинен реагувати на такі маршрути, як / foo / bar / json і foo / bar, обслуговуючи правильний формат; реалістично, якщо ви загортаєте все у макети та частки, щоб отримати першу сторінку, ви повинні мати можливість отримати все також за допомогою макетів та партій для другої та наступних сторінок.

Тут справедлива робота; правда, але якщо у вас є контроль над повним стеком, він збалансує дві технології.