Применение одной страницы: преимущества и недостатки

Ответ 1

Посмотрите на один из самых популярных SPA-сайтов, GMail.

1. SPA очень хорош для очень отзывчивых сайтов:

Отверстие на стороне сервера не так сложно, как обычно, с простыми методами, такими как сохранение #hash в URL-адресе, или совсем недавно HTML5 pushState. При таком подходе точное значение веб-приложения встроено в URL-адрес страницы. Как и в GMail при каждом открытии почты, к URL-адресу добавляется специальный хэш-тег. Если скопировать и вставить в другое окно браузера, можно открыть ту же самую почту (при условии, что они могут пройти аутентификацию). Этот подход отображается непосредственно в более традиционную строку запроса, разница заключается только в выполнении. С помощью HTML5 pushState() вы можете исключить #hash и использовать полностью классические URL-адреса, которые могут быть разрешены на сервере по первому запросу, а затем загружать через ajax при последующих запросах.

2. С помощью SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.

Количество загрузок страниц во время посещения моего веб-сайта? действительно, сколько писем некоторые читает, когда он/она открывает свою учетную запись электронной почты. Я читал > 50 за один раз. теперь структура писем почти такая же. если вы будете использовать схему рендеринга на стороне сервера, тогда сервер будет отображать ее на каждом запросе (типичный случай).   - проблема безопасности - вы должны/не должны хранить отдельные страницы для админов/логинов, которые полностью зависят от структуры вашего сайта, например, на paytm.com, также создание веб-сайта SPA не означает, что вы открываете все конечные точки для всех Я имею в виду, что я использую формы auth с моим сайтом в спа.  - в наиболее вероятно используемой инфраструктуре SPA Angular JS разработчик может загрузить весь html-храм с веб-сайта, чтобы это можно было сделать в зависимости от уровня аутентификации пользователей. Предварительная загрузка html для всех типов auth не является SPA.

3. Могут ли быть другие преимущества? Больше не слышу.

• В эти дни вы можете смело предположить, что у клиента будут браузеры с поддержкой javascript.
• только одна точка входа на сайт. Как я уже упоминал ранее, возможно поддержание состояния, у вас может быть любое количество точек входа, как вы хотите, но вы должны быть уверены.
• даже в SPA-пользователе видят только то, что у него есть. вам не нужно вводить все сразу. загрузка шаблонов diff html и javascript async также являются действительной частью SPA.

Преимущества, о которых я могу думать:

• рендеринг html явно требует некоторых ресурсов, каждый пользователь, посещающий ваш сайт, делает это. также не только предоставление основных логик теперь выполняется на стороне клиента, а не на стороне сервера.
• проблемы с датой - я просто даю клиенту время UTC - это предварительно установленный формат и даже не заботятся о часовых поясах, с которыми я позволяю JavaScript обрабатывать его. это большое преимущество, когда я должен был догадываться о часовых поясах, основанных на местоположении, полученном от IP-адресов пользователей.
• для меня состояние более красиво поддерживается в SPA, потому что, как только вы установили переменную, вы знаете, что она будет там. это дает ощущение разработки приложения, а не веб-страницы. это очень помогает в создании сайтов, таких как foodpanda, flipkart, amazon. потому что, если вы не используете состояние клиентской стороны, вы используете дорогие сеансы.
• веб-сайты, безусловно, очень отзывчивы - я возьму крайний пример для этой попытки сделать калькулятор на сайте, не являющемся SPA (я знаю его странный).

Обновления из комментариев

Кажется, что никто не упоминал о сокетах и ​​длительном опросе. Если вы выходите из другого клиента, скажите мобильное приложение, то ваш браузер также следует выйти из системы. Если вы не используете SPA, вам необходимо заново создать сокет каждый раз, когда есть перенаправление. Это также должно работать с любыми обновлениями в таких данных, как уведомления, обновление профиля и т.д.

Альтернативная перспектива: помимо вашего сайта, ваш проект привлечь родное мобильное приложение? Если да, вы, скорее всего, будете подача необработанных данных на это родное приложение с сервера (например, JSON) и выполнение клиентская обработка для рендеринга, правильно? Таким образом, с этим утверждением, вы УЖЕ выполняете модель рендеринга на стороне клиента. Теперь вопрос становится, почему вы не должны использовать ту же модель для веб-сайта вашего проекта? Вид без проблем. Тогда вопрос становится хотите ли вы отображать серверные страницы только для преимуществ SEO и удобство совместного использования/закладки URL

