Поспішайте на сторону клієнта у веб-розробці

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

Чому це так? Яким чином новий і «розсіяний» клієнт, що розвивається в HTML5 / JS, може бути кращим для великих та продуманих серверних рішень?

Це правда:

Поспішайте на сторону клієнта у веб-розробці

Але це не обмежується стороною клієнта, це повний рух стека.

Я знаю, що це може дивувати. Будь ласка, вислухай мене.

Чому це так? Яким чином новий і «розсіяний» клієнт, що розвивається в HTML5 / JS, може бути кращим для великих та продуманих серверних рішень?

Перш за все, обидва добре продумані.

По-друге, тому що це краще.

Хороше питання.

Але "краще" є суб'єктивним, тому відповідь на ваше запитання полягає в тому, що конкретно краще?

Повторно відвідайте питання:

Як "дифузний" клієнт, що розвивається в HTML5 / JS, можливо, перевершує великі рішення на стороні сервера?

Because small is nimble.
And big is clunky.

Це гнучкість.

Це не здається великою справою. Робить це? Гнучкість.

Однак гнучкість лежить в основі всього. Одне покращення гнучкості - покращує все.

Технічне обслуговування. Розширюваність. Масштабованість. Модульність. Корисність. UX.

І це швидше здійснити. Це реальність. Швидше і краще.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, не примха і він не піде. Ми бачимо лише насіння технології, яка зростатиме, надаючи обчислювальний вміст та поведінку взаємодії планшетам. Таблетки

Смартфони були найшвидшим прийняттям засобів масової інформації після телебачення в 1950-х роках. Тепер ми не тільки маємо смартфони - у нас є планшети.

Вже в розробці в Mozilla та Windows ОС, яка буде працювати на майбутніх пристроях на своїх ринках -> HTML / JS.

Залишилося багато рішень та нововведень.

Виходить повний стек JS, заснований на гнучкості.

Я сподіваюся, що це допомагає.

Ця історія завжди мала дві сторони; і на стороні сервера, і на стороні клієнта є свої плюси і мінуси.

Переваги сценаріїв на стороні клієнта включають:

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

Але і серверний скрипт має багато переваг:

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

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

Спостережуваний ажіотаж походить від поєднання двох останніх подій:

1. HTML5 та його корона суміжних технологій. Це зайняло занадто довго, але зараз ми нарешті встановили стандарт, який містить все необхідне для створення тих динамічних веб-додатків, як настільний комп’ютер, без нагромадження хакерів, та основних браузерів, які їх належним чином реалізують.
2. Доступна потужність обробки. Сьогоднішні настільні ПК настільні настільки ж потужні, як веб-сервер початкового рівня, мобільні телефони клієнтів - це практично настільні комп’ютери 2005 року, а сучасні реабілітації JavaScript досить ефективні, щоб налаштувати баланс продуктивності: на сьогодні клієнтські ресурси дешевші серверних ресурси.

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

Сторона сервера завжди буде навколо. Ви не можете сидіти на стороні клієнта на все. Наприклад, ви не хочете використовувати дизайн MVC Backbone.js для свого мікроконтролера, що надсилає вам параметри в режимі реального часу з підвісного крана на виробничому поверсі.

Не вірте шуміху.

Я перейшов у 2009 році з PHP-сервера на сторону сервера до рішення ExtJS на стороні клієнта, пов'язаного з веб-сервісами на стороні сервера.

Причини міграції для мене були:

1. Краща безпека за рахунок зменшення кількості кінцевих точок та коду на сервері.
   Переходячи до веб-служб, ви підтверджуєте введення даних на кордоні веб-служби та отримуєте більш точний контроль над входом / виходом вашого сервера. Немає шару інтерфейсу на стороні сервера, який би змішував вашу архітектуру безпеки.
2. Покращена продуктивність через меншу кількість зворотних маршрутів на сервері
   . Архітектура змінюється, тому витяг даних може траплятися рідше, а дані можна кешувати локально, надаючи інтерфейс користувача, не вимагаючи взагалі зворотного переходу. Напрямні - це те, що вбиває ефективність веб-додатків.
3. Покращена продуктивність через кешованість користувальницького
   інтерфейсу Шар UI можна повністю розмістити на CDN. Я навіть створив веб-програми в автономному режимі, засунувши код інтерфейсу в кеш-код HTML5.
4. Більш висока надійність інтерфейсу (багате управління на стороні клієнта)
5. Сторонні розробники можуть використовувати той самий API, який використовує мій власний фронт-енд, і я можу легко використовувати повторно API через модулі, якщо вони мають спільні функції.
   Це означає менший розвиток, якість, документація, ...
6. Мені подобається програмування в JavaScript краще, ніж PHP, Python або Java

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

Ще одним фактором, який викликає захоплення клієнтськими рішеннями, є зростання мобільних додатків. Якщо ви робите веб-сайт, заснований на JavaScript та AJAX на стороні клієнта, а також створюєте вбудовані додатки для iOS та Android, є хороший шанс, що всі троє можуть використовувати одні й ті самі послуги REST, щоб зробити всі свої дані для того, щоб переглядати свої дані. .

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

Великий і потужний хостинг сервера досить дорогий. Набагато дешевше реалізувати певну логіку (крім перевірки) на стороні клієнта. Таким чином, ви можете використовувати менший (отже, дешевший) хостинг сервера, оскільки він не буде завантажений так сильно.

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

Ці дві частини додатків не можуть існувати окремо. І, здається, Інтернет найближчим часом нікуди не йде.
Я не думаю, що big server-side frameworksце теж може зникнути. Завжди знайдуться компанії, які можуть собі їх дозволити, і використають їхні суттєві переваги.

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

Є кілька рішень, які намагаються виправити це питання. Наприклад, якщо ви використовуєте jquery, ви впевнені, що ваш сценарій буде працювати в браузерах, підтримуваних цією бібліотекою jquery. Але лише автори надають вам сумісність із деякими / більшістю / усіма браузерами. Питання в тому, яка команда підтримає вас краще. Це буде команда motools, команда jquery, інша команда? Якщо вони не забезпечують підтримку певного веб-браузера, ваш проект може не працювати в цьому веб-переглядачі.

Хвилювання, яке вам здається, існує вже давно. Я бачив це, коли Shockwave та його наступник Flash були представлені, було «велике повернення» багатих користувальницьких інтерфейсів, коли були відправлені складні js-бібліотеки, спочатку з motools, потім з jquery (я почав використовувати їх у цьому порядку). Були Flex та JavaFX. Але жоден з них не може отримати великої частки на ринку. Деякі вимагають плагінів, які з часом часто піддають кінцевому користувачеві вразливості безпеки, інші можуть не працювати на стороні клієнта через деякі спеціальні налаштування (наприклад, JavaScript відключений у браузері клієнтів).

З іншого боку, рішення на стороні сервера зазвичай пишеться лише один раз. Вам не потрібно турбуватися про те, що все вийде з ладу, і доведеться їх переписувати, як тільки буде завантажено новий Firefox / Chrome / IE / Opera. Вам також не потрібно хвилюватися, що клієнт намагатиметься підробити ваше додаток та / або зіпсувати дані.

Абсолютно згоден з вашими настроями. Я також вважаю, що поза тим, що ви говорите, ми побачимо різке падіння REST та масовий підйом веб-сокетів для основного способу, яким ми бачимо, як сайти передають свої повідомлення на свої сервери. Vert.x, Node.js тощо. Вся серверна сторона, а також сторона клієнта переходить до програмування, керованого подіями. Java EE, PHP, Rails і т. Д. Всі вони повинні адаптуватися або вони дуже швидко втратять.