Одностраничные (spa) и многостраничные (pwa) веб-приложения

Чем отличаются веб-приложения MPA, SPA и PWA, для каких задач подходят. Разбор преимуществ, недостатков и отличий методов разработки.

99

Несколько слов поводу SPA и их "недостатках" (буду высказываться в контексте Vue.js)
1) Для SEO в мире SPA существует SSR (Server side rendering) - Nuxt.js.
Если кратко, то когда пользователь впервые обращается к сайту, то на стороне сервера делаются все необходимые запросы к API для получения данных + "раскрывается" вся html, выполняется еще куча различных действий и в итоге на клиент улетает уже развернутая html, со всеми необходимыми данными, а дальше web-приложение начинает работать как обычное SPA.

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

А если же использовать SPA + SSR, то MPA приложения проигрывают по производительности практически во всех аспектах.

Так же, с помощью SSR мы можем реализовывать следующую технику: загружать только те части js / css, которые необходимы для работы конкретного компонента, т.е. представьте, что у нас есть страница каталога с закрытой картой и с закрытыми фильтрами. Когда мы загружаем эту страницу, то у нас не подгружаются компоненты, связанные с картой и фильтрами (т.к. она закрыты) => размер страницы будет крайне мал, а когда человек включает карту или (и) фильтры, то у нас динамически со стороны сервера подгружаются эти самые компоненты (Code Splitting), крч мы подгружаем компоненты только тогда, когда в них есть необходимость.
И дополню, что Code Splitting работает не только для отдельных компонентов, но и для целых страниц, что очень сильно облегчает размер бандла => скорость отдачи web-приложения на сторону клиента.

3) Утечка памяти: если над SPA приложением работает (ют) квалифицированные разработчики, то я на 99.8% уверен в том, что подобной проблемы не возникнет, т.к. методы / тулзы для профилирования (анализа работы приложения) уже давным-давно вышли на новый уровень и сейчас не эпоха ie6, где люди дебажили (искали баги / ошибки) с помощью alert's. И непонятно, почему этот пункт отнесся именно к SPA, ведь в любом приложении, где есть хоть какая-то логика, может возникнуть подобная ситуация, ни?

4) Поддержка js - я хз, но мы сейчас не в 2001 году, и я никогда (на основе личного опыта) не видел подобных людей, у которых был бы отключен js (исключение - это Opera Mini или всякие proxy browser, доля которых 0.0001% (наобум)), да даже в том же Tor Browser уже по умолчанию включен js (просто знаю).
В дополнении к этому, могу сказать, что для этого в мире SPA, и не только - существует специальная техника, которая называется Graceful Degradation (можно так же посмотреть в сторону Progressive Enhancement, как делает VK и многие другие популярные платформы).

5) Про PWA / TWA даже писать не буду, т.к. для этого нужно писать отдельную статью о том, что в этой статье не так.

Для frontend developer'ов: я постарался выражаться не с точки зрения программиста, а с точки зрения "обывателя", чтобы всем было понятно, о чем я говорю, поэтому примите и простите.

13
Ответить

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

1
Ответить