Чому бази кодів у розробці n-ярусів мають рівний, якщо не більше, код JavaScript зараз?

Я давно займаюся веб-програмуванням, і десь я втратив слідку, чому ми робимо те, що робимо сьогодні (або як ми прийшли робити такі речі)?

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

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

Потім я стрибнув на універсал ASP.NET і почав використовувати їх підхід MVC. Я також зрозумів, що Java здається мовою вежі із слонової кістки в корпоративних системах, а також спробував їх підхід MVC. Пізніше ASP.NET розробив цю модель дизайну MVVM, і Java (саме J2EE або JEE) також боролася і вийшла зі своїми підходами MVC2.

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

Чому відбувся цей рух від розробки сервера до клієнта? Я зробив простий підрахунок рядків одного з моїх проектів JEE, і в JavaScript більше рядків коду, ніж у Java (за винятком сторонніх бібліотек). Я вважаю, що більшість розробок, що використовують мови програмування, такі як Java або C #, - це просто створити інтерфейс, схожий на REST, і що всі важкі зусилля для відображення, візуалізації, введення даних / виведення даних, взаємодії користувачів тощо ... за допомогою клієнтської системи, наприклад кутовий, магістральний, вугільний, нокаут тощо.

Протягом епохи до jQuery я побачив безліч діаграм, де була чітка, концептуальна лінія між M, V та C в MVC в n-ярусному розвитку. Post-jQuery, куди малюються ці рядки? Здається, MVC і MVVM все там у коді JavaScript на стороні клієнта.

Що я хочу знати, чому ми зробили такий перехід (від акценту на серверному програмуванні до клієнтської, від переваги компільованих мов до мов скриптів, від імперативного до функціонального програмування, все це, здається, відбулося одночасно ) і які проблеми вирішив цей перехід / зсув?

Переміщення обчислювального навантаження між сервером і клієнтом - циклічне явище, і таке вже досить давно.

Коли я був у коледжі громади, Персональний комп’ютер просто отримував голову пари. Але Ethernet ще не отримав широкого використання, і ніхто не мав локальної мережі. Тоді коледж мав мейнфрейм, який обробляв записи студентів і служив платформою для занять з програмування. Адміністрація мала термінали, які були підключені до мейнфрейму на основі часу поділу часу, але студенти повинні були пробивати картки, щоб виконати завдання програмування, важкий процес. Врешті-решт, вони помістили в лабораторію, де студенти могли записатись на термінал, але це все-таки зайняло, можливо, півгодини або близько того, щоб отримати ваш друкований помилки товщиною пів дюйма Усі роботи з обробки були виконані на мейнфреймі (сервері).

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

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

У міру того, як комп’ютери ставали все більш потужними, стали можливі розподіли праці. Тепер у вас можуть бути файлові сервери, сервери баз даних, веб-сервери, сервери друку тощо. Кожна машина могла бути дещо оптимізована під завдання, яке вона поставила, та підтримувати її хтось із необхідним досвідом. Можуть бути написані програми, які запускаються у веб-браузері, тому встановлення клієнтів більше не потрібно. Це називалося багаторівневим або n-рівнем. Браузери, по суті, використовувались як німі термінали, як і в дні мейнфрейму, хоча метод спілкування з сервером був більш досконалим, менш захищеним та базувався на механізмах переривання, а не обміну часом та опитуваннями. Обробка перемістилася назад на сервер (и).

Однак веб-розробка прийшла з цілком новим набором головних болів. Більшість ліній бізнес-додатків, написаних для браузера, були статичними формами та звітами. Інтерактивності в інтерфейсі було дуже мало. Javascript ще не знайшов свого другого вітру, і існували великі проблеми з несумісністю браузера, що відштовхувало його широке поширення. Однак справи стали набагато краще. HTML5 та CSS3 надають істотні нові можливості моделі програмування браузера, jQuery вийшов і допоміг цілому поколінню програмістів виявити, наскільки корисним може бути JavaScript. З'явилися нові фронтальні рамки інтерфейсу користувача. Стало можливим писати високоінтерактивний інтерфейс користувача у браузері, навіть повноцінні ігри. Обробка знову перейшла до клієнта.

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

Ви ніби змішуєте дві дуже різні концепції:

1. Розмежування презентації та бізнес-логіки (MVC) => підвищує ремонтопридатність
2. Призначення виконання вузлу => підвищення ефективності

