×Закрыть

Багатосторінкові та односторінкові додатки, їх переваги та недоліки

Анотація. В даній статті розглянуто що таке багатосторінкові (Multiple Page Application — далі MPA) та односторінкові (Single Page Application — далі SPA) додатки, їхні основні переваги та недоліки.

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

Аналіз останніх досліджень і публікацій. Протягом усього часу стрімкого розвитку веб-технологій було випущено велику кількість книг та публікацій, зокрема дослідженням переваг та недоліків створення MPA та SPA займались Васцо Феррейра та Пауль Шерман.

Постановка завдання. Основним завданням, яке поставлене при написанні статті, є дати визначення, багатосторінкових та односторінкових додатків, визначити переваги та недоліки кожного з них.

Виклад основного матеріалу

Сьогодні веб-сайти все більше виглядають як додатки з багатьма можливостями взаємодії, а не статичними сторінками, які ми мали близько 10 років тому. З одного боку, причини цього полягають у спробах користувачів отримувати та створювати інформацію на основі їхніх особистих характеристик та вимог. З іншого боку, власники веб-сайтів хочуть надати користувачам більш зручні інтерфейси користувача для роботи з інформацією.

Давайте подивимося, як ми можемо побудувати інтерфейсну частину веб-сайтів. Існує два основних способи побудови веб-сайтів сьогодні: більш сучасний спосіб — це багатосторінковий додаток (MPA) — більш традиційний спосіб, а також односторінковий додаток (SPA). Почнемо з багатосторінкового підходу.

Багатосторінковий додаток (MPA) складається з декількох сторінок із статичною інформацією (текстом, зображеннями тощо) та посиланнями на інші сторінки з тим самим вмістом. Під час переходу на іншу сторінку браузер робить новий запит до сервера і знову завантажує всі ресурси, навіть ті компоненти, які повторюються на всіх сторінках (наприклад, заголовок, нижній колонтитул). Таким чином, продуктивність витрачається на завантаження тих самих елементів. Відповідно, це впливає на швидкість і продуктивність. Основними технологіями для такого типу веб-сайту є HTML та CSS. Дані технології використовувались для розробки найперших веб-сайтів, та продовжують використовуватись сьгодні, для створення сучасних веб-сайтів. Принцип роботи даного підходу зображено на рисунку 1.

Рисунок 1. Принцип роботи багатосторінкового додатку

Під час розробки веб-сайту може виникати потреба в більш складних інтерактивних компонентах (наприклад, у формах). У цьому випадку ви все ще можете використовувати традиційний спосіб розробки, але ви будете обмежені стандартними функціями HTML технології. Проте існують більш підходящі технології для нестандартних, складних та інтерактивних речей, такі, як JavaScript та AJAX. Розвиток Web 2.0 став можливим завдяки еволюції цих технологій. На сьгоднішній день, за допомогою цих технологій, можна створювати складні форми, різні анімації, діаграми та графіки з динамічним оновленням, не перезавантажуючи всіє сторінки, а лише ту частину сторінки, в якій відбулися зміни.

Недоліки багатосторінкових додатків

  • Розробка як десктопної, так і мобільної версії веб-сайту займає значно більше часу;
  • Збільшує вартість змін при додаванні нових функціональних можливостей в додатку.

Переваги багатосторінкових додатків

  • Багатосторінкова (MPA) архітектура дозволяє легко оптимізувати кожну сторінку для пошукових систем. Розробник може додати мета-теги для будь-якої сторінки;
  • Як правило, для розробки багатосторінкової програми потрібен менший стек технологій, таким чином вартість таких додатків виходить дешевшою.

Односторінкова програма (SPA) — це додаток, що працює в браузері з метою забезпечити користувачу досвід близький до користування настільною програмою. Його архітектура побудована таким чином, що при переході на нову сторінку оновлюється лише частина вмісту. Таким чином, немає необхідності повторно завантажувати ті самі елементи. Це дуже зручно для розробників та користувачів. Прикладом технології SPA є реалізований сервіс Gmail компанією Google. Для розробки SPA використовується одина з найпопулярніших мов програмування — JavaScript. На рисунку 2 наведено принцип роботи односторінкових додатків.

Рисунок 2. Принцип роботи односторінкового додатку

Невеликий веб-додаток може бути зроблено за допомогою бібліотеки jQuery. Але слід зазначити, що jQuery є дуже поганим для розробки великих проектів. Перш за все, це пов’язано зі структурою коду. Для створення складних проектів рекомендується використовувати більш потужні фреймворки, такі як React, Angular чи Vue. Їхня архітектура дозволяє створювати гнучкі веб-додатки і до того ж вони мають в собі великий набір готових рішень, що значно спрощує процес розробки. Крім того, на основі цих фреймворків можна створювати повноцінні мобільні додатки.