Ответ 2

Недостатки

1. Клиент должен включить javascript. Да, это явный недостаток SPA. В моем случае я знаю, что я могу ожидать, что мои пользователи включат JavaScript. Если вы не можете, тогда вы не сможете сделать SPA, период. Это похоже на попытку развернуть приложение .NET на компьютере без установленной платформы .NET Framework.

2. Только одна точка входа на сайт.. Я решаю эту проблему, используя SammyJS. 2-3 дня работы, чтобы правильно настроить вашу маршрутизацию, и люди смогут создавать заставки с глубокой связью в вашем приложении, которые работают правильно. Вашему серверу нужно будет только разоблачить одну конечную точку - "дать мне HTML + CSS + JS для этого приложения" (подумайте об этом как о месте загрузки/обновления для предварительно скомпилированного приложения) - и на клиентском JavaScript, который вы пишете, будет обрабатывать фактический вход в приложение.

3. Безопасность.. Эта проблема не уникальна для SPA, вам нужно иметь дело с безопасностью точно так же, когда у вас есть приложение "клиент-сервер старой школы" (модель HATEOAS для использования гипертекста для связи между страницами), Это просто, что пользователь делает запросы, а не ваш JavaScript, и что результаты находятся в HTML, а не в JSON или в некотором формате данных. В приложении, отличном от SPA, вы должны защищать отдельные страницы на сервере, тогда как в SPA-приложении вам необходимо защитить конечные точки данных. (И, если вы не хотите, чтобы ваш клиент имел доступ ко всему коду, вам нужно разделить загружаемый JavaScript на отдельные области. Я просто привязываю это к моей системе маршрутизации на основе SammyJS, поэтому браузер запрашивает только вещи, которые клиент знает, должны иметь доступ к ним на основе начальной загрузки пользовательских ролей, а затем это становится проблемой без проблем.)

Преимущества

• Основным архитектурным преимуществом SPA (который редко упоминается) во многих случаях является огромное сокращение "chattiness" вашего приложения. Если вы сконструируете его должным образом, чтобы обрабатывать большую часть обработки на клиенте (в конце концов, все), количество запросов на сервер (чтение "возможностей для 503 ошибок, которые разрушают ваш пользовательский интерфейс" ) значительно сокращается. Фактически, SPA позволяет делать полностью автономную обработку, которая в некоторых ситуациях огромна.

• Производительность, безусловно, лучше с рендерингом на стороне клиента, если вы делаете это правильно, но это не самая веская причина для создания SPA. (В конце концов, скорость сети улучшается.) Не делайте это для SPA только на этой основе.

• Гибкость в дизайне пользовательского интерфейса, возможно, является другим основным преимуществом, которое я нашел. Как только я определил свой API (с SDK в JavaScript), я смог полностью переписать мой интерфейс с нулевым воздействием на сервер, кроме некоторых статических файлов ресурсов. Попробуйте сделать это с помощью обычного приложения MVC!:) (Это становится ценным, если у вас есть живые развертывания и согласованность версий вашего API, чтобы беспокоиться.)

Итак, нижняя строка: если вам нужна автономная обработка (или, по крайней мере, хотите, чтобы ваши клиенты могли пережить случайные сбои в работе сервера) - значительно сократить ваши собственные затраты на оборудование - и вы можете считать JavaScript и современные браузеры, тогда вам понадобится СПА. В других случаях это скорее компромисс.

Ответ 3

Я прагматик, поэтому я попытаюсь посмотреть на это с точки зрения затрат и преимуществ.

Обратите внимание, что для любого недостатка, который я даю, я признаю, что они разрешимы. Вот почему я не смотрю на что-то черное и белое, а скорее на затраты и выгоды.

<сильные > Преимущества

• Простое отслеживание состояния - не нужно использовать файлы cookie, отправку формы, локальное хранилище, хранилище сеансов и т.д., чтобы запомнить состояние между загрузкой на две страницы.
• Содержимое плиты котла, которое находится на каждой странице (верхний колонтитул, нижний колонтитул, логотип, баннер авторских прав и т.д.), загружается только один раз для каждого сеанса браузера.
• Отсутствие задержки по времени при переключении "страниц".

Недостатки

