Първо, благодаря ви, че споделихте мислите си за СПА, но трябва да попитам коя година написахте тази статия? Не само, че групирате идеята за всички SPA с uber frameworks като Angular и Ember (нито един от тях не е единственият начин за изграждане на приложения в JS, трябва да следвате философията на Unix и да създавате приложенията си от малки композируеми части, което е Node way), но вие също се притеснявате за много проблеми, които вече не са проблеми. За разлика от вашата статия, аз ще дам примери за това, за което говоря.
Може би вашето едностранично приложение е различно, но тези, които познавам, нарушават повечето функции на браузъра ми, като бутоните за връщане назад и напред, опресняване на страницата, маркиране, изпращане на връзка или отваряне на връзка в нов прозорец или раздел. Те не предлагат начин за връзка към нещо, което гледам.
Проблемите, свързани с управлението на историята и дълбоките връзки, са разработени за известно време. Както бе споменато в други коментари, не само големите рамки вече имат библиотеки за маршрутизиране, но има и самостоятелни библиотеки за маршрутизиране, които ви позволяват да структурирате приложението си в базирани на маршрут компоненти, което го прави много лесно за навигиране напред и назад, както и за споделяне на състоянието на приложението с дълбоки връзки.
Те са раздути и се зареждат бавно, въпреки че действителната информация, която показват, и взаимодействието, което предлагат, са много прости.
Въпреки че това може да е вярно за SPA, които сте склонни да използвате, това е от създаването на програмист, а не проблем с JavaScript или приложения с една страница. Да не говорим, че изобразяването от страна на сървъра не коригира това по никакъв начин. Може да се наложи да изчакате, за да заредите приложението, но след това то се кешира, докато има промяна. Следващият път, когато посетите, трябва да бъдете посрещнати от потребителски интерфейс доста бързо (отново, освен ако приложението е очевидно лошо написано, но съм виждал много приложения от страна на сървъра, които също са ужасни). Да не говорим, че изобразяването от страна на сървъра изисква опресняване ВСЕКИ ПЪТ, КЪМ СМЕНЯ СЪСТОЯНИЕТО НА ПРИЛОЖЕНИЕТО! Това е просто ужасно неефективно в повечето случаи. Поне с приложения с една страница добър разработчик (или екип от разработчици) ще създаде скелетно оформление и след това ще го попълни, след като данните попаднат на страницата. Все още не съм виждал SPA, който показва бял екран, докато чака страницата да се зареди като приложения от страна на сървъра.
Почти мога да те чуя да казваш: „Но не ме интересува мрежата. Създавам приложение, а не уебсайт.“ На което казвам: Давайте, създайте приложение, като използвате собствения инструментариум на вашата настолна или мобилна операционна система, или създайте аплет, или приложение за Flash или Silverlight. Това е добре за мен. Дори не възразявам да създавате същото нещо, като използвате браузъра като среда за изпълнение на приложение. Просто имайте предвид, че когато правите нещата по този начин, вашето приложение е в мрежата точно толкова, колкото ако сте го изградили като Java аплет. Бъдете наясно какво жертвате.
Честно казано, дори не знам как да отговоря на това. Пак да питам в коя година живееш? Дори ако SPA е прекалено много и имате нужда от някакъв вид вградена джаджа, не трябва да избирате нито една технология, която споменахте. Flash се премахва от всяко време на изпълнение, докато говорим. Silverlight не е в Microsoft Edge и тъй като IE 8,9 и 10 вече не се поддържат, това означава, че Silverlight скоро ще изчезне. Дори няма да говоря за Java Applets, WTF? Ако не е необходимо да създавате цяло приложение, трябва да търсите нещо като уеб компоненти, React компоненти или jQuery плъгини.
Но по-важното е, че те пропускат ползите от това да не изберат СПА. Те не са наясно с предимствата на алтернативата. Каква е тази алтернатива тогава? Това е да се създаде класическо уеб приложение, включително изобразяване на HTML от страна на сървъра, и да се използва пестеливо JavaScript, за да се подобри функционалността на браузъра, където е възможно. При този архитектурен подход е абсолютно ясно, че отговорността за действителната бизнес логика е изцяло на сървъра. Това включва държавната машина от страна на сървъра, която управлява преходите между страниците. И отново, това не е грешка, а функция: това е, което позволява бърза промяна от страната на сървъра да влезе в сила незабавно, навсякъде – включително другите видове клиенти, които в крайна сметка може да изградите в допълнение към вашия уеб интерфейс. Бизнес логиката не принадлежи на клиента, освен ако не ви харесва да поддържате излишно същата логика във всеки вид клиент, който поддържате (в допълнение към поддържането й на сървъра, разбира се - не забравяйте, че никога не можете да се доверите на нито един клиент). От гледна точка на сървъра най-добрата архитектура, която можете да имате, е тази, която бихте могли (и трябваше) да изградите преди десетилетие: следвайки принципите на REST, включително комуникация без състояние и идентифициране на ресурси.
Да кажете на разработчиците да създават уеб приложения по начина, по който направихме преди десет години, е най-лошият съвет, който можете да дадете на някого. Времената се променят, технологиите се променят. Притесненията не са това, което бяха. Способността да достигаме до хората чрез множество клиенти промени начина, по който трябва да мислим за това как съхраняваме/предоставяме/показваме информацията, която потребителите искат от нас. Това също означава, че трябва да променим начина, по който създаваме нашите приложения, за да задоволим по-добре тези нови нужди. Казвате, че сървърът трябва да бъде държавна машина и че трябва да следвате принципите на REST, „включително комуникация без състояние“. Как се осъществява комуникация без състояние, когато сървърът е мениджърът на състоянието?
Вие също казахте: „Бизнес логиката не принадлежи на клиента“, това е правилно, за това са API. Това, което трябва да каже, е „управлението на състоянието не принадлежи към вашия API“. Сървърното приложение, поддържащо вашите клиенти, е там, за да предоставя данни и да позволява взаимодействие с тези данни, това е всичко. Защо друго приложение трябва да управлява състоянието на клиента? Във вашата Utopia имате едно приложение от страната на сървъра, което изобразява съдържание за всички устройства. Как това е по някакъв начин по-малко сложно от множество клиентски приложения. Виждал съм ефектите от използването на приложение от страната на сървъра за захранване на мобилни и уеб браузъри, не беше много красиво. Много проблеми с горилата/банана започват да се появяват, когато един клиент се нуждае от функция, която е малко по-различна от другите клиенти. Докато проблемът с горила/банан се фокусира главно върху ООП, същата ситуация идва с наследяване на нежелано поведение от разширяване на изгледи и шаблони.
Напълно добре е клиентите да управляват собственото си състояние. Всъщност в повечето случаи би трябвало. Друг проблем с вашата архитектура (за който не давате подробности) е, че процесът ви на компилация/пускане ще отнеме много време. Нека да разгледаме пример от реалния живот на този сценарий.
- Дизайнерският екип казва, че бутонът се нуждае от нов текст и цвят. (5 минути промяна)
- Програмистът прави промени (може би един час работа, може би)
- Разработчикът се ангажира и настоява за промяна
- Изпълнява се цялата компилация, включително всички тестове за всички клиенти и сървърното приложение (кой знае колко време отнема това)
- Версията все още не може да излезе, защото има грешка в друг клиент, която трябва да бъде коригирана, открита от QA. (Няколко дни)
- Грешката е коригирана, но създава друга непредвидена грешка, тъй като цялата сложна логика на рендиране за множество клиенти започва да става твърде объркваща. (Още няколко дни)
Вашият бутон и текст се разпространяват в стандартната версия две седмици по-късно.
Това е реален пример, който съм виждал от първа ръка. Разделянето на притесненията е ключово и никога няма да ме убедите, че моят API трябва да се тревожи за състоянието на който и да е от своите клиенти. Ползите, които представяте в публикацията си, всъщност не дават цялата картина. Казвате да не се фокусирате върху приятелското отношение към разработчиците, а вместо това да се фокусирате върху щастието на клиента. Мисля, че трябва да намериш място по средата. Да имате страхотен фокус върху клиентите е страхотно, освен ако не можете да им доставите продукта си бързо, те най-вероятно ще го намерят някъде другаде.
Вие също споменахте, че извършването на промяна веднъж на сървъра ви позволява да разпространявате тази промяна навсякъде, без да актуализирате множество кодови бази. Казвам, че трябва да не разбирате наистина JavaScript в наши дни. Ако правите правилно JS, вашият код е разбит на малки пакети, които се споделят във вашите приложения (тъй като всичко е JS, можем да го използваме отново навсякъде). Направете корекция на вашия модул и използвайте услуги като greenkeeper.io, за да облекчите необходимостта да управлявате тези зависимости вместо вас.
Някои хора възразяват срещу това, защото смятат, че SPA ви дава по-добра архитектура. Не съм съгласен: при SPA вашата архитектура обикновено е тази, предложена от вашата рамка, тъй като от гледна точка на мрежата вашият SPA е единственото нещо, с което се занимава мрежата. С не-SPA подход (който отсега нататък ще наричам ROCA), архитектурата, управляваща вашите приложения, е тази на самата мрежа.
Не съм сигурен какво се опитвате да кажете, звучи сякаш казвате, че SPA рамки като Angular и Ember са мнителни и имат предварително дефинирана архитектура, която популяризират. О, имаш предвид като Wordpress, Drupal, Laravel, Django, RoR и всички останали мнителни рамки от страна на сървъра?
Смешно е, защото случайно сте наполовина прав! Трябва да избягвате тези рамки, но не защото трябва да позволите на сървъра да визуализира потребителския ви интерфейс, а защото JavaScript, комбиниран с NPM модули, прави много лесно избирането на отделните части, от които се нуждаете, за да изградите правилната рамка, която да отговаря на нуждите на вашето приложение. Има повече JavaScript модули от всеки друг език с мениджър на пакети, ИЗПОЛЗВАЙТЕ ГИ!
Фантастичен пример за проблемите, създадени от SPA подхода, е успоредяването на работата. Ако имате екип от множество хора, или не дай Боже, няколко екипа, работещи върху един и същ SPA, трябва да измислите добър начин да поддържате това. Вместо това можете просто да накарате всеки от тези екипи да изгради собствено уеб приложение. Всяко от тези приложения може да бъде свързано с всяко друго, създадено по същото време от същата организация (както и с всяко друго уеб приложение, което се намира навсякъде, ако желаете) — всъщност разчитайки на основната сила на мрежата.
Отново Node модулите решават този проблем. Да не говорим, че тази логика просто би съществувала на сървъра, а не на клиента, как това, че е приложение от страна на сървъра, прави нещо повече от тези екипи да работят върху различна кодова база заедно?
В почти всеки случай, за който знам, вашият SPA няма нулева полза за потребителя и вместо това има само положителни страни от възприемането на функциите на браузъра.
Това е доста смело изявление, без да има нито един пример за това!
Трябва да кажа, че изглежда, че всъщност имате много малко опит с използването на JavaScript в мащаб. В момента работя с JavaScript в множество изпълнения, включително SPA, и не мога да си представя да създам нашето приложение или сайт, или както предпочитате да го наричате по друг начин. Сега има моменти, когато прилагането на SPA не е оправдано, но с начина, по който технологията се променя, всъщност ми е по-трудно да мисля кога е добра идея да НЕ използвам SPA.
Преместването в СПА всъщност ни помогна и на много предишни работни места. Ако сте имали такъв лош опит с него, може би уточняването на това, което е толкова лошо, освен разрешените проблеми (маршрутизиране, SEO и т.н.) и предоставянето на конкретни решения би било много по-жизнеспособно, отколкото просто да се оплаквате за това. JavaScript експлодира в момента и с неговата лекота на използване и ниска бариера за навлизане, не е чудно, че се появяват някои приложения, които може да ви създадат впечатлението, че JS не е добър за създаване на приложения. Не съдете за цялостната архитектура по няколко примера. (Говорейки за това, ще се радвам, ако можете да направите връзка към някои от тези „ужасни“ СПА, които толкова ви вълнуват по темата.)
Наздраве и приятно JavaScript!