Недоліки односторінкових додатків

  • Погана SEO оптимізація. SPA працює на основі JavaScript і завантажує інформацію за запитом від клієнтської частини. Пошукові системи навряд чи можуть імітувати цю поведінку. Оскільки більшість сторінок просто недоступні для сканування пошуковими роботами.
  • Продуктивність та оптимізація. Необхідно пам’ятати про мобільні пристрої та пристрої з низькою продуктивністю, оскільки в односторінкових програмах використання JavaScript який має великий розмір. Також слід пам’ятати про розмір пакету, якщо проект великий, то його слід розбити на окремі компоненти з динамічним завантаженням, щоб покращити швидкість загрузки додатку.

Переваги односторінкових додатків

  • Висока швидкість. Оскільки SPA не оновлює всю сторінку, а лише необхідну частину, це значно підвищує швидкість роботи додатку.
  • Висока швидкість розробки. Готові бібліотеки та фреймворки забезпечують потужні інструменти та велику кількість готових рішень для розробки веб-програм.
  • Мобільні додатки. SPA дозволяє створювати мобільні додатки, оскільки розробник може повторно використати той же код бекенда для веб-додатка та власної мобільної програми.
  • SPA може ефективно кешувати будь-які дані. Програма надсилає лише один запит, кешує всі дані, після чого може їх використовувати і навіть працювати у режимі офлайн.

MPA чи SPA?

Кожна архітектура має свої переваги та недоліки і добре підходить для конкретного типу проекту. SPA відрізняється своєю швидкістю і здатністю розробляти мобільні програми на основі готового коду. Але в той же час, SPA має погану SEO оптимізацію під пошукові системи. Таким чином, ця архітектура є відмінним підходом для соціальних мереж, закритих спільнот, де оптимізація пошукових систем не має значення. MPA більше підходить для інтернет-магазинів, бізнес-сайтів, каталогів тощо. Добре оптимізований MPA має високу швидкість, але все одно не дозволяє легко розробляти мобільний додаток. MPA та SPA з правильною архітектурою добре підходять для розробки масштабованих веб-додатків.

На даному етапі розвитку WEB, односторінкові додатки швидко витісняють класичні додатки і є великим внеском у розробку масштабних, швидких, динамічних веб — систем. Однак технології реалізації front end частини web-додатків потребують додаткового дослідження в контексті вибору кращих альтернатив для реалізації систем під конкретні вимоги користувачів чи замовників продукту.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

основной недостаток во всей этой кухне — хтмл.

Лично меня сам по себе html раздражает, на вид он как сплошной говнокод и копипаста, на нем нельзя программировать как на C#/Java или JavaScript.
И эта дрочка со стилями, как буд-то карточный домик собираешь — на миллиметр сдвинул и весь дом в кучу смешался.
Это все мое имхо. Я туда ни ногой ни за какие деньги.

Істину глаголите. Занадто складно все в верстці сайтів. Я мало що тямлю але здається там уже половина всіх конструкцій це костилі. Я в андроїді верстав і там в мене все одразу виходило і все зрозуміло. Я розумію що екран менший. Але все ж. Потрібна революшн!

П.с. не просто копіпаста а свалка.

на нем нельзя программировать как на C#/Java или JavaScript.

Денис Попов с вами несогласен)))

HTML не мова програмування, а мова розмітки документів.

Хоча я програмую саме на HTML.

<code>
  <h1>
    <if expr="user.active">
      <class>active</class>
    </if>
    <value>user.name</value>
  </h1>
</code>

Щось фігово недоліки пропрацьовані
Недоліки MPA:

  • Кожна сторінка — це купа одноманітної роботи по побудові не тільки контенту, а й всіх інших елементів на сторінці, таких як менюшки, сайдбари, фільтрашки й інший мотлох, стан якого треба відновляти при кожному запиті. Це тонни коду.
  • Без фреймворків воно летить погано, або низько-низько. А фреймворки — шлях до безглуздої витрати ресурсів.
  • Через постійну обробку мотлоху та фреймворки є проблеми із швидкістю оновлення сторінок, особливо тих, які надають функції фільтрації даних. Прискорити можна тільки в один спосіб — через домішування SPA. Вітаю, ентропіє!

Недоліки SPA:

  • Неможливість контролювати витрати ресурсів на клієнті. Якщо клієнт гальмує, то прискорити його неможливо в принципі. А значить, що можна швидко досягати максимумів в функціональності.
  • Клієнт має обмеження по технологіям та не має можливості їх змінити. Додати бібліотеку із швидкою реалізацією певного алгоритму? Забудь! Додати іншу мову? Не в цьому житті!
  • Моніторинг роботи клієнта тільки жере ресурси та погіршує й без того поганий стан.

Вы в каком году мпа делали?))) Еще бы айфреймы вспомнили, в мПа тоже есть шаблонизаторы и шеред компоненты

