СУЧАСНІ ЗАСОБИ РОЗРОБКИ ІНТЕРНЕТ-САЙТІВ І WEB-ДОДАТКІВ
Крупіна Тетяна Олександрівна 1 , Щербакова Світлана Михайлівна 1
1 Московський педагогічний державний університет, магістрант
Анотація
Ця стаття присвячена огляду сучасних засобіврозробки Інтернет-сайтів та Web-додатків. Також розглядаються проблеми навчання студентів та школярів цим технологіям.
MODERN DEVELOPMENT TOOLS ONLINE SITES AND WEB-APPLICATIONS
Krupina Tatiana Aleksandrovna 1 , Шчербакова Светлана Михайловна 1
1 Moscow State Pedagogical University, Graduate of the Department of Applied Mathematics and IT
Abstract
Ця стаття дає змогу розробити сучасні веб-сайти і Web-based applications. Це також обговорює проблему тренування школярів і вистави цих технологій.
Інформатизація сучасного суспільствапов'язана з впровадженням засобів та методів інформаційних та комунікаційних технологій(ІКТ) у різні галузі людської діяльності. Особлива рольу цьому процесі, безперечно, належить розвитку мережевих технологійта комунікацій, яка, в тому числі, проявляється у створенні корпоративних автоматизованих інформаційних систем та мережевих проектів електронної комерції. Дійсно, діяльність будь-якого сучасного підприємства, так чи інакше, пов'язана зі створенням та веденням корпоративного інтернет-сайту.
Сучасні Федеральні державні освітні стандарти (ФГОС) за багатьма не тільки інженерними, а й гуманітарними напрямами вимагають від випускників умінь з розробки та управління Інтернет-сайтами.
Методи та засоби розробки Інтернет-сайтів та Web-додатків розвиваються динамічно від можливостей створення простих сайтів-візиток до розробки серверних додатків, що обробляють та зберігають великі масиви даних.
Для розробки нескладного сайту, у тому числі сайту-візитки з описом та контактними даними, можна скористатися різними способами:
- створення HTML документа, тобто. за допомогою редактора «Блокнот» набрати код на мові HTMLв ручному режиміта реалізувати його за допомогою браузера на клієнтському робочому місці, а згодом опублікувати у провайдера, скориставшись його послугами хостингу;
- створення того ж HTML документа, за допомогою редактора Adobe Dreamweaver, користуючись великим набором функцій та зручностей;
- скористатися готовими сайтами-оболонками для розробки Web-сайтів різних тематичних напрямків та дизайну та опублікувати сайт в інтернеті, скориставшись послугами безкоштовного або платного хостингу.
На відміну від розробки простих і не інтерактивних сайтів, для розробки Web-додатків, які запускаються та виконують обробку даних на сервері, необхідні методи та засоби, що доповнюють зазначені в попередньому абзаці. Розробка Web-програм пов'язана крім створення HTML-коду з програмуванням спеціальною мовою. Для розробки Web-додатків використовується мова програмування PHP, а також не обійтися без, наприклад, локального сервера Apache та баз даних MySQL.
Розглянемо ще засоби програмування Web-додатків:
- мова програмування JavaScriptвикористовується створення інтерактивних HTML документів;
- VBScript використовується для написання сценаріїв клієнта та для написання сценаріїв на сервері;
- Perl використовується для розробки інструментів системного адміністрування, а також у розробці CGI-сценаріїв, систем автоматичної обробки електронної пошти та підтримки вузлів Web.
Для самостійної розробки Web-додатків можна скористатися ресурсом Denwer, що вільно розповсюджується.
Denwer (від скор. ДНВР - джентльменський набір Web-розробника) - набір дистрибутивів та програмна оболонка, які призначені для створення та налагодження Web-додатків та іншого динамічного вмісту Web-сторінок на ПК під керуванням ОС.
До складу набору Denwer входять:
- локальний сервер Apacheдля запуску програм на комп'ютері користувача, імітуючи функціональні можливостісервера, де у провайдера згодом буде встановлено розроблений додаток. Apache – це програмне забезпечення – кросплатформне, що вільно розповсюджується та підтримує різними операційними системами;
- система програмування PHP – Cі-подібна мова для розробки програмних кодів, що вбудовуються в HTML-код сайту та виконуються на сервері, з метою обробки даних, що надходять від користувачів того чи іншого сайту. PHP (Hypertext Preprocessor – «Препроцесор гіпертексту», спочатку Personal Home Page Tools – «Інструменти для створення персональних веб-сторінок») – скриптова мова загального призначення, застосовуваний розробки Web-додатків, створили Расмусом Лердорфом 1994 року;
- MySQL – програмне забезпечення, що вільно розповсюджується для обробки баз даних, у тому числі використовується при роботі з даними, що надходять з клієнтських браузерів. MySQL (Structured Query Language – « Структурована мовазапитів») був створений Майклом Віденіусом з шведської компанії TcX у 1995 році.
Комплект програм Denwerабо його компоненти окремо широко використовуються як любителями, так і професіоналами для створення та налагодження Web-додатків та сайтів. Цей набір також широко використовується в освітніх цілях для навчання Web-програмування школярів та студентів.
Програми веб-дизайну змінили спосіб, яким дизайнери займалися розробкою сайтів протягом тривалого часу. Використання сучасних інструментів робить речі набагато простіше та швидше, наприклад, якщо ви використовуєте програми з авто-завершенням та макроси. Сьогодні дизайнери, які вважають за краще створювати дизайн зоровим способом, можуть використовувати деякі з цих додатків, щоб робити проекти, здатні перетворюватися на код, який потім буде закріплений онлайн.
Факт у тому, що більшість платформ веб-розробки у ці дні значно полегшує спеціалістам процес розробки своїх веб-сайтів. Наприклад, якщо ви знаходитесь поза зоною Інтернет-з'єднання, і хочете продовжити займатися вашим проектом, такі програми дуже допоможуть з цим.
Існує велика кількість відмінних додатківдля веб-розробки, і ось деякі з найкращих, можливість використання яких ви можете розглянути.
Ця програма, яка може допомогти вам створювати свої власні професійні стандартні сайти за кілька хвилин. Це найкращий додаток, які ви повинні розглянути, якщо ви шукаєте інструмент для веб-розробки, який буде робити за вас все, особливо якщо ви є користувачем Windows. Є дві версії - безкоштовна та розширена ( платна версія), але обидві вони однаково вражають. Додаток поєднує WYSIWYG дизайн і кодування, надаючи вам інструмент, який не тільки працює дуже швидко, але також дуже легкий в освоєнні. У безкоштовній версії можуть бути відсутні функції, які є в платній версії, але це все одно дивовижний додаток, що заслуговує на вашу увагу.
Це найкращий додаток для використання, чуйні сайти, які також будуть виглядати естетично-приємним, як на простих комп'ютерах, так і на мобільних пристроях. З Mobirise створення сайтів може бути дуже веселим. Інструмент поставляється з різними блоками, які веб-розробники можуть вибирати та перетягувати туди, де вони хотіли б їх розмістити, а потім змінювати налаштування за умовчанням для того, щоб врахувати свої вимоги.
Це універсальний текстовий редактор, що поставляється з безліччю дивовижних інструментів для веб-розробників. Він може бути не найкращий, але, однозначно, він добрий. Це інтерфейс Windows, який пропонує відмінний редактор програмування, що включає шаблони найбільш поширених мов програмування, таких як HTML, VBScript, FTP-клієнт, PHP.
Дуже чуйна програма для веб-розробки, яку ви просто зобов'язані розглянути, як один із інструментів для своїх проектів. Є безкоштовна версіяз обмеженням у функціях, які ви можете використовувати, та платна версія, де вам пропонується повний функціонал, який ви можете використовувати у своїй веб-розробці. TOWeb - дуже простий у використанні додаток, що містить дивовижні шаблони, які можуть бути налаштовані на вашу думку. Як і попередній інструмент, TOWeb підтримує багато мов програмування.
Це найкраща програма, яку ви можете використовувати, якщо хочете створити приголомшливі анімації для ваших сайтів. Найчастіше вона використовується дизайнерами, що займаються безпосередньо анімацією та рекламою, тому якщо ви є тим самим дизайнером, який створює анімовані елементи для використання в інших програмах, які можуть бути доступні на всіх платформах, тоді це додаток те, що вам потрібно. Існує ряд компонентів, які вам, напевно, сподобаються в цій програмі, включаючи інтеграцію з Google Drive, заходи, 3D-об'єкти, шари та інше.
Дуже простий редактор «drag-and-drop», який найкраще підходить для новачків, які розробляють свої перші сайти. Ця програма поставляється з безкоштовним хостингом та необмеженою кількістю сторінок, серед усіх інших чудових особливостей. Якщо ви хочете створити фантастичний сайт, не витрачаючи занадто багато часу для його створення, то ця програма буде дуже доречною.
Відмінна програма, якою ви можете почати користуватися прямо зараз. Інструмент заснований на Firefox, і пропонує сучасний підхіддля створення чудових веб-сайтів. Він має визначні характеристики, і хоча для використання більшості з них потрібна покупка ліцензії, є і ті, які вам пропонуються безкоштовно, щоправда, обмежені по можливості використання.
Це веб-додаток, який відмінно підходить для веб-розробки, однак, через його складність, він не зовсім підходить новачкам. Тим не менш, незважаючи на те, що інструмент не такий простий у використанні, він дає величезні можливості тим, хто вже має деякий досвід роботи в веб-розробці.
Текстовий редактор, який призначений лише для найрозвиненіших веб-розробників. Той факт, що це інструмент, заснований на тексті, робить його не зовсім придатним для новачків, але якщо у вас є трохи досвіду в кодуванні, то це програма, яку варто розглянути для проектів з веб-розробки. Воно маленьке та легке, ви навіть можете носити його на флешці. SynWrite - це повнофункціональний інструмент з можливістю запису макросів, історією буфера обміну, плагінами, купою допомоги в кодуванні, анонсами та палітрами. Він також дозволяє розробникам здійснювати пошук та заміну серед множини файлів, а також шаблонів коду. Мабуть, це найкраща програма, яка буде використовуватися протягом усього проекту – від створення макета до написання коду.
Це стильна програма веб-розробки, яка може допомогти вам створити блискучі, естетично приємні сайти. Онлайн-додаток, який пропонує великі можливості, якщо ви платите за них, тобто ви можете очікувати трохи більше функцій, якщо готові розлучитися з кількома зайвими доларами Існує також безкоштовна версія, але вона не має так багато особливостей як платна версія.
Додатки веб-розробки призначені для того, щоб зробити вашу роботу легше, надаючи деякі функції та інструменти, яких ви потребуватимете як розробник. Ваш вибір повинен залежати від функцій, які ви шукаєте, та типу веб-сайту, який ви хотіли б створити.
Що таке розробка веб-застосунків?
Розробка веб-додатків - це загальний термін для створення веб-сторінок або сайтів. Веб-сторінки створюються з використанням HTML, CSS та JavaScript. Ці сторінки можуть містити простий текст і графіку, нагадуючи статичний документ. Сторінки також можуть бути інтерактивними або відображати змінну інформацію. Створювати інтерактивні сторінки трохи складніше, але вони дозволяють створювати веб-сайти з багатим вмістом. Сьогодні більшість сторінок інтерактивні та надають сучасні інтерактивні послуги, такі як кошики інтернет-магазинів, динамічна візуалізація та навіть складні соціальні мережі.
Розробка програм для сучасних комп'ютерів здійснюється за допомогою спеціалізованих мов програмування. Дані вступні матеріали допоможуть вам познайомитися з ними.
Відео | 15 хвилин | Мови програмування
У цій доповіді йдеться про те, навіщо потрібні мови програмування, які вони бувають, для яких цілей призначені. Також коротко згадуються мови розмітки (HTML), подання даних (XML) та запитів (SQL).
Відео | 23 хвилини | Мови програмування
У цій доповіді дається короткий оглядмови програмування C#, його основних особливостей та конструкцій, демонструються приклади створення найпростіших консольних та віконних програм для Windows у Visual Studio 2010.
Ознайомтеся з багатими можливостями операційної системи Windows, які можна і потрібно використовувати для розробки веб-додатків.
| 4 | засоби розробки |
Відео | 10 хвилин | WebMatrix
Коротка розповідь про WebMatrix – середовище для розробки веб-сайтів. WebMatrix дозволяє створювати сайти різної складності: від домашньої сторінки до невеликого корпоративного порталу. Середовище включає набір шаблонів заготовок сайтів, які можуть бути взяті за основу створення власного сайту. WebMatrix дозволяє створювати та редагувати розмітку та код сайтів, а також керувати базами даних та публікувати готові сайти на хостинг.
Відео | 11 хвилин | Internet Explorer
У цій доповіді наведено короткий огляд технології Pinned Sites ("Прикріплені сайти"), що з'явилася в Internet Explorer 9. Демонструється робота з Jump Lists, Overlay Icons і Thumbnail Toolbar Buttons.
Наведені нижче ресурси допоможуть вам отримати додаткові вміння і навички в області, що вас цікавить.
У зв'язку із цим питання – що ще потрібно знати?Якщо я правильно розумію, Angular, Vue та інші фреймворки - це тільки фронтенд.
Куди не сунься, скрізь про веб-розробку говориться, як про створення саме фронтенда, а також це обов'язково пов'язано з Node.js (щоб щось написати на ангулярі, без нього ніяк). Яким боком пов'язаний фронтенд із Node.js - я не розумію, т.к. Node.js – це, по суті, спосіб запустити JS поза браузером.
Швидше за все ви читаєте статті про фронтенд, тому в них про бекенд нічого і немає. Як ви знаєте фронтенд пишеться на JS і багато хто підкуповує те, що можна підняти NodeJS на бекенді і використовуючи одну мову створювати сайти.Якщо я хочу запустити додаток у браузері, то навіщо мені node? Це все мене вводить у ступор, я бачу лише протиріччя.
Ви не плутайте. Існують технології, які використовуються в процесі роботи програми і є технології, які використовуються в процесі розробки програми. Усі ці Gulp, Grunt, Babel, Webpack та інші – це інструменти розробки. Вони прискорюють, полегшують, підвищують якість роботи. У той час jQuery, Angular, React - це бібліотеки та фреймворки, за допомогою яких програма буде працювати.
Якщо раніше сайти створювали з використанням пари технологій, то сучасні програми можуть використовувати десятки, а то й сотні останніх. При чому це можуть бути різні мови програмування, бібліотеки, фреймворки, послуги тощо. Все це часто називають "зоопарком" технологій.
Тут я лише можу припустити, що сервер замість HTML повинен обмінюватися даними з додатком за допомогою json або чогось ще.Так, JSON, як найпоширеніший. Вам потрібний фреймворк для бекенда, на якому можна розгорнути REST API. Наскільки мені відомо більшість сучасних фреймворів сучасних мов програмування, які використовуються для веб-розробки, це вміють. Я не можу стверджувати точно, я працюю в рамках однієї мови. Все-таки сервер – це основа будь-якої мережевого додатка, і в першу чергу, потрібно розробити серверну частину.
Однозначно. Сучасні односторінкові програми (SPA) складаються з двох роздільних частин - фронтенду та бекенду. Вони можуть створюватися повністю окремо різними розробниками, головне узгодити формат передачі та всі нюанси.
Вся краса SPA у розподілі цих частин. Будь-яка з них може бути замінена на іншу без особливих наслідків. Один бекенд може обслуговувати сайти, мобільні додатки, надавати доступ до даних для сторонніх партнерських додатківі все це через єдиний API.
Що ще потрібно вивчити? Чи перелічених знань достатньо?Не думаю, що достатньо. Ви точно визначите завдання, які має вирішувати ваш проект та під них підбирайте технології. Вам потрібно зупинитися на чомусь одному, ви не зможете вивчити все сучасне, не вистачить часу. Чи не можна використовувати Node.js і, відповідно, npm, якщо JS (TS) потрібен тільки в браузері? При цьому тестування також необхідне.
Так, цілком. На стороні клієнта, наприклад, JS+Angular. А на боці бекенда, наприклад, PHP+Laravel. Зараз дуже багато мов та ще більше фреймворків під них. Вибирайте те, що вам простіше.
Нещодавно, в основному, у зв'язку з UX та продуктивністю.
Я хочу представити 7 дієвих принципів для веб-сайтів, які хочуть застосувати JavaScript для керування UI. Ці принципи є результатом моєї роботи як веб-дизайнера, а також як давнього користувача WWW.
JavaScript безперечно став незамінним інструментомдля розробників фронтенду. Наразі сфера його застосування розширюється на інші області, такі як сервери та мікроконтролери. Цю мову програмування обрали престижні університети, щоб навчати студентів основ інформатики.
У той же час існує низка питань щодо його ролі та конкретного використання, на які багато хто не може відповісти, у тому числі автори фреймворків та бібліотек.
- Чи має JavaScript використовуватися як заміна функцій браузера: історія, навігація, рендеринг?
- Чи вмирає бекенд? Чи потрібно взагалі рендерувати HTML?
- Чи правда, що майбутнє за додатками на одній сторінці (Single Page Applications, SPA)?
- Чи має JS генерувати сторінки на веб-сайті та рендерувати сторінки у веб-додатках?
- Чи потрібно використовувати техніки на кшталт PJAX чи TurboLinks?
- Яка точна відмінність між веб-сайтом та веб-додатком? Чи має залишитися щось одне?
Далі будуть мої спроби відповісти на ці запитання. Я спробував дослідити використання JavaScript з точки зору користувача (UX). Зокрема, приділив особливу увагуідеї мінімізації часу, який потрібно користувачеві для отримання даних, що його цікавлять. Починаючи з основ мережевих технологій і закінчуючи прогнозом майбутнього поведінки користувача.
1. Рендеринг сторінок на сервері необов'язковийtl;DR: рендеринг на сервері здійснюється не заради SEO, а для продуктивності. Приймайте до уваги додаткові запити для отримання скриптів, стилів та наступні запити до API. У майбутньому, беріть до уваги використання методу HTTP 2.0 Push.
Насамперед, я змушений звернути увагу на загальноприйняту помилку розділяти «додатки з рендерингом на сервері» та «односторінкові додатки». Якщо ми хочемо домогтися найкращого сприйняття з погляду користувача, то повинні обмежувати себе такими рамками і відмовлятися від однієї альтернативи на користь інший.
Причини цілком очевидні. Сторінки передаються по інтернету, який має фізичні обмеження, що незабутньо проілюстрував Стюарт Чешир у знаменитому есе «Це latency, дурник».
Відстань між Стенфордом та Бостоном 4320 км.
Швидкість світла у вакуумі 300 x 10^6 м/с.
Швидкість світла в оптоволокні становить приблизно 66% швидкості світла у вакуумі.
Швидкість світла у оптоволокні 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Одностороння затримка при передачі Бостон 4320 км / 200 x 10^6 м/c = 21,6 м/c.
Затримка під час передачі туди і назад 43,2 м/c.
Пінг зі Стенфорда до Бостона в інтернеті сучасного зразка близько 85 мс (…)
Отже, сучасне обладнанняІнтернету передає сигнал зі швидкістю 0,5 від швидкості світла.
Зазначений результат 85 мс можна поліпшити (і вже зараз він трохи кращий), але важливо зрозуміти, що існує фізичне обмеження на затримку під час передачі інформації через інтернет, як би не збільшувалася смуга пропускання на комп'ютерах користувачів.
Це особливо важливо у зв'язку зі зростанням популярності JavaScript-додатків, які зазвичай містять лише розмітку та поруч із порожнім полем. Так звані односторінкові програми (Single Page Applications, SPA) - сервер повертає одну сторінку, а все інше викликається кодом на стороні клієнта.
Уявіть сценарій, коли користувач безпосередньо заходить на http://app.com/orders/ . До моменту, коли ваш додаток отримує та обробляє цей запит, у нього вже є важлива інформаціяпро те, що потрібно показувати на сторінці. Воно може, наприклад, підвантажити замовлення з бази даних і додати його у відповідь. А ось більшість SPA у такій ситуації повертає порожню сторінку та тег. Потім доведеться знову обмінятися запитами для отримання вмісту скрипту, і ще раз - для отримання контенту.
Аналіз HTML, який надсилається сервером для кожної сторінки SPA
Багато розробників свідомо йдуть на таку жертву. Вони намагаються гарантувати, що додаткові мережеві хопидля користувача відбудуться лише один раз, відправляючи правильні заголовкидля кешування у відповідях зі скриптами та CSS. Загальна думка полягає в тому, що це прийнятна угода, тому що після завантаження всіх файлів на комп'ютер більшість дій користувача (як переходи в інші розділи) здійснюються без запитів додаткових сторінок або скриптів.
Однак, навіть з урахуванням кешу, є певний програш у продуктивності, якщо врахувати час на парсинг та виконання скрипту. У статті «jQuery надто великий для мобільного телефону?» говориться, як тільки jQuery може гальмувати деякі мобільні браузерина сотні мілісекунд.
Що ще гірше, зазвичай користувач не отримує жодного фідбека в той час як завантажуються скрипти. Результат - чиста сторінкана екрані, яка потім раптово перетворюється на повністю завантажену сторінку.
Найголовніше, ми зазвичай забуваємо, що найпоширеніший транспорт для передачі інтернет-даних (TCP) стартує повільно. Це майже напевно гарантує, що більшість комплектів зі скриптами не буде передано за один раз, роблячи вищеописану ситуацію ще гірше.
TCP-з'єднання починається з обміну пакетами для рукостискання. Якщо ви використовуєте SSL, що важливо для безпечної передачіскриптів, відбувається два додаткові обміни пакетами (один, якщо клієнт відновлює сесію). Тільки після цього сервер може розпочати відправлення даних, але практика показує, що він робить це повільно та порційно.
Механізм контролю заторів під назвою Slow Start вбудований у протокол TCP, щоб надсилати дані, поступово нарощуючи кількість сегментів. Це має два серйозні висновки для SPA:
1. Великі скрипти завантажуються набагато довше, ніж здається. Як пояснюється в книзі "High Performance Browser Networking" Іллі Григорика, потрібно «чотири обміни пакетами (…) та сотні мілісекунд затримки, щоб вийти на 64 КБ обміну даними між клієнтом та сервером». Наприклад, у разі швидкого інтернет-з'єднання між Лондоном і Нью-Йорком потрібно 225 мс, перш ніж TCP зможе вийти на максимальний розмір пакета.
2. Оскільки це правило діє також для початкового завантаження сторінки, дуже важливо, який контент вантажиться для рендерингу на сторінці в першу чергу. Як робить висновок Пол Іріш у своїй презентації «Доставка товарів», критично важливі перші 14 КБ. Це зрозуміло, якщо подивитися на графік із зазначенням обсягів передачі між клієнтом та сервером на перших етапах встановлення з'єднання.
Скільки КБ сервер може відправити на кожному етапі з'єднання, за сегментами
Веб-сайти, яким вдається доставити контент (нехай навіть базову розмітку без даних) у цьому вікні, видаються винятково чуйними. Насправді багато авторів швидких серверних додатків сприймають JavaScript як щось непотрібне або що потрібно використовувати з великою обережністю. Таке ставлення ще більше посилюється, якщо програма має швидкі бекенд і базу даних, а його сервери знаходяться біля користувачів (CDN).
Роль сервера у прискоренні представлення контенту залежить від веб-програми. Рішення не завжди зводиться до «рендерінг цілих сторінок на сервері».
У деяких випадках, неактуальну в Наразідля користувача частину сторінки краще виключити з початкової відповіді та залишити на потім. Деякі програми, наприклад, вважають за краще здійснити рендеринг лише «ядра» сторінки для забезпечення негайного відгуку. Потім вони вимагають різні частини сторінки паралельно. Це забезпечує кращу чуйністьнавіть у ситуації з повільним застарілим бекендом. Для деяких сторінок гарним варіантомбуде рендеринг лише видимої частини сторінки.
Винятково важлива якісна оцінкаскриптів та стилів з урахуванням інформації, яка у сервера є про сесію, клієнта та URL. Скрипти, які здійснюють сортування замовлень, очевидно будуть важливішими для /orders, ніж логіка сторінки налаштувань. Можливо, не настільки очевидна, але є різниця у завантаженні. структурного CSS» та «CSS для оформлення». Перший може знадобитися для коду JavaScript, тому потрібно блокування, а другий завантажується асинхронно.
Хороший приклад SPA, яке не призводить до зайвого обміну пакетами, - концептуальний клон StackOverflow в 4096 байтах, він теоретично може завантажуватися з першим пакетом після рукостискання на TCP-з'єднанні! Автор примудрився досягти такого за рахунок відмови від кешування, використовуючи inline для всіх ресурсів у відповіді з сервера. Застосувавши SPDY або HTTP/2 server push , теоретично можна передати весь кешований клієнтський код за один хоп. Ну а в даний час рендеринг частин або всієї сторінки на стороні сервера залишається найпопулярнішим способом позбутися зайвих раундів обміну пакетами.
Proof-of-concept SPA з використанням inline для CSS та JS, щоб позбутися зайвих roundtrip'ів
Досить гнучка система, яка розділяє рендеринг між браузером та сервером і надає інструменти для поступового завантаження скриптів та стилів, цілком може стерти межу між веб-сайтамиі веб-додатками. І те, й інше використовує URL'и, навігацію, демонструє дані користувачеві. Навіть додаток з електронними таблицями, що традиційно покладається на функціональність з клієнтської сторони, спочатку має показати клієнту інформацію, яку потрібно редагувати. І зробити це за найменшу кількість roundtrip'ів важливо.
На мій погляд, найбільший недолік продуктивності у багатьох популярних системаху наш час пояснюється прогресивним накопиченням складності у стеку. Згодом додавалися технології на кшталт JavaScript та CSS. Їхня популярність теж поступово зростала. Тільки зараз ми можемо оцінити, як їх можна використати інакше. Йдеться і про покращення протоколів (це показує нинішній прогрес SPDY і QUIC), але найбільшу вигоду несе все-таки оптимізація додатків.
Корисно буде згадати деякі історичні дискусії навколо ранніх дизайнів версій HTMLта WWW. Наприклад, цей список розсилки від 1997 пропонує додати тег у HTML. Марк Андрессен повторює, наскільки важливо швидко доставляти інформацію:
«Якщо документ потрібно складати в єдине ціле на льоту, то це може бути як завгодно складним, і навіть якщо складність обмежити, у нас все одно виникнуть великі проблемиз продуктивністю через структуризацію документів у такий спосіб. Насамперед, це одразу порушує принцип одного хопу в WWW (ну, IMG теж його порушує, але з дуже специфічної причини та в дуже обмеженому сенсі) – чи впевнені ми, що хочемо цього?»
2. Негайна відповідь на дії користувачаtl;DR: JavaScript дозволяє взагалі сховати мережну затримку. Використовуючи це як принцип дизайну, ми можемо навіть прибрати з програми майже всі індикатори завантаження та повідомлення “loading”. PJAX або TurboLinks втрачають можливості збільшення суб'єктивної швидкості інтерфейсу.
Наше завдання полягає у максимальному прискоренні реакції на дії користувача. Скільки б зусиль ми не вкладали у зменшення кількості хопів під час роботи з веб-додатком, але є речі поза нашим контролем. Це теоретична межа швидкості світла та мінімальний пінг між клієнтом та сервером.
Важливий фактор – непередбачувана якість зв'язку між клієнтом та сервером. Якщо якість зв'язку погана, буде відбуватися повторна передача пакетів. Там, де контент має завантажуватись за пару roundtrip'ів, може знадобитися набагато більше.
У цьому головна перевага JavaScript для покращення UX. Якщо на клієнтській стороні інтерфейс керується за допомогою скриптів, ми можемо сховати затримку мережі. Ми можемо створити враження високої швидкості. Ми можемо штучно досягти нульової затримки.
Припустимо знову, що перед нами звичайний HTML. Документи поєднуються гіперпосиланнями або тегами . Якщо натиснути на будь-який з них, то браузер здійснить мережний запит, що займає непередбачувано довгий час, потім отримує та обробляє отримані дані і нарешті переходить у новий стан.
JavaScript дозволяє реагувати негайно та оптимістично на дії користувача. Натискання на посилання або кнопку призводить до негайної реакції без звернення до мережі. Відомий приклад – це інтерфейс Gmail (або Google Inbox), в якому архівація поштового повідомлення відбувається негайно, тоді як відповідний запит до сервера надсилається та обробляється асинхронно.
У разі форми, замість очікування якогось коду HTML як відповідь її заповнення, ми можемо реагувати відразу, як користувач натиснув “Enter”. Або навіть краще, як шукає Google, ми можемо реагувати ще раніше, готуючи розмітку для нової сторінки заздалегідь.
Така поведінка – приклад того, що я називаю адаптацією розмітки. Основна ідея полягає в тому, що сторінка «знає» свою майбутню розмітку, тому може переключитися на неї тоді, коли ще немає даних для вказівки на це. Це «оптимістична» поведінка, тому що залишається ризик, що дані ніколи не надійдуть, і доведеться виводити повідомлення про помилку, але це, очевидно, трапляється рідко.
Головна сторінка Google цілком підходить як приклад, тому що вона дуже чітко демонструє перші два принципи нашої статті.
Наприкінці 2004 року компанія Google стала піонером у використанні JavaScript для видачі підказок у реальному часі в процесі набору пошукового запиту (цікаво, що цю функцію співробітник розробив у вільні від основної роботи 20% часу, так само як і Gmail). Це навіть стало фундаментом для появи Ajax:
Подивіться на Google Suggest. Спостерігайте, як оновлюються пошукові терміни в міру набору тексту практично миттєво… без затримки на перезавантаження сторінки. Google Suggest та Google Maps – це два приклади нового підходу до створення веб-додатків, які ми в Adaptive Path назвали “Ajax”
Іншим типом дій, крім кліків та відправлення форм, які відмінно покращуються з допомогою JavaScript, є рендеринг завантаження файлу.
Ми можемо зареєструвати спробу користувача завантажити файл у різний спосіб: drag-n-drop, вставка з буфера, вибір файлу. Потім, завдяки новим HTML5 APIs, ми можемо відобразити контент, начебто він уже завантажений. Приклад такого роду інтерфейсу - наша робота із завантаженнями у Cloudup. Зверніть увагу, як мініатюра зображення генерується та рендерується миттєво:
Зображення рендерується та відображається до закінчення завантаження
У всіх цих випадках ми покращуємо сприйняття швидкості. На щастя, є багато доказів корисності такого підходу. Взяти хоча б приклад, як збільшеннявідстані до багажного конвеєра в аеропорту Х'юстон зменшилокількість скарг на втрачений багаж без необхідності прискорювати обробку багажу.
Ця ідея має серйозно вплинути на UI наших програм. Я вважаю, що індикатори завантаження мають стати рідкістю, особливо якщо ми переходимо на програми з інформацією в реальному часі, що описуються в наступному розділі.
Є ситуації, коли ілюзія миттєвого впливу насправді надає шкідливий ефект на UX. Це може бути форма платежу або закінчення сесії на сайті. Застосовуючи тут оптимістичний підхід, фактично обманюючи користувача, ми ризикуємо викликати в нього роздратування.
Але навіть у цих випадках слід припинити відображення на екрані спіннерів або індикаторів завантаження. Їх потрібно відображати тільки після того, як користувач вважає відгук не миттєвим. Відповідно до часто цитованих досліджень Nielsen :
Базова рада за часом відгуку залишається незмінною вже тридцять років Miller 1968; Card та ін. 1991:
* 0,1 секунд є лімітом, щоб користувач сприймав відгук як негайний, тут не потрібно відображення ніякої додаткової інформаціїкрім результату операції.
* 1,0 секунд є лімітом на безперервність потоку думки у користувача, навіть хоча він помітить затримку. Зазвичай, не потрібно додаткової індикації при затримці більше 0,1 секунди, але менше 1,0 секунди, але у користувача зникає відчуття прямої роботи з даними.
* 10 секунд є лімітом утримання уваги користувача на діалозі. При більшій затримці користувачі захочуть виконати інше завдання, очікуючи на відгук від комп'ютера.
Техніки на кшталт PJAX або TurboLinks, на жаль, упускають більшість можливостей, описаних у даному розділі. Код на стороні клієнта не «знає» про майбутній стан сторінки доти, доки не відбудеться обмін даними з сервером.
3. Реакція зміну данихtl;DR : Коли на сервері оновлюються дані, клієнту слід повідомляти без затримки. Це така форма підвищення продуктивності, коли користувача звільняють від необхідності здійснювати додаткові дії(натискати F5, оновлювати сторінку). Нові проблеми: керування (повторним) з'єднанням, відновлення стану.
Третій принцип відноситься до реагування UI на зміну даних у джерелі, як правило, в одному або кількох серверах баз даних.
Відходить у минуле модель передачі по HTML даних, які залишаються статичними, поки користувач не оновить сторінку (традиційні веб-сайти) або не взаємодіє з нею (Ajax).
Ваш UI повинен оновлюватися автоматично.
Це критично важливо у світі з наростаючим потоком інформації з різних джерел, включаючи годинник, телефони, планшети та пристрої, що носяться, які з'являться в майбутньому.
Представте стрічку новин Facebook відразу після її появи, коли інформацію публікували, в основному, з персональних комп'ютерівкористувачів. Статичний рендеринг не можна було назвати оптимальним, але він мав сенс для людей, які оновлювали стрічку, скажімо, щодня.
Зараз ми живемо у світі, коли ти завантажуєш фотографію – і майже негайно отримуєш лайки та коментарі від друзів та знайомих. Необхідність у миттєвому відгуку стала природною необхідністю конкурентному оточенні інших додатків.
Було б невірним, однак, припустити, що переваги миттєвого оновлення UI обмежуються тільки розрахованими на багато користувачів додатками. Ось чому я люблю говорити про узгоджених дата-поінтахзамість користувачів. Візьмемо типовий сценарій синхронізації фотографії між телефоном та вашим власним ноутбуком:
Однокористувацький додаток теж може отримати користь від «реактивності»
Корисно представляти всюінформацію, яка надсилається користувачеві як «реактивну». Синхронізація сесії та стану авторизації – один із прикладів універсального підходу. Якщо у користувачів програми одночасно відкрито кілька вкладок, то закінчення робочої сесіїоднією з них має відразу деактивувати авторизацію усім інших. Це неминуче веде до покращення безпеки та кращий захистконфіденційної інформації, особливо в ситуаціях, коли кілька людей мають доступ до одного пристрою.
Кожна сторінка реагує на стан сесії та статус авторизації
Як тільки ви встановили правило, що інформація на екрані оновлюється автоматично, важливо працювати над новим завданням: відновлення стану.
При надсиланні запитів та отриманні атомарних оновлень легко забути, що ваша програма повинна нормально оновлюватись навіть після тривалої відсутності зв'язку. Уявіть, що ви закриваєте кришку ноутбука та відкриваєте її за кілька днів. Як поводитиметься додаток?
Приклад того, що відбувається у випадку некоректного оновленнязв'язку
Здатність програми нормально відновлювати зв'язок взаємодіє з принципом № 1. Якщо ви вибрали надсилати дані при першому завантаженні сторінки, ви повинні враховувати і час, який минув перед завантаженням скриптів. Це час, по суті, еквівалентно часу дисконнекту, тому початкове підключення ваших скриптів є відновленням сесії.
4. Контроль обміну даними із серверомtl;DR : Тепер ми можемо тонко налаштовувати обмін даними із сервером. Переконайтеся в обробці помилок, повторних запитах користь клієнта, синхронізації даних у фоновому режиміта збереження кешу в офлайні.
Коли з'явився Інтернет, обмін даними між клієнтом та сервером був обмежений декількома способами:
Простота такої моделі дуже приваблива, і зараз все безумовно ускладнилося, коли йдеться про розуміння, як отримувати та надсилати інформацію.
Головні обмеження стосуються другого пункту. Неможливість надсилання даних без обов'язкового завантаження нової сторінки було недоліком з точки зору продуктивності. Але найголовніше, що це повністю ламало кнопку «Назад»:
Ймовірно, найдратівливіший артефакт старого вебу
Саме тому веб як платформа для програм залишався неповноцінним без JavaScript. Ajax був величезний стрибок вперед з погляду зручності в частині публікації інформації користувачем.
Зараз у нас є безліч API (XMLHttpRequest, WebSocket, EventSource, це лише деякі з них), які дають повний та чіткий контроль над потоком даних. Крім можливості публікувати дані користувача через форму, у нас з'явилися нові можливості по поліпшенню UX.
Пряме відношення до попереднього принципу має показ стану з'єднання. Якщо ми очікуємо, що дані оновлюватимуться автоматично, то зобов'язані інформувати користувача про факти втрати зв'язкуі спробах її відновлення.
При виявленні дисконнекту корисно зберегти дані в пам'яті (а ще краще, в localStorage), так що їх можна відправити пізніше. Це особливо важливо у світлі майбутнього використання ServiceWorker, який дозволяє програмам JavaScript працювати у фоновому режимі. Якщо ваша програма не відкрита, ви все ще можете продовжувати спроби синхронізувати дані з сервером у фоновому режимі.
Враховуйте можливість таймаутів та помилок при надсиланні даних, такі ситуації повинні вирішуватися на користь клієнта. Якщо з'єднання відновлено, спробуйте надіслати дані знову. В разі постійної помилки, повідомте про це користувачеві.
Деякі помилки слід обробляти особливо уважно. Наприклад, несподівана 403 може означати, що сесія користувача визнана недійсною. У таких випадках є можливість відновити сеанс, якщо показати користувачеві вікно для введення логіну та пароля.
Важливо ще переконатися, що користувач не перерве потік даних. Це може статися у двох ситуаціях. Перший і найочевидніший випадок - закриття браузера або вкладки, що ми намагаємося запобігти обробці переднеобробкою.
Попередження beforeunload
Інший (і менш очевидний) випадок – спроба переходу на іншу сторінку, наприклад, натискання на посилання. І тут додаток може зупинити користувача іншими способами, на розсуд розробника.
5. Не ламай історію, покращуй їїtl;DR : Якщо браузер не керуватиме URL'ами та історією, у нас виникнуть нові проблеми. Переконайтеся, що ви відповідаєте очікуваній поведінці щодо прокручування. Зберігайте власний кеш для швидкого фідбеку.
Наприклад, типову «нескінченну» сторінку зазвичай роблять за допомогою кнопки JavaScript, яка запитує додаткові дані/HTML і вставляє їх. На жаль, деякі при цьому пам'ятають про необхідність виклику history.pushState або replaceState як обов'язкового кроку.
Ось чому я використовую слово "ламати". З простою моделлю початкового Інтернету така ситуація була неможлива. Кожна зміна стану ґрунтувалася на зміні URL-адреси.
Але є й зворотний бік медалі – можливість покращуватиісторію серфінгу, яку ми тепер контролюємо засобами JavaScript.
Одну таку можливість Деніел Піпіус назвав Fast Back:
Кнопка «Назад» має працювати швидко; користувачі не очікують надто великої зміни даних.
Це як розглядати кнопку «Назад» як кнопку з веб-додатку і застосувати до неї принцип № 2: негайно реагувати на дію користувача. Головне, що ви можете вирішити, як організувати кешування попередньої сторінки і миттєво вивести її на екран. Ви можете потім застосувати принцип №3, а потім інформувати користувача про надходження нових даних на цю сторінку.
Досі залишається кілька ситуацій, коли ви не можете контролювати поведінку кеша. Наприклад, якщо ви відрендерували сторінку, потім пішли на сторонній сайт, а потім користувач натиснув «Назад». Цьому маленькому багу особливо схильні додатки, які рендер HTML на стороні сервера, а потім модифікують його на стороні клієнта:
Некоректна роботакнопки «Назад»
Ще один спосіб зламати навігацію – ігнорування пам'яті про стан прокручування. Ще раз, сторінки, які не використовують JS та ручне керуванняісторією, швидше за все, не матимуть тут проблем. Але динамічні сторінки будуть. Я протестував дві найпопулярніші стрічки новинна основі JavaScript в інтернеті: Twitter та Facebook. В обох виявилася амнезія на прокручування.
Нескінченне гортання сторінок - зазвичай, ознака скролінг-амнезії
Зрештою, побоюйтеся таких змін стану, які є релевантними тільки при перегляді історії. Наприклад, цей випадок із зміною стану піддерев з коментарями.
Зміна вигляду коментарів слід зберігати в історії
Якщо сторінку знову намальовано після натискання посилання всередині програми, користувач може очікувати, що всі коментарі будуть розгорнуті. При зміні стану його необхідно зберегти в історії.
6. Оновлення коду через push-повідомленняtl;DR : Недостатньо надсилати через push-повідомлення лише дані, потрібно ще й код. Уникайте помилок API та підвищуйте продуктивність. Використовуйте stateless DOM для безболісного перелицювання програми.
Винятково важливо, щоб ваша програма реагувала на зміни в коді.
По-перше, це зменшує кількість можливих помилокта підвищує надійність. Якщо ви зробили важливу зміну в API бекенда, то повинніоновити код клієнтських програм. В іншому випадку, клієнти можуть не сприйняти нові дані або надіслати дані в несумісному форматі.
Не менш важливою причиною є дотримання принципу № 3. Якщо ваш інтерфейс оновлюється сам, то у користувачів мало причин звертатися до перезавантаження сторінки.
Майте на увазі, що у звичайного сайту оновлення сторінки ініціює дві речі: перезавантаження даних та перезавантаження коду. Організація системи з push-оновленнями даних без push-оновлень коду є неповноцінною, особливо у світі, де одна вкладка (сесія) може залишатися відкритою дуже довгий час.
Якщо серверний push-канал працює, то користувачеві можна надіслати повідомлення про доступність нового коду. Якщо ні, номер версії можна додати до заголовка вихідних HTTP-запитів. Сервер може порівняти його з останньою відомою версією, погодитись на обробку запиту чи ні, та видати завдання для клієнта.
Після цього деякі веб-програми примусово перезавантажують сторінку від імені користувача. Наприклад, якщо сторінка не знаходиться у видимій області екрана і на ній немає заповнених форм для введення.
Ще кращий підхід - "гаряча" заміна коду. Це означає, що не доведеться здійснювати повне перезавантаження сторінки. Натомість, певні модулізамінюються на льоту, які код повторно відправляється виконання.
В багатьох існуючих додаткахдосить складно здійснити «гарячу» заміну коду. Для цього потрібно спочатку дотримуватись архітектури, яка поділяє поведінка(код) від даних(Стан). Такий поділ дозволить нам досить швидко накочувати багато різних патчів.
Наприклад, у нашому веб-додатку є модуль, який встановлює шину для передачі event'ів (як socket.io). Коли настає подія, стан певного компонента змінюється і це відображається в DOM. Потім ви змінюєте поведінку цього компонента, наприклад так, що він генерує різні розмітки DOM для існуючого і нового станів.
В ідеалі ми маємо можливість змінювати код помодульно. Не потрібно буде знову встановлювати з'єднання з сокетом, наприклад, якщо є можливість просто оновити код потрібного компонента. Ідеальна архітектура для push-оновлень коду, таким чином, є модульною.
Але відразу виникає проблема з тим, як оцінити модулі без небажаних побічних ефектів. Тут найкраще підходить архітектура на кшталт тієї, яку пропонує React. Якщо код компонента оновлюється, його логіка може бути просто виконана, і DOM оновлюється. Пояснення цієї концепції від Дена Абрамова читай.
По суті, ідея полягає в тому, що ви оновлюєте DOM (або перефарбовувати його), що істотно допомагає в заміні коду. Якщо стан збережено в DOM або обробники event'ів встановлені програмою, то оновлення коду може стати набагато складнішим завданням.
7. Передбачення поведінкиtl;DR : Негативна затримка.
Сучасний JavaScript-програми можуть мати механізми для передбачення дій користувача.
Найбільш очевидним застосуванням цієї ідеї є завчасне завантаження даних із сервера, перш ніж користувач їх запросив. Завантажувати веб-сторінку, коли над нею з'явився курсор миші, так що після натискання на посилання вона відображається миттєво, це простий приклад.
Трохи більш просунутий метод моніторингу відстеження руху миші аналізує її траєкторію щодо майбутнього «зіткнення» з інтерактивними елементами, як кнопки. :
Плагін jQuery передбачає траєкторію миші
Веб залишається найбільш багатогранним середовищем передачі. Ми продовжуємо додавати динаміку на наші сторінки і перед їх впровадженням маємо переконатися, що збережемо важливі принципиІнтернету, що дісталися нам у спадок.
Сторінки, пов'язані між собою гіперпосиланнями - хороші будівельні блоки для будь-якої програми. Поступове завантаження коду, стилів та розмітки в міру дій користувача гарантує відмінну продуктивність без відмови від інтерактивності.
Нові унікальні можливостінадає JavaScript. Якщо ці технології будуть використовуватися повсюдно, то забезпечать найкращий досвідроботи для користувачів найвільнішої платформи з існуючих – WWW.