• Мониторинг производительности - привязаны руки: большинство решений мониторинга производительности на уровне браузера, которые я видел, сосредоточены исключительно на времени загрузки страницы, например, в режиме времени до первого байта, времени для создания DOM, совместной поездки по сети для HTML, события onload и т.д. Обновление пост-нагрузки страницы через AJAX не будет измерено. Существуют решения, позволяющие вам документировать ваш код для записи явных мер, например, при нажатии ссылки, запускать таймер, затем заканчивать таймер после визуализации результатов AJAX и отправлять эту обратную связь. Например, новая Relic поддерживает эту функцию. Используя SPA, вы связали себя только с несколькими возможными инструментами.
• Тестирование на безопасность/проникновение - привязанные руки: автоматизированные проверки безопасности могут затруднять обнаружение ссылок, когда вся ваша страница построена динамически с помощью системы SPA. Вероятно, есть решения для этого, но опять же, вы ограничили себя.
• Связывание. Легко попасть в ситуацию, когда вы загружаете весь код, необходимый для всего веб-сайта, на начальной загрузке страницы, что может ужасно работать для соединений с низкой пропускной способностью. Вы можете связать свои JavaScript и CSS файлы, чтобы попытаться загрузить более естественные фрагменты, когда вы идете, но теперь вам нужно поддерживать это сопоставление и следить за тем, чтобы непреднамеренные файлы могли втягиваться через нереализованные зависимости (только что случилось со мной). Опять же, разрешимо, но с себестоимостью.
• Рефакторинг Big Bang: если вы хотите сделать крупное архитектурное изменение, например, переключиться с одной рамки на другую, чтобы свести к минимуму риск, желательно внести дополнительные изменения. То есть, начните использовать новый, перенести на какой-то основе, например, для каждой страницы, для каждой функции и т.д., А затем отказаться от старого. С помощью традиционного многостраничного приложения вы можете переключить одну страницу из Angular на React, а затем переключить другую страницу в следующем спринте. С SPA, все это или ничего. Если вы хотите изменить, вам нужно изменить все приложение за один раз.
• Сложность навигации: существует инструмент, помогающий поддерживать навигационный контекст в SPA, например history.js, Angular 2, большинство из которых зависит от структуры URL (#) или новейшего API истории. Если каждая страница была отдельной страницей, вам это не нужно.
• Сложность определения кода: мы, естественно, думаем о веб-сайтах как о страницах. Многостраничное приложение обычно разбивается на разделы по страницам, что помогает ремонтопригодности.

Опять же, я признаю, что каждая из этих проблем разрешима, по какой-то причине. Но наступает момент, когда вы тратите все свое время на решение проблем, которые вы могли бы просто избежать в первую очередь. Он возвращается к преимуществам и насколько они важны для вас.

Ответ 4

Один из главных недостатков SPA - SEO. Только недавно Google и Bing начали индексировать страницы на основе Ajax, выполнив JavaScript во время обхода, и все же во многих случаях страницы индексируются неправильно.

При разработке SPA вы будете вынуждены обрабатывать проблемы SEO, возможно, после рендеринга всего своего сайта и создания статических html-снимков для использования искателя. Это потребует твердых инвестиций в надлежащую инфраструктуру.

Обновление 19.06.16:

С момента написания этого ответа некоторое время назад я получаю гораздо больше опыта работы с Single Pages Apps (а именно AngularJS 1.x), поэтому у меня есть дополнительная информация для совместного использования.

По моему мнению, основным недостатком приложений SPA является SEO, что делает их ограниченными только для приложений "приборной панели". Кроме того, у вас будет намного сложнее время с кешированием по сравнению с классическими решениями. Например, в ASP.NET кэширование предельно просто - просто включите OutputCaching, и вы хорошо: вся HTML-страница будет кэшироваться в соответствии с URL (или любыми другими параметрами). Тем не менее, в SPA вам нужно будет обрабатывать кэширование самостоятельно (используя некоторые решения, такие как кеш второго уровня, кэширование шаблонов и т.д.).

Ответ 5

Для таких компаний, как google, amazon и т.д., чьи серверы работают с максимальной пропускной способностью в режиме 24/7, сокращение трафика означает реальные деньги - меньше аппаратного обеспечения, меньше энергии и меньше обслуживания. Переход от использования процессора от сервера к клиенту оправдывается, и SPA-системы блестят. Преимущества избыточного веса недостатки далеко. Таким образом, SPA или не SPA во многом зависит от варианта использования.

Просто для упоминания другого, возможно, не столь очевидного (для веб-разработчиков) использовать случай для SPA: В настоящее время я ищу способ реализации графических интерфейсов во встроенных системах, и архитектура, основанная на браузере, кажется мне привлекательной. Традиционно было мало возможностей для пользовательских интерфейсов в встроенных системах - Java, Qt, wx и т.д. Или пристрастия коммерческих рамок. Несколько лет назад Adobe попыталась выйти на рынок со вспышкой, но, похоже, не настолько успешна.

В наши дни, поскольку "встроенные системы" так же мощны, как и мэйнфреймы несколько лет назад, пользовательский интерфейс на основе браузера, подключенный к блоку управления через REST, является возможным решением. Преимущество заключается в том, что огромная палитра инструментов для пользовательского интерфейса без каких-либо затрат. (например, Qt требует 20-30 $за проданную единицу за гонорары за лицензию плюс 3000-4000 $за разработчика)

Для такой архитектуры SPA предлагает множество преимуществ - например, более знакомый подход к разработке для разработчиков настольных приложений, снижение доступа к серверу (часто в автомобильной промышленности пользовательский интерфейс и системные путаницы - это отдельное оборудование, в котором системная часть имеет ОС RT).

Поскольку единственным клиентом является встроенный браузер, упомянутые недостатки, такие как доступность JS, ведение журнала на стороне сервера, безопасность больше не учитываются.

Ответ 6

Я хотел бы обратить внимание на то, что SPA лучше всего подходит для приложений, управляемых данными. gmail, конечно, все о данных и, следовательно, хороший кандидат на SPA.

Но если ваша страница в основном предназначена для отображения, например, страницы условий обслуживания, то SPA полностью перегружается.

Я думаю, что у сладкого пятна есть сайт со смесью страниц SPA и статического/MVC-стиля, в зависимости от конкретной страницы.

Например, на одном сайте, который я создаю, пользователь приземляется на стандартной странице индекса MVC. Но затем, когда они идут на фактическое приложение, он вызывает SPA. Другим преимуществом этого является то, что время загрузки SPA не на домашней странице, а на странице приложения. Время загрузки на домашней странице может быть отвлечением на первых пользователей сайта.

Этот сценарий немного похож на использование Flash. После нескольких лет опыта количество сайтов Flash только упало почти до нуля из-за коэффициента загрузки. Но в качестве компонента страницы он все еще используется.

Ответ 7

2. С помощью SPA нам не нужно использовать дополнительные запросы к серверу для загрузки страниц.

Мне еще нужно многому научиться, но с тех пор, как я начал изучать SPA, я их люблю.

Этот конкретный момент может иметь огромное значение.

Во многих веб-приложениях, которые не являются SPA, вы увидите, что они все равно будут извлекать и добавлять контент на страницы, делающие запросы ajax. Поэтому я думаю, что SPA выходит за рамки, рассматривая: что, если контент, который будет извлекаться и отображаться с помощью ajax, - это целая страница? а не только небольшую часть страницы?

Позвольте мне представить сценарий. Подумайте, что у вас есть 2 страницы:

• страница со списком продуктов
• страницу для просмотра сведений о конкретном продукте

Учтите, что вы находитесь на странице списка. Затем вы нажимаете на продукт, чтобы просмотреть детали. Приложение на стороне клиента вызовет два запроса ajax:

• запрос на получение объекта json с информацией о продукте
• запрос на получение html-шаблона, в котором будут добавлены сведения о продукте

Затем клиентское приложение будет вставлять данные в шаблон html и отображать его.

Затем вы возвращаетесь к списку (для этого не требуется запрос), и вы открываете другой продукт. На этот раз для получения информации о продукте будет только запрос ajax. Шаблон html будет таким же, поэтому вам не нужно снова загружать.

Вы можете сказать, что в не SPA, когда вы открываете детали продукта, вы делаете только 1 запрос, и в этом сценарии мы сделали 2. Да. Но вы получаете прибыль от общей перспективы, когда вы перемещаетесь по многим страницам, количество запросов будет ниже. И данные, которые передаются между клиентской стороной и сервером, также будут ниже, потому что шаблоны html будут повторно использоваться. Кроме того, вам не нужно загружать в каждом запросе все эти файлы css, images, javascript, которые присутствуют на всех страницах.

Также учтите, что язык на стороне сервера - это Java. Если вы проанализируете два упомянутых мною запроса, 1 загружает данные (вам не нужно загружать какой-либо файл вида и вызывать механизм рендеринга представления), а также другие загрузки и статический шаблон html, чтобы вы могли иметь HTTP-сервер HTTP, который может получить он напрямую без вызова сервера приложений Java, вычисления не выполняются!

Наконец, крупные компании используют SPA: Facebook, GMail, Amazon. Они не играют, у них есть величайшие инженеры, которые все это изучают. Поэтому, если вы не видите преимуществ, которые вы можете изначально им доверять, и надеемся открыть их в будущем.

Но важно использовать хорошие образцы дизайна SPA. Вы можете использовать фреймворк вроде AngularJS. Не пытайтесь внедрять SPA без использования хороших шаблонов дизайна, потому что у вас может быть беспорядок.

Ответ 8

Недостатки: Технически, проектирование и начальное развитие СПА является сложным и его можно избежать. Другими причинами отказа от использования этого SPA могут быть:

• a) Безопасность: одностраничное приложение менее безопасно по сравнению с традиционными страницами из-за межсайтового скриптинга (XSS).
• b) Утечка памяти: утечка памяти в JavaScript может привести к замедлению работы компьютера. Поскольку традиционные веб-сайты поощряют перемещение между страницами, таким образом, любая утечка памяти, вызванная предыдущей страницей, почти очищается, оставляя меньше остатков.
• c) Клиент должен включить JavaScript для запуска SPA, но в многостраничном приложении JavaScript можно полностью избежать.
• d) SPA растет до оптимального размера, вызывая длительное время ожидания. Например: работа с Gmail с более медленным подключением.