Це так але дані туди всерівно треба гнати кожного разу. Хоча це вирішується в різних фреймворках по різному і в результаті ти маєш окремі компоненти з своїми вюхами і кверями до бази чи репо, а в контролерах просто повертаєш вюху пейджа яка встроюється в темплейт де і інші компоненти спокійно вставляються аля хтмл тег. Коротше це істина нах! Я пів року пилю апі і теж вже підзабув як в мпа все легко! Shame on me

Легко, тому що фреймворки за тебе роблять багато роботи.

І що? Хай роблять. Для цього вони і створені.

Я не проти. Без них взагалі важко. Я писав це в оригінальному пості. ;)

Я SPA робив ще в 2005му році. Під IE6. Як ти вважаєш, в якому році я робив MPA?

На сьогоднішній день існує два принципових підходи до створення веб-додатків: традиційні веб-додатки, велика частина логіки яких виконується на сервері, а також односторінкові додатки, де логіка користувача інтерфейсу виконується переважно в веб-браузері, а взаємодія з веб-сервером здійснюється головним чином через веб-API.

П-ф-ф-ф-ф.. Є й третій варіант, SPA із логікою та темплейтуванням на сервері.

SPA добрий коли ти бекендер, і в команді є фронтендер. Робиш АПІ, при чому універсальну як для сайтів так і для моб. додатків, а з жс потім хай морочиться фронтендер як хоче і ліпить там що хоче. В результаті розділяються обовязки, і при побудові стабільного АПІ можна вже не перейматися нічим, бо всі баги вилізатимуть і фікситимуться на клієнт сайді.

У них разные области применения. SPA идеальны там, где пользователь должен проводить какие-то сложные манипуляции с данными — отборы, поиск, сортировки, группировки, сравнения. Например на сайте интернет-магазина для выбора товаров по нескольким характеристикам. Или в облачных CRM/ERP системах.
MPA лучше использовать там, где нет сложных манипуляций с данными, а пользователь просто потребляет контент — форумы, блоги, социальные сети, новостные сайты. MPA обычно проще SPA и поддерживать их дешевле.

Вот например страница выбора ноутбуков в Розетке: rozetka.com.ua/notebooks/c80004/filter
Здесь идеально использовать SPA. Вытащил один раз с сервера полный список ноутбуков, а потом с помощью переключателей в левой части экрана делай какие-хочешь отборы с кучей условий. При этом данные уже закешированы на клиенте и нет нужды каждый раз лезть на сервер, когда пользователь изменяет условия отбора.

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

Ты это сам себе нафантазировал? Когда кликаешь на фильтры оно тьму разметки с ноутбуками уже зарендереную на сервере аяксом берет и нихрена ничо не кэширует. Там вообще от спа только игры с url остались. Все делается по взрослому серверным рендерингом иначе ясно было бы что бы было в противном случае.

Так я и не говорил, что на Розетке используют SPA. Я привел эту страницу как пример для возможного применения SPA.

Аааа. Ну дык раньше вся страница розетки полностью бралась за один запрос с бэкэнда. Видно что чуваки нашли разумную точку между «сделать вебсайт реально живее аяксом» и «угробить превратив в глючное spa как линкедин». Выбрать абсолютно все ноутбуки? Серьезно?

Не вижу здесь никаких проблем. «Абсолютно все ноутбуки» это несколько сотен моделей, то есть json весом максимум в пол мегабайта.

ну ладно на розетке дураки сидят. почему на амазоне тогда не отдают все ноутбуки

Через таких фанатиків деякі сайти глючать навіть на ноутах, не кажучи про мобілки.

До речі усі дані не грузять навіть в мобайл апах, а там швидкість роботи нативна. Тягнути в й так важкі спашки усе за раз це геніально. Хочеш один ноутбук глянути — прийдеться тобі пару мегабайт скачати. Так посидиш на сайті і трафік як на ютюбі з фул хд.

весом максимум в пол мегабайта.

1. Яким чином ви підрахували?
2. Це мало? А тепер думаємо що ноутбуки активно фільтруються і пів мегабайта стає 10 мегабайт. Ой сорян, тут протупив. Тоді рахуємо як це клієнту видавати усі дані по ноутбукам щоб можна фільтрувати, і потім як воно буде тормозити і скільки важити.

Also

это несколько сотен моделей

3203

imgur.com/a/wCPMFvw

Ну і на кінець: обмежувати кількість доступних ітемс бо хочеться на фронт вигружати все за раз це неадекват(як власне і грузити більше ніж потрібно для вирішення завдання, типу економія ресурсів, ага). На щастя такого неадеквату рідко зустрічаєш, бо вирішують не фанатично упороті в обмежені ідеї кодери.

Блин, я уже жалею, что влез в этот срач. Дам окончательный ответ и уйду. Можете считать себя победителями.

1. Я не предлагаю загружать ВСЕ товары на сайте одним запросом. Речь идет о небольших категориях в несколько сотен позиций. Если категория большая то конечно нужна разбивка на подкатегории, либо пагинация.

