Прежде всего, спасибо, что поделились своими мыслями о СПА, но я должен спросить, в каком году вы написали эту статью? Вы не только объединяете идею всех SPA с такими uber-фреймворками, как Angular и Ember (ни один из которых не является единственным способом создания приложений на JS, вы должны следовать философии Unix и создавать свои приложения из небольших составных частей, что является Node way), но вы также беспокоитесь о множестве проблем, которые больше не являются проблемами. В отличие от вашей статьи, я приведу примеры того, о чем говорю.
Возможно, ваше одностраничное приложение отличается, но те, которые я знаю, нарушают большинство функций моего браузера, таких как кнопки «Назад» и «Вперед», обновление страницы, создание закладок, отправка ссылки или открытие ссылки в новом окне или вкладке. Они не предлагают возможности ссылаться на то, на что я смотрю.
Проблемы, связанные с управлением историей и глубокими ссылками, прорабатывались некоторое время. Как упоминалось в других комментариях, теперь не только большие фреймворки имеют библиотеки маршрутизации, но также существуют автономные библиотеки маршрутизации, которые позволяют структурировать ваше приложение в компонентах на основе маршрутов, что позволяет очень легко перемещаться вперед и назад, а также делиться состоянием приложения. с глубокими ссылками.
Они раздуты и медленно загружаются, хотя фактическая информация, которую они отображают, и взаимодействие, которое они предлагают, очень просты.
Хотя это может быть правдой в отношении SPA, которые вы обычно используете, это сделано разработчиком, а не проблемой JavaScript или одностраничных приложений. Не говоря уже о том, что рендеринг на стороне сервера никоим образом не исправляет это. Возможно, вам придется подождать, чтобы загрузить приложение, но затем оно кэшируется до тех пор, пока не произойдет изменение. В следующий раз при посещении пользовательский интерфейс должен вас встретить довольно быстро (опять же, если приложение явно плохо написано, но я видел множество приложений на стороне сервера, которые также ужасны). Не говоря уже о том, что рендеринг на стороне сервера требует обновления КАЖДЫЙ РАЗ Я МЕНЯЮ СОСТОЯНИЕ ПРИЛОЖЕНИЯ! В большинстве случаев это ужасно неэффективно. По крайней мере, с одностраничными приложениями хороший разработчик (или команда разработчиков) создаст скелетный макет, а затем заполнит его, как только данные попадут на страницу. Я еще не видел SPA, который отображал белый экран во время ожидания загрузки страницы, как приложения на стороне сервера.
Я почти слышу, как вы говорите: «Но меня не волнует Интернет. Я создаю приложение, а не веб-сайт ». На что я говорю: вперед, создайте приложение, используя собственный набор инструментов для настольных или мобильных операционных систем, или создайте апплет, или приложение Flash или Silverlight. Меня все устраивает. Я даже не возражаю против того, чтобы вы создавали то же самое, используя браузер в качестве среды выполнения приложения. Просто имейте в виду, что когда вы делаете что-то таким образом, ваше приложение находится в сети точно так же, как если бы вы создали его как Java-апплет. Осознавайте, чем вы жертвуете.
Честно говоря, я даже не знаю, как на это ответить. Я должен спросить еще раз, в каком году вы живете? Даже если SPA избыточен, и вам нужен какой-то встраиваемый виджет, вам не следует выбирать ни одной технологии, о которой вы упомянули. Пока мы говорим, Flash удаляется из каждой среды выполнения. Silverlight отсутствует в Microsoft Edge, а IE 8,9 и 10 больше не поддерживаются, что означает, что Silverlight скоро исчезнет. Я даже не буду говорить о Java-апплетах, 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 не подходит для создания приложений. Не оценивайте архитектуру в целом по нескольким примерам. (Кстати, я был бы рад, если бы вы могли дать ссылку на некоторые из этих «ужасных» SPA, которые вы так взволновали по этой теме.)
Приветствую и счастливого JavaScripting!