Ще в ті часи обчислення клієнта / сервера часто плутали, маючи на увазі перше, оскільки клієнти, як правило, не пропонували великої кількості обчислювальної потужності порівняно з серверами. Тому здавалося природним переміщення «важкого» обчислення бізнес-логіки (M) на сервери, зберігаючи при цьому «легку» обробку подання (V) клієнтам. У свою чергу вам довелося реалізувати якийсь арбітраж (С) для перекладу між ними.

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

• клієнтська затримка та складність: обробка на стороні сервера робить системи простішими, оскільки не потрібно розгортати / завантажувати код на клієнта, однак це відбувається за рахунок затримки на клієнті під час обчислення.

• Складність та завантаження сервера: обчислення на стороні клієнта може збільшити складність системи, але також може допомогти зменшити навантаження сервера.

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

Це невичерпний перелік багатьох компромісів.

Оскільки користувачі завжди хотіли тієї ж функціональності, дзвіночки зі своїми веб-додатками (а не лише веб-сайтами), які вони мали із додатками для настільних ПК. Здійснення цього роботи у веб-переглядачі (фактично в декількох браузерах) не схоже на старі часи, коли ви могли зв'язати форму VB з базою даних з невеликим кодом. Це легше здійснити, коли не потрібно робити поїздки назад на сервер.

Більшість розробок, що використовують мови програмування, такі як Java або C #, - це просто створити інтерфейс, схожий на REST, і всі важкі зусилля для відображення, візуалізації, введення даних / виведення даних, взаємодії з користувачами тощо ... бічні рамки, такі як кутова, хребта, вугілля, нокаут тощо ...

Можливо, програмне забезпечення / сервіси, що надаються, здаються такими ж старими, але це серце програми. Практики кодування можуть бути ефективнішими в цих областях. Інструменти, мови, браузери та рамки все ще розвиваються, тому UI / UX важко розробити. Це нові речі, яких не мав старий ASP. Якби ми могли відійти від користувальницьких інтерфейсів з простими формами та html-таблицями, в цих областях не виникне великого інтересу / галасу, але користувачі хочуть перетягування, анімації, переходи, спливаючі вікна тощо.

Сьогодні в більшості проектів, над якими я працюю, я виявив, що рамки JavaScript та розробка на стороні клієнта - це досягнення всіх захоплюючих та інноваційних прогресів.

Чому відбувся цей рух від розробки сервера до клієнта?

Тут насправді є два питання:

1. Чому програмування на стороні клієнта там, де відбувається прогрес?
2. Чому програми написані для роботи на клієнті, а не на сервері?

Два насправді є різними.

Чому програмування на стороні клієнта там, де відбувається прогрес?

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

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

Оскільки ці фактори поступово змінюються, вони створюють критичну масу для швидкого розвитку багатих клієнтських додатків та послідовного їх запуску.

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

Чому програми написані для роботи на клієнті, а не на сервері?

Близьких причин існує безліч, але найбільш чіткою в останні роки є зростання смартфонів.

Смартфони роблять помірно потужні обчислення дешевими, всюдисущими та корисними. Вони належать мільярдам людей по всій планеті і по суті привели обчислювальну техніку до середніх класів економік, що розвиваються. Але мобільні мережі мляві, нерівномірні та обмежені географічними, інженерними та політичними жорсткими проблемами. У цьому середовищі програми неминуче зберігати стан і локально зберігати дані вгору неохоче та в операціях без стану.

Як це могло бути інакше? Уявіть, якби ваш смартфон був просто німим терміналом. Кожна мутація стану повинна бути асинхронною та помилковою. Кожне завантаження вмісту коштуватиме дорогоцінних центів. Вам доведеться інвестувати у величезні серверні ферми з п’ятьма дев'ятьма послугами. Витрати на обчислення ви мали би безпосередньо ви, тому раптовий приплив популярності насправді може заповнити ваш бізнес.

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

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

Ви задали кілька питань, на деякі з яких вже є хороші відповіді. Кілька ще не мали своїх відповідей:

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

Роберт Харві дав чудову відповідь.

... від переваги компільованих мов до мов сценарію,

Мови сценаріїв пропонують багато переваг ( також ) перед зібраними мовами, наприклад:

• простіші в навчанні та використанні
• усунути час компіляції (швидший розвиток)
• забезпечити більше функцій (контроль додатків вищого класу)
• дозволити швидкі зміни запущеного коду
• тощо.

... від імперативного до функціонального програмування,

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