2. Неразумно лезть на бекэнд с запросом если клиент поменял отбор внутри категории, или скажем сделал возрастающую сортировку вместо спадающей. С этим прекрасно справиться браузер.

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

4. У SPA действительно есть недостаток. Они могут не работать или глючить в старых браузерах или некоторых мобильных браузерах. Так что интернет-магазин потеряет какой-то процент покупателей сидящих на IE6, зато существенно выиграет на производительности за счет уменьшения нагрузки на сервера. Так что пусть просто решает для себя, где потери меньше а выигрыш больше.

5. SPA работает через API, которые так-же можно использовать для мобильного приложения либо интеграции со сторонними сервисами. Если делать все на бек-энд, то такой возможности не будет.

Речь идет о небольших категориях в несколько сотен позиций

Невеликі категорії це фіксовані категорії. Всі інші категорії мають сприйматися як незкінченні. Товари це є незкінченні листи.

конечно нужна разбивка на подкатегории

Лол. Тобто замість пагінації і фільтрів робити 100500 сторінок? Клевер.

Неразумно лезть на бекэнд с запросом если клиент поменял отбор внутри категории, или скажем сделал возрастающую сортировку вместо спадающей

Це як раз таки розумно. Нерозумно витягати всі товари щоб нагружати браузер лишній раз. В цьому я розуму не бачу взагалі(крім свербіжу витягти на фронт побільше).

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

Можна. Але не треба. Кеш для постійно змінюючихся даних є нерозумним рішенням і лишньою витратою місця. В результаті всерівно прийдеться перекачувати цей кеш, і перекачувати більше, ніж потрібно, коли видаєш малими порціями і тільки тими що відфільтрував користувач. Крім того кеш все ускладнює.

Так что интернет-магазин потеряет какой-то процент покупателей сидящих на IE6, зато существенно выиграет на производительности за счет уменьшения нагрузки на сервера

Якась жіноча логіка. Тобто те що мене як клієнта почнуть грузити більше, а сервер компанії менше — я залишуся більш лояльним цій компанії? Яке мені діло до серверу? Жарт про IE6 не смішний, виглядає як дитячий.

Так что пусть просто решает для себя, где потери меньше а выигрыш больше

Всі і вирішують. Саме тому не роблять ту нісенітницю яку пропонуєте ви. Тим більше для інтернет магазину. Те що ви пропонуєте підійде для чогось якраз таки простого, а не монстрів як інет магазини. Знову ж таки апелюю до того як роблять мобайл апс. Якщо ви захерачите спа що буде працювати неадекватно по вашому, то легше буде скачати мобайл ап. Може це таке спонукання клієнтів перейти на мобайл ап, хто зна =)

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

Вибачте, але це яким боком до нашої теми? Ви пропонуєте товстий SPA. Ви б мали догадатися що товстий SPA якраз протирічить можливості легкої інтеграції апі для інших типів клієнтів. Важко повірити що розробник зі стажем такого простого не розуміє. Робимо товстий сервер — дістаємо одинаковий відтестований функціонал для усіх видів клієнтів. Крім того клієнти стає легше розробляти. Профіт, ваш КЕП.

Якась жіноча логіка. Тобто те що мене як клієнта почнуть грузити більше, а сервер компанії менше — я залишуся більш лояльним цій компанії?

У меня новый процессор и тележка памяти (32 гига вагоном называть было бы некорректно) и я еще не видел веб-приложения, способного хоть сколь серьезно его нагрузить. Поэтому мне все равно что там переносится нагрузка на клиент. Но не все равно на то как быстро я вижу результат после нажатия чего-либо. Я для того и тратился на железки чтобы все быстро работало, а не меряться в справедливость типа «ой это ж они свой сервер экономят».

Лооооол. Ппць. Тобто щоб юзати ссані сайти мені вже треба топовий ігровий пк мати? Ви в своєму розумі? Та я в арму з меншими характеристиками ганяю.

У меня

Я злився...

Покупать комп и трястись чтобы приложение использовало только серверные ресурсы, а не мои — вот это лол и ппц

Ні, я тепер щоб вийти в веб змушений буду зберати лише ігрові пк. Все ясна панятна. Це пабеда. тільки от якщо до такого доведуть ідіоти деви, то всі перейдуть на мобільні і десктоп додатки. Але такий зомбі апокаліпсис неможливий, по причині малої кількості зїхавших з розуму фронтендерів.

Даєш всі бази сайтів мені на комп. І хай в мене все працює на локалці. Я ж комп купив ігровий, йопта!

от якщо до такого доведуть ідіоти деви, то всі перейдуть на мобільні і десктоп додатки

