Зависит от того, для чего вы его используете.

СПА сейчас очень популярны, и поклонники создания таких сайтов и приложений начинают больше походить на культистов, чем на разумных взрослых. Это связано с тем, что существует значительное совпадение между глупыми фанатами фреймворков и теми, кто делает дикие необоснованные заявления о том, насколько «лучше» SPA для пользовательского опыта.

К сожалению, очень похоже на художников, которые думают, что они дизайнеры, те, кто заявляет о UX, так же мало знают о пользовательском опыте или доступности.

Как я уже много раз говорил, поклонники интерфейсных фреймворков лишены самых элементарных знаний о том, для чего вообще нужны HTML и CSS; поэтому нет ничего удивительного в том, что у них такое же культовое отношение, когда дело доходит до использования JavaScript на веб-сайтах.

Хотя БОЛЬШИНСТВО проблем не по вине SPA. Нет, вина лежит на пороге реализации.

Проблемы реализации

То, как создается и кодируется SPA, по большей части идет не так. Давайте рассмотрим некоторые из наиболее распространенных проблем.

Никаких сценариев изящной деградации

Это не обязательно должно быть правдой, но, к сожалению, в большинстве случаев это так. Блокирование или недоступность сценариев - это реальность для многих пользователей. Многие рабочие места и пользователи закрывают его из-за недоверия. Некоторые ограничивают его, чтобы попытаться сэкономить полосу пропускания (то же самое для изображений), другие блокируют его, чтобы разрешить это только в каждом конкретном случае; См. Расширения браузера, такие как NoScript.

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

Дело в том, что в этом нет необходимости. Если вы напишете страницу так, чтобы она работала как обычная страница, насколько это возможно ПЕРВЫЙ, а затем превратите страницу в SPA, вы получите лучшее из обоих миров. На самом деле это действительно легко сделать, если у вас уже есть система с несколькими шаблонами. Подобно тому, как RSS-каналы представляют собой не что иное, как разные оболочки для одного и того же контента, вы применяете те же методы к SPA. Нормальная загрузка страницы использует нормальную обложку, но ваши запросы AJAX получают другую обложку, которая выводит JSON или какой-либо другой формат только того, что нужно изменить на странице. Это не ракетостроение, и очень жаль, что большинство людей, которые рвут страницы с мусором, таким как React и Angular, не могут быть обеспокоены, потому что они на самом деле не обращают внимания на конечных пользователей. Их волнует только их собственный маленький кругозор скриптов.

Как видно из того, как каждый раз, черт возьми, эта тема поднимается, они говорят идиотские вещи, такие как «использование Интернета без JavaScript в 2021 году» бла-бла-бла, не осознавая, что их тупое чрезмерное использование JavaScript - вот что побуждает все больше и больше людей обращать на это внимание. прочь!

И почему это трагическая комедия, когда они болтают о «пользовательском опыте», даже не зная, что означает этот термин!

Отсутствие навигационных очередей и неработающая навигация

Это простые вещи, которые также можно реализовать, чтобы их не заметить. Например, изменение содержимого ‹title› для представления текущей страницы. Достаточно плохо, что большинство людей, пишущих веб-сайты, похоже, даже не заботятся о создании полезных заголовков в соответствии с "page title — site title" format без того, чтобы сайты не обновляли его на подстраницах.

То же самое касается фактических ссылок на контент страницы. Если вы не используете window.history.push URI своей новой страницы, как люди будут ссылаться на вас? Опять же, сделать это достаточно легко, почему люди этого не делают? Ну, я частично знаю почему; во многих SPA отсутствует какой-либо механизм, позволяющий пользователям напрямую ссылаться на подстраницы из-за отсутствия постепенной деградации, описанной выше.

И это прежде, чем мы поговорим о том, что отсутствие активности window.history означает, что нормальная навигация вперед / назад не работает. То же самое касается открытия в новых вкладках, что является достаточно распространенным явлением (средний щелчок или Ctrl-щелчок) для многих пользователей. SPA часто блокируют такое поведение, поскольку их поведение, основанное только на сценариях, совершенно не способно его реализовать.