Помимо вышеизложенного, другими архитектурными ограничениями являются Навигационные потери данных, Нет журнала истории навигации в браузере и трудности в автоматическом функциональном тестировании с селеном.

Эта ссылка объясняет преимущества и недостатки одной страницы.

Ответ 9

Попытайтесь не использовать SPA без предварительного определения того, как вы будете решать проблему безопасности и стабильности API на стороне сервера. Тогда вы увидите некоторые из истинных преимуществ использования SPA. В частности, если вы используете сервер RESTful, который реализует OAUTH 2.0 для обеспечения безопасности, вы достигнете двух основных разделов проблем, которые могут снизить затраты на разработку и обслуживание.

• Это переместит сеанс (и его безопасность) в SPA и освободит ваш сервер от всех этих накладных расходов.
• Ваш API станет стабильным и легко расширяемым.

Указывается на ранее, но не делается явным; Если ваша цель состоит в развертывании приложений Android и Apple, написание JavaScript SPA, завернутого обычным вызовом для размещения экрана в браузере (Android или Apple), избавляет от необходимости поддерживать как базу кода Apple, так и базу кода Android.

Ответ 10

В моем развитии я нашел два отличных преимущества для использования SPA. Это не значит, что в традиционном веб-приложении не может быть достигнуто следующее: я вижу дополнительные преимущества без дополнительных недостатков.