Ну когда купите себе смартфон и пройдет года два-три, тогда вы узнаете что в сегменте мобильных приложений уже давным-давно разработка ведется только под свежие модели. И чтобы получить свежую операционку — нужно покупать свежий смартфон, так как смартфоны обновляют на одну-две мажорных версии, и всё. Ваше нытье о сайтах вообще ни о чем. У меня лежит древний ноут, и на нем можно без проблем лазить по сайтам, если терпения хватит дождаться загрузки с hdd. Что там у вас за деревянный пк, что его SPA нагружают — я не знаю.

Свіжі моделі не значить топові моделі. І свіжі не значить що андроід пятого покоління відрубали бо вийшов андроід сьомого покоління. Ви продовжуєте видавати бажане за дійсне. А так, відрубають лише тоді коли апішка устаріла, а не тому що в ап забили те що мав бек виконувати. Клієнтоорієнтованість, ага. Не бачу далі сенсу щось вам писати.

У меня

Ви тут еталон правди. Я це вже зрозумів. А те що у мене від спа комп з ноутбучним ай3 і інтел хд грузився дофіга і пейдж лагав то таке, всьо врьоте. У вас же ж нада даждатса лише доки прогрузиться, ага. А ще доки якусь херь з 10к записами не скачає, бо фронтендеру чеше десь. Ок, далі розмова не має сенсу.

Як же я радий що розвиток технологій вирішують не такі обмежені в своїй області люди як ви. Стільки упоротих ідей вже викидалося, на щастя. Все таки є всесвітній розум у цому світі.

Ну и живите со своим ноубучным ай3, вам вообще не обязательно пользоваться сайтами и приложениями

Ну и живите со своим ноубучным ай3, вам вообще не обязательно пользоваться сайтами и приложениями

Це такий жирний тролінг? Я просто сиджу тут в шоці з загальної вашої аргументації, але цим ви мене добили. Не вірю що це не тролінг.

Куда уж мне до вашей аргументации:

Тобто те що мене як клієнта почнуть грузити більше, а сервер компанії менше — я залишуся більш лояльним цій компанії? Яке мені діло до серверу?

Это же какой ужас и вселенская несправедливость — клиент грузит комп!

Клієнт грузить комп більше ніж у конкурента, при тому функціонал одинаковий => йду до конкурента. Саме так. Тормозні сайти мені не подобаються. До речі, я вам не рекомендую йти в мобільну розробку, бо там ще й батареї людям посадите з таким мисленням.

Я повторюсь. На щастя рішення приймають не такі як ви, і я як клієнт не потерпаю від ідіотських рішень в розробці. Є виключення звісно, подекуди зомбі пробиваються.

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

Та у вас пече бо ви абсолютно наглухо закриті в ваших СПА. Ви увірували в СПА і більше нічого не чуєте і не бачите. Це дитяча поведінка, не більше. А всі хто вам реальні аргументи наводить, що не все так просто і кожне технічне рішення має бути обдумане, і зроблене як краще, ви його називаєте тролем. Завтра спа подохне придумають щось нове ви знову увіруєте в нове. Таке життя, коли обєктивості мислення нема.

Та у вас пече бо ви абсолютно наглухо закриті в ваших СПА. Ви увірували в СПА і більше нічого не чуєте і не бачите. Це дитяча поведінка, не більше.

Посмотрите в зеркало

Я привів овердофіга аргументів(і вони до речі максимально обєктивні). Якщо ви щось не бачите — протріть очі від своєї віри. Але так, практика показує що переконати фанатиків це завдання impossible. Удачі вам. Пішов я звідци.

Ваши аргументы все сводятся к «комп нагружают!!!!» и «каждый раз грузить!!!». Если бы мир прислушивался к таким как вы — жили бы все в пешерах. Может вы не в курсе, но даже голый дом нагружает браузер. И CSS. Не нагружать клиента — это клепать простые текстовые страницы без стилей. А вместо корзины в интернет-магазине ставить надпись «позвоните нам», а то все эти заказы и оплаты нагружают.

Я ніде не писав що клієнта навантажувати непотрібно взагалі. Я писав що робити це треба лише при необхідності, а не тому що жс девелоперу захотілося перетягти на фронтенд всю базу даних. А економити ресурси це хороша риса для розробника. Якщо економія проста, а пагінація це дуже проста економія багатьох ресурсів. Крім того на беку я можу зберати моделі, а не просто видавати базу. Зберати моделі також їсть ресурси, серверу. Джойнити таблиці їсть базу. Але ні, треба будь яку херь робити лише б упоротому жс бою догодити.

Коротше в ваших ідеях нема ні турботи про клієнта, ні турботи про бек-енд розробників. Ви джекі чан, дартаньян і на всіх вам на.рать.

В заключення напишу(я виписав здається достатньо щоб не продовжувати цей срач з biased front-end developer). Клієнт має бути настільки товстим, щоб зручно комунікувати з back-end API і відображати його результати. Все. Якщо клієнт бере на себе обовязки back-end — це поганий клієнт(якщо він не є з самого початку клієнтським додатком як то онлайн фото редактор).

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