Однако, как я постоянно говорю, концепция SPA не виновата в этом. Всех этих проблем можно избежать с помощью хорошей реализации! Проблема не в самой концепции! Большинство людей ее претворяют в жизнь наполовину!

Но нужны ли даже СПА? Что они даже пытаются «исправить»?

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

Чтобы объяснить, почему я так думаю, нам нужно взглянуть на проблемы, которые предположительно существуют для решения SPA.

Проблема №1: FOUC, вспышка нестилизованного контента

Это в значительной степени пережиток и миф прошлого, если вы правильно написали свой HTML и CSS. Пока у вас есть относительно небольшое количество хорошо написанного CSS, мало кто из современных браузеров будет демонстрировать такое поведение при первой загрузке. Тем более, если вы сохраняете разделение представления от контента таким образом, чтобы вы предварительно кэшировали внешний вид подстраниц, это просто НЕ ВЕЩЬ, если только вы не вырвете сотни килобайт HTML для выполнения десятков килобайтных задач.

Проще говоря, если вы получаете эту надоедливую «белую вспышку» между загрузками страниц на веб-сайте, HTML и CSS веб-сайта, скорее всего, представляют собой невежественный некомпетентный мусор. См. фреймворки HTML / CSS. Это либо вы используете «JavaScript даром» и / или «скрипты блокировки рендеринга». Одна из многих причин НЕ использовать JavaScript, когда в этом нет необходимости, не помещать скрипты в рендеринг и т. Д. И т. Д.

Это совершенно не проблема, для решения которой вам не нужно тратить больше кода. Во всяком случае, добавление в него большего количества кода в форме JavaScript может только усугубить проблему!

Если это был 2005 год и более 90% пользователей все еще использовали IE6, то это нормально. В 2021 году, когда большая часть мира будет использовать Chrome-лайки, единственная причина, по которой это будет / должно или даже может стать проблемой, требующей решения, - это невежество, некомпетентность и некомпетентность разработчиков.

Проблема 2: время загрузки / экономия полосы пропускания

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

  1. SPA ВСЕГДА медленнее при первой загрузке с пустым кешем. Это жертва, которую вы приносите, пользуясь SPA, потому что у вас больше кода. Если реализовано так, чтобы сценарии исключали постепенную деградацию, это могло бы стоить компромисса на сайтах, где люди посещают множество отдельных страниц. Подумайте о тех, которые ВСЕГДА используют JavaScript для загрузки ВСЕГО контента. Эта первая загрузка контента не только требует дополнительного подтверждения, но и не загружает контент до тех пор, пока не будет загружено все остальное, что находится в очереди. Это может задержать загрузку страницы на секунды или больше в зависимости от того, как браузер расставляет приоритеты, а также от того, бодаются ли сервер или клиент лимитами соединений.
  2. Действительно ли то, что должно быть лишь небольшим количеством избыточной разметки, которую сохраняет SPA, стоит этих болезненных накладных расходов при первой загрузке?

Второй - настоящий камень преткновения, потому что, Честно говоря, ИМХО нет причин для того, чтобы общая разметка всей страницы, НЕ считая область содержимого, превышала 10 КБ. Если и того больше, значит, ваш HTML плохо написан, и наполовину МУСОР! К моменту сжатия разметки ее, скорее всего, не будет и 4 КБ. Вот и все, вы говорите о том, что в большинстве случаев экономия времени на передачу составляет 4 КБ, что составляет едва ли даже два современных пакета.

Именно здесь SPA часто используются скорее как фигня с плацебо, чтобы скрыть плохие практики. В эпоху, когда невежественные люди, не способные написать одну чертову строчку HTML, изрыгают более 200 тысяч чудовищ, чтобы выполнить 16 тысяч операций по переворачиванию разметки, вряд ли удивительно, что многие люди могут быть втянуты в размышления о том, что все это лишнее Материал JavaScript / AJAX «помогает», когда он - опять же - пластырь на дыре от пули.