• Потенциал для меньшего запроса сервера в качестве рендеринга нового контента не всегда или даже никогда не является запросом HTTP-сервера для новой html-страницы. Но я говорю о потенциале, потому что новый контент может легко потребовать вызова Ajax для вывода данных, но эти данные могут быть постепенно легче, чем сама по себе плюс разметка, обеспечивая чистую выгоду.

• Возможность поддерживать "состояние". В простейших терминах установите переменную при входе в приложение, и она будет доступна для других компонентов на протяжении всего опыта пользователей, не передавая ее или не устанавливая ее на локальный шаблон хранилища. Разумное управление этой способностью, однако, является ключом к тому, чтобы держать область верхнего уровня незагроможденной.

Помимо требований JS (что не является безумным требованием к веб-приложениям), другие отмеченные недостатки, на мой взгляд, либо не специфичны для SPA, либо могут быть смягчены с помощью хороших привычек и шаблонов разработки.

Ответ 11

Я понимаю, что это старый вопрос, но я хотел бы добавить еще один недостаток приложений Single Pages:

Если вы создаете API, который возвращает результаты на языке данных (например, XML или JSON), а не на язык форматирования (например, HTML), вы обеспечиваете большую совместимость приложений, например, в бизнес-бизнесе (B2B ) Приложения. Такая интероперабельность имеет большие преимущества, но позволяет людям писать программное обеспечение для "моего" (или кражи) ваших данных. Этот недостаток является общим для всех API, которые используют язык данных, а не для SPA в целом (действительно, SPA, который просит сервер для предварительно обработанного HTML избегает этого, но за счет плохой разметки модели/представления). Этот риск, подвергаемый этому недостатку, может быть смягчен различными способами, такими как ограничение запроса и блокировка соединения и т.д.