Ну если теоретически количество записей неограничено и есть сервер-сайд пагинация — то сортировку на фронте не выполнишь. А если до тысячи элементов — не должно быть проблемой совсем.

А если до тысячи элементов

І як часто ви можете на 100% бути впевненими що буде не більше 1000 елементів? І не тому що ви вважаєте що сайт не вистрілить, чи базу не забють, і просто тупо обмежуєте його ріст, а тому що там логічно не може бути більше елементів? Отож бо. Такі варіанти одиничні. А будувати ап під одиничні випадки це абсурд.

и есть сервер-сайд пагинация

Пагінація має бути на будь-яких списках, які є логічно необмеженими. Тобто для більшості списків. Крім того зробити її це як 2+2 на калькуляторі обрахувати. Не кажучи вже що пагінація є універсальною. Зробив один раз і під усі таблиці.

SPA идеальны там, где пользователь должен проводить какие-то сложные манипуляции с данными — отборы, поиск, сортировки, группировки, сравнения

Маячня яка ніякого відношення до клієнт сайду не має. Все це має робитися на сервері(а точніше сервером формуватися запит до бази даних. Переносити базу даних на клієнт? рилі?), а клієнту видавати готові результати пошуку. SPA це симуляція апу в браузері. Щоб зрозуміти що туди треба пихати, треба подивити як роблять мобільні апи, і там де спа недостатньо потужний ще й урізати. А мобільні апи жоден не загружає усі дані, окрім тих для роботи яких задумано офлайн режим, і де дійсно скачується все, але все це не один листинг, а всі дані. І це завантаження займає десятки а то і сотні мегабайт. Грузити треба рівно стільки скільки потрібно мені як користувачу, а не що захотілося розробнику. Сайт який мені забиватиме кешем комп бо я відкрив якусь сторінку соковижималок чисто з цікавості — більше відкриватися не буде. Ну і само собою за один запит не вийде, бо завтра якісь ітемс видалять, якісь додадуть, а на якісь зроблять знижку. Що тепер — качати кожного разу по мегабайту?

Ну і само собою за один запит не вийде, бо завтра якісь ітемс видалять, якісь додадуть, а на якісь зроблять знижку. Що тепер — качати кожного разу по мегабайту?

Какое завтра? Кеш SPA находиться в оперативной памяти и актуален пока открыта вкладка браузера. Это уже просто смешно.

Тобто ви пропонуєте весь час викачувати всі дані. Це дійно смішно. Не менш смішно ніж якби ви пропонували зберігати щось на завтра.

пока открыта вкладка браузера

Закрив вкладку — все пропало. Качай по новій, ібо нехай щастить вкладку закривати, скотина, москалюка ти така! Тут до речі виплив цікавий недолік СПА — воно не є справжнім апом і в бекграунді не зберігається.

Закрив вкладку — все пропало. Качай по новій

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

Носять те що треба, а не весь магазин бітів і байтів, щоб потім дома вибрати необхідне.

Хороший тролль должен выполнить дневную норму, прежде чем его покормят.

Це ви про себе я так розумію.

а як вам MPA, який складається з кучі SPA (MSPA?), до такого ваші дослідники вже дійшли? :)
Я б не сказав що SPA аж витісняють MPA, швидше їх знайшли де приліпити і там ліплять при потребі.. )

Собственно выбор не между MPA или SPA (количеством страниц) — а между «тонким клиентом» и «толстым клиентом». И этому выбору больше лет, чем Интернету! Потому что начиналось все с выбора между центральной ЭВМ с терминалами или персональной ЭВМ в чемоданчике.
Браузеры и концепция веб-страниц изначально разрабатывались как тонкие клиенты. И в этом отношении продолжают успешно выполнять свою работу: сайт на чистом HTML + CSS с минимумом скрипта может быть ничем не хуже для пользователя. При этом браузер не кушает ресурсы клиента, разработчикам не надо беспокоиться про утечки памяти, а страницы может свободно редактировать любой дизайнер или даже сам хозяин сайта.
Откуда вообще возникло SPA? Посему именно одна страница? Главная причина — с одной страницей можно было сделать что бы браузер выглядел на мобильных устройствах как приложение. Т.е. изначально цель не сделать лучше — а угодить моде на мобильные приложения!
Не-мобильному пользователю нету разницы он переходит по ссылке внутри одной страницы или на другую страницу. Если очень нужно перегружать только часть страницы — ифреймы есть в чистом HTML и это можно делать вообще без скрипта.
Все остальные преимущества SPA довольно спорные:
— собрать HTML скриптом на клиенте быстрее чем загрузить готовый с сервера?
— перейти на другую страницу в браузере или удалить и добавить новый контент всей страницы скриптом?
— кэшировать данные на клиенте забивая память или подтягивать из серверного кэша?
— загружать весь контент сайта сразу, или только первую страницу?
— играться с событиями на клиенте, выгребая проблемы с асинхронностью и вешая колбеки на колбеки или принимать запрос и отдавать результат?
Но главная проблема в другом: если для «серверных» сайтов технологии и библиотеки давно разработаны и обкатаны, то для «клиентских» SPA они только появились и до сих по сырые.
Те вещи, которые на сервере есть «из коробки»: контейнеры зависимостей, обработка ошибок, телеметрия, перфоманс каунтеры, криптография, таймзоны, локализация, тестирование, обработка изображений да и сама сборка проекта — на клиенте требуют подобрать и подружить между собой целый зоопарк скриптовых фреймвоков. Сделать это непросто — поэтому сплошь и рядом в SPA приложениях возникают проблемы с утечкой памяти, с последовательностью событий, с порядком заргузки и т.д. Очень часто оказывается что пользователь нажал и ждет — а в скрипте вылетела ошибка (которая видна только в консоли) и весь SPA «остановился». Иногда просто перезагружая SPA страницу несколько раз можно получить каждый раз разные ошибки.
Мое мнение: пытаться превратить «тонкий клиент» — браузер в «толстый» — полноценное GUI приложение это «просунуть верблюда в игольное ушко». Для создания GUI приложений есть другие технологии, которые намного стабильнее и проще.
Даже на старом Делфи можно было без строчки кода собрать GUI приложение с массой меню, контролов, закладок и гридов. Что бы создать такое-же в браузере нужно очень постараться!