Вы должны подумать: если то, что вы получаете, является фрагментом HTML, у вас есть накладные расходы на дополнительную копию разметки в виде переменной JS, и парсер должен попытаться вставить / проанализировать это в разметку через innerHTML, будь то на живую DOM или через фрагмент документа. Если, с другой стороны, вы просто отправляете необработанные ДАННЫЕ и используете какую-то функцию «create» или «make» (например, react делает это «под капотом», чтобы прикрепить данные к реальным узлам DOM, у вас снова есть медленно интерпретируемый JavaScript выполнять кучу работы - включая расшифровку любого формата, в котором вы отправляете данные, - вместо того, чтобы просто загружать страницу в обычном режиме.

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

И если эти двое расходятся в реальной производительности на хорошо написанных сайтах, эта «жертва» при первой загрузке с пустым кешем становится не чем иным, как обузой!

Итак, давайте проверим!

В свободное время я сделал две версии одного и того же общего сайта. Один основан на обычной загрузке страниц, другой - это «одностраничное приложение», в котором весь контент загружается через AJAX. Страницы с большим количеством потокового текста загружаются через innerHTML, но я также создал страницу галереи, где сервер отправляет имена и расширения больших пальцев и полноразмерных изображений, а клиентский скрипт загружает их через DOM.

Обе страницы поддерживаются PHP в конструкции «один индекс, чтобы управлять ими всеми», имеют два статических модальных диалоговых окна (логин и контакт) для увеличения «веса» базовой разметки и используют одну и ту же внутреннюю систему шаблонов и CSS. Для удобства я выбрал JSON в качестве носителя данных.

Страницы:

Обычная страница:
https://cutcodedown.com/for_others/medium_articles/spaPlacebo/normal/

Страница SPA:
https://cutcodedown.com/for_others/medium_articles/spaPlacebo/spa/

Архив RAR:
https://cutcodedown.com/for_others/medium_articles/spaPlacebo/spaPlacebo.rar

Если есть какие-то промахи с моей стороны или есть идеи для более справедливого сравнения, я хотел бы это услышать.

Версия SPA ни в коем случае не является полной реализацией. Он не выполняет переадресацию вперед / назад для обновления, а также отсутствует ряд «наворотов». Я просто реализовал достаточно, чтобы мы могли сравнивать необработанное время загрузки для подходов, созданных как с помощью innerHTML, так и DOM.

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

Тем не менее, я сделал несколько наблюдений в собственном тестировании. Единственное, в чем мы можем быть уверены, - это поведение при первой загрузке с пустым кешем. Поскольку у меня есть сценарий «Просто загружается и запускается» прямо перед ‹/body›, легко сказать «да, SPA медленнее при первой загрузке пустого кеша» - конечно, это так, у нас есть два дополнительных файла для загрузки , скрипт и данные JSON для подключения ‹main›.

Нет ни одной вспышки нестилизованного контента!

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

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

Среднее значение первой загрузки пустого кэша за десять прогонов

Обычная загрузка страницы
Домашняя страница: 176 мс
Галерея: 271 мс

SPA
Домашняя страница: 228 мс
Галерея: 336 мс

Разница в ~ 50 мс незначительна, но, конечно, это дает преимущество обычной странице. Этот результат не должен удивлять тех, кто знает, что они делают, поскольку, опять же, более медленная первая загрузка должна быть компромиссом для более быстрых подстраниц.

Время загрузки подстраницы

Это довольно сложно измерить, так как я снова в основном застрял на нем. В обычной версии я могу с уверенностью сказать, что переход с домашней страницы в галерею с пустым, но включенным кешем и возврат назад занимает 145 мс. Если вы заметите сетевой водопад и вкладки производительности в браузере, SPA займет около 150 мс, чтобы перейти на домашнюю страницу, и около 160 мс, чтобы поместить туда галерею. Я считаю, что такая промывка находится в пределах погрешности, вызванной гранулярностью таймера. (никогда не доверяйте разнице менее 35 мс в большинстве программ!)

Единственное место, где мы можем провести твердое сравнение, - это пропускная способность. Мы можем точно знать, что:

Нормальная загрузка страницы
Домашняя страница: размер 8,84 КБ, передано 3,84 КБ (сжатие)
Галерея: размер 4,77 КБ, передано 1,48 КБ (сжатие gzip)

SPA, только JSON
Домашняя страница: размер 6,64 КБ, передано 2,65 КБ (сжатие с помощью gzip)
Галерея: размер 1,05 КБ, передано 648 байт (сжатие с помощью gzip)

Неужели эта разница ДЕЙСТВИТЕЛЬНО настолько велика, что стоит пожертвовать первой загрузкой и усложнить ситуацию с помощью сценариев, которые могут вам даже не понадобиться?

Я слышу, как вы, ребята, уже возражаете, что «этого недостаточно для реального сравнения». Да да это. Потому что это репрезентативное количество контента, который должна / должна содержать самая настоящая веб-страница ... и указывает на настоящую проблему ... неспособность разработчика.

Меня до смерти тошнит от работы над существующими сайтами, где требуется разметка в два-двадцать раз больше, чтобы работать с кодом в два-двадцать раз больше, я вижу это снова и снова, где у вас, ребята, есть HTML, измеряемый сотнями килобайт. две дюжины или меньше работы К.

Бесконечные бессмысленные DIV напрасно, бесконечные бессмысленные презентационные классы, помешанные на разметке из-за ошеломляюще идиотского мусора, такого как буткрап или попутный ветер, полное отсутствие семантики, избыточные / расточительные роли ARIA, META, ни один законный UA не дает наплевать, проприетарный МЕТА, которая, если бы она отсутствовала, вернулась бы к обычным, у вас в любом случае должна быть огромная ‹style› в разметке из-за лжи «рендеринг выше сгиба»… Список причин, которые мы в итоге приводим до смехотворности, можно продолжать и продолжать. раздутая разметка, которая замедляет загрузку ваших страниц, недовольна простотой создания и обслуживания, и говорит пользователям с доступностью, которые должны пойти на самотек!

Заключение

Я не говорю, что нет законных причин для использования подобных технологий на основе SPA или AJAX. Я говорю о том, что многие из причин, по которым люди их используют, - например, ускорение или предотвращение FOUC - больше плацебо, чем факт. Хуже того, потому что это часто приводит к «скриптингу только страниц», вы говорите огромному количеству пользователей, чтобы они отвалили.

.
Если вы чувствуете «необходимость» прибегнуть к этой методологии, гораздо более вероятно, что вы бросаете хороший код за плохим и имеете гораздо более глубокие коренные проблемы, которые следует решать - например, дурацкий мусор, который представляет собой «фреймворки». »- прежде чем вы уйдете и начнете набрасывать больше кода на проблему.

Потому что чаевые большие?

Если кто-то говорит вам, что добавление большего количества кода в виде клиентского JavaScript будет быстрее или лучше, ваш здравый смысл должен поколебать.

.

ПРЕКРАТИТЕ использовать 200 КБ разметки для выполнения работы 16 КБ, ПРЕКРАТИТЕ использовать десятки отдельных файлов для выполнения работы с тремя-пятью файлами, ПРЕКРАТИТЕ полагаться на раздутые CSS-фреймворки с несемантическим кодом, ПРЕКРАТИТЕ вставлять представление в вашу разметку, и, может быть, просто МОЖЕТ БЫТЬ, вы сможете Избегайте всех проблем, которые люди пытаются решить с помощью всего этого «JS бесплатно, а ваши скрипты - бесплатно». ’Потому что это не работает, это не то, как вы это делаете! Дай мне сказать, эти ребята - тупицы!