Пользуясь случаем спрошу. Медиаплеер для аудио-подкастов с активным вперед|пауза|назад функионалом в виде SPA — это разумно/приемлемо, если контент все равно будет частично кэшироваться на клиенте или тяжело и лучше делать нативно?

Медиаплеер это скорее контрол или виджет, а не приложение. Не совсем понятно что тут нужно делать: в HTML 5 уже есть все что бы показывать медиаплеер «из коробки». Если нужно мобильное приложение то и там контролы для этого есть готовые.
Лично меня, как пользователя, вполне устраивает когда по ссылке на сайте открывается мой системный плеер. Зачем изобретать велосипед?

Дело частично в аудио-контенте, а частично в его подаче, этих функций нет в системном медиа-плеере. Например вот этот сайт нужно адаптировать под мобайл еще больше? www.babeleo.com

Отличная иллюстрация к тому, что я писал про SPA!
У меня при заходе на www.babeleo.com виден только заголовок и «крутилка», которую наши тестировщики в багах давно называют «wheel of death». В консольке сыпется «Blocked loading mixed active content».
Так что минус один пользователь у вас уже есть благодаря жабаскрипту. А теперь подумайте о том разнообразии браузеров и настоек, которые бывают у других пользователей. И это не говоря уже про пользователей с ограниченными возможностями!
Мне кажется что для пользователя качество приложения, его простота, удобство, надежность и доступность намного важнее, чем модные фреймвоки и несколько секунд перфоманса.
Модные фреймвоки и базворды нужны что бы выступать на конференциях и собирать инвестиции.

Ок, но если все равно есть необходимость в дополнительном функционале, которого нет в штатном плеере и потребность подтягивать подкасты кусками, тогда как правильнее пилить клиентскую часть?

Если вы хотите свой плеер — то выбора как-бы и нет. На скрипте можно управлять стандартным плеером, но написать полностью свою обработку аудио с самостоятельным кэшированием потока — это только в нативном приложении.
Инженер от «самоделкина» отличается тем, что инженер в первую очередь ищет как просто решить задачу, используя готовые решения. А «самоделкин» априори считает что он придумает лучше — и мастерит 5 колесный велосипед.
Именно поэтому вместо 1-2 серьезных джаваскрипт фреймвоков имеем сотни поделок для одного и того-же.

Нет, обработка аудио, меня не интересует, скорее реакция на метки, зашитые в метаданные к файлу.

Так что минус один пользователь у вас уже есть благодаря жабаскрипту.

Благодаря кривым рукам

ИМХО но SPA пошли после того как задолбались возиться со стейтом на бэк-энде ну и когда начинаешь увлекаться айаксом на странице то мысли сам приходят — а нафига мне каждый раз дергать сервер и колбасить одну и ту же страницу в 100 раз чтобы дорисовать нужные данные или перерисовать форму по новой?
SPA отделяет мух от котлет — есть стейт на фронте и его море вьюшек, а есть данные на серваке. Это в идаеле конечно ;-)

Так что до места про мобилки я с тобой согласен — извечаня борьба между тонким и толтсым клиентом.

Откуда вообще возникло SPA? Посему именно одна страница? Главная причина — с одной страницей можно было сделать что бы браузер выглядел на мобильных устройствах как приложение.

Бобёр, выдыхай!

AJAX существовал и был в моде ещё 10 лет назад, когда дорогими и продвинутыми мобильными устройствами считались какие-нибудь нокии N-серии (или этой серии вообще ещё не было). И этот аякс пихался в сайты для пк.

AJAX это еще не SPA. Аяксом можно грузить и HTML и XML для трансформации на клиенте. И да — его использовали на обычных многостраничных сайтах в нужных местах задолго до SPA.
Так же на джаваскрипте было множество виджетов и контролов, которые вообще не использовали AJAX.
SPA — это не просто джаваскрипт или AJAX, это «философия» все делать на одной странице! Даже если визуально пользователь переходит к другому разделу сайта и все меняется — мы программно чистим дом, отписываем ивенты (и часто — не до конца) вместо просто загрузить новую страницу.
Никто ведь не запрещает сделать многостраничный сайт, на каждой странице которого будут нужные джаваскрипт контролы, будет AJAX что бы подгружать данные... Но нет — философия требует все-все делать на клиенте и на одной странице. Почему? Единственную причину я уже назвал — быть похожим на мобильное приложение.

перейти на другую страницу в браузере или удалить и добавить новый контент всей страницы скриптом?

Даже на старом ноуте ember рендерит страницу со скоростью, незаметной для глаза. И этот фреймворк не считаетс ябыстрым в плане рендеринга (vue писали на своем сайте что у них быстрее). Медленно это если насвинячить с версткой и CSS или загружать много информации в десятке запросов.

играться с событиями на клиенте, выгребая проблемы с асинхронностью и вешая колбеки на колбеки или принимать запрос и отдавать результат?

Ну кто виноват разработчику, если он не умеет готовить современный JS?

Ну кто виноват разработчику, если он не умеет готовить современный JS?

Большую часть программ можно написать на чистом С ! Более того: ее можно написать так, что бы потом скомпилить под все платформы. Почему все девелоперы не пишут на С? Потому что правильно написать на С — это сложно и долго!
Все было бы прекрасно с SPA, если бы фреймвоки для него были достаточно зрелые! Формошлепство не должно требовать глубоких знаний — например для GUI приложений было и есть масса инструментов как клепать UI мышкой. При этом такие приложения умеют ловить и обрабатывать ошибки, в них не течет память (если девелопер не налажал), они загружаются и работают одинаково.
Что я вижу на SPA сайтах: ошибки валятся в консоль и приложение «останавливается», или после загрузки что-то «непрогрузилось», или с каждым переходом по ссылке отжирается все больше памяти... Почему? Да потому что что бы этого не было девелопер должен глубоко понимать как там все внутри устроено и понимать что ошибка может вылететь в любое время, колбэк может не вызваться и ему нужно это все предусмотреть самому! Нужно «уметь готовить современный JS» — а это не проще, чем уметь готовить рыбу Фугу.
Естественно никто не хочет тратить кучу времени на затыкание всех потенциальных проблем в UI. Все таки UI — это не главная часть приложения. Поэтому большая часть SPA сайтов работает по принципу happy path — если что пошло не так то пускай пользователь перегружает страницу.
Особенно если вместо опытных фронтенд — гуру мы берем модных «фулстек» девелоперов, которые знают всего понемногу. А иначе глупо выходит: написать UI на джаваскрипте сложнее и дороже, чем всю серверную логику приложения!
В то же время простой HTML сайт, написанный по стандартам, будет работать во всех браузерах и на всех устройствах, будет поддерживать индексацию, читалки, пользовательские CSS, закладки, при переходе по страницам браузер будет все очищать... И написать такой UI в разы проще, чем SPA приложение!

Нужно «уметь готовить современный JS» — а это не проще, чем уметь готовить рыбу Фугу.

Для повара, готовящего фугу регулярно — да, проще фугу. Для программиста, пищущего каждый день на JS таки проще готовить JS.

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

И выглядят как все программы на делфи?

Нашо нам Ваша курсова робота? Ну, мпа-спа. Усі давно вже визначилися. Це ж не Хабр, де за інвайт потрібно шось «пристойне» та «офіційне». Все значно простіше

даже на реферат не тянет, скорее доклад на 3 минуты на паре

Переваги односторінкових додатків
Висока швидкість. Оскільки SPA не оновлює всю сторінку, а лише необхідну частину, це значно підвищує швидкість роботи додатку.

Це мало схоже на реальність. Класичний набір веб-сторінок набагато легше та швидше.

Если их отдавать с локального сервера, поднятого тут же на машине разработчика 😂

причем делать это в проде)

А шо прод? «У меня все работает» ©️

Я ХЗ звідки віддаються ваші SAPи, але таке враження що десь з Антарктиди. Не кажучи вже про те, що вони машину грузять майже як IDEA.

Мобільні додатки. SPA дозволяє створювати мобільні додатки, оскільки розробник може повторно використати той же код бекенда для веб-додатка та власної мобільної програми.

а в МРА в чем проблема?

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

Подписаться на комментарии