Переваги та недоліки створення веб-програми на одній сторінці [закрито]


52

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

Наразі мій прототип - це традиційна налаштування на багато сторінок, проте я шукав backbone.js, щоб очистити та застосувати певну структуру до мого коду Javascript (jQuery). Схоже, що в той час як backbone.js можна використовувати у багатосторінкових програмах, це більше світиться для програм на одній сторінці. Я намагаюся скласти список переваг та недоліків використання підходу до дизайну додатків на одній сторінці. Поки що я маю:

Переваги

  • Усі дані повинні бути доступні через якийсь API - це велика перевага для мого використання, оскільки я хочу мати API для своєї програми. Зараз приблизно 60-70% моїх дзвінків щодо отримання / оновлення даних здійснюються через REST API. Виконання програми на одній сторінці дозволить мені краще перевірити свій REST API, оскільки сама програма його буде використовувати. Це також означає, що в міру зростання програми додаватиметься сам API, оскільки саме для цього використовується додаток; не потрібно підтримувати API як доповнення до програми.

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

Недоліки

  • Дублювання коду - наприклад, код моделі. Мені доведеться створювати моделі як на стороні сервера (PHP в даному випадку), так і на стороні клієнта в Javascript.
  • Бізнес-логіка в JavaScript - я не можу навести конкретних прикладів того, чому це було б погано, але мені просто не подобається мати бізнес-логіку в Javascript, яку кожен може прочитати.
  • Витік пам’яті Javascript - оскільки сторінка ніколи не перезавантажується, може відбуватися витік пам'яті Javascript, і я навіть не знаю, з чого почати їх налагоджувати.

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

Які є переваги та недоліки веб-додатків на одних сторінках, про які я повинен пам’ятати, вирішуючи, яким шляхом я повинен піти для свого проекту?


Basecamp , нова версія basecamphq робить досить непогану роботу з IMO для налаштування однієї сторінки.
Хакан Деріал

Ви можете знайти витоки пам’яті за допомогою хромового інспектора купи: gent.ilcore.com/2011/08/finding-memory-leaks.html
Joeri Sebrechts

обов'язковий xkcd.com/1309
Пітер Б

Відповіді:


17

Найбільшим недоліком є ​​те, що клієнт повинен увімкнути JavaScript і бути достатньо потужним, щоб запустити його досить. Також важче задовольнити проблеми щодо доступності чи будь-чого іншого, що спирається на аналіз статичного HTML (хоча щось, що знає ваш конкретний API, можливо, може зробити і краще, ніж скребтування HTML). Нарешті, легше мати значні витоки пам'яті.

Що стосується дублювання коду або розміщення ділової логіки для клієнта - я не впевнений, скільки ви маєте зробити. Якщо модель на клієнті - це View-Model (модель, яка відповідає світові, як бачить інтерфейс користувача, а не бізнес-модель), то логіка, що відповідає ViewModel до бізнес-моделі, може знаходитися на клієнті, сервер, або трохи обох. Це залежить від того, як ви ставитесь до того, що ваш API містить специфічний для клієнта фасад порівняно з тим, щоб клієнт переводив входи інтерфейсу користувача у виклики API.

Ви також можете подивитися на knockout.js. Я не можу сказати, чи це краще ніж кістяк, але це може відповідати вашому проекту краще.


Так, я здогадуюсь, що більша частина дублювання коду буде перевіряти дані, що добре. Мені добре з тим, що потрібно включити JavaScript, оскільки мене не турбує доступність для цього проекту (наприклад, зчитувач екрана, а що ні). Що стосується проблеми витоку пам’яті javascript, яка викликала мою стурбованість, за посиланням у коментарях мого запитання, яке насправді це заперечує (хром - це мій браузер первинної розробки в будь-якому випадку).
ryanzec

7

Недоліки, які я часто бачу у веб-додатках на одній сторінці:

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

(особливо мобільний :)

  • Завантажувати потрібно дуже довго.
  • Не працює взагалі.
  • Неможливо перезавантажити сторінку, раптова втрата мережі поверне вас до початку сайту.

Все це можна вирішити, але, як я бачив, більшість будівельників сайтів цього не роблять.


9
1,2 і 6 - це в основному символи однієї проблеми. Що автор не використовує API / хеш-посилання історії.
Мартін Хансен

11
Ця відповідь застаріла. Більшість рамок додатків на одній сторінці є способом вирішення вищезазначених питань
Луїс

@Luis, поки технологія є, занадто часто вона не використовується.
Пітер Б

5

Є один важливий клієнт, який ніколи не запускає Javascript: гусеничний гугл Google (станом на 2012 рік) . (Гадаю, Bing також не працює JS)

Вам потрібно буде надати розумну не AJAX версію кожної сторінки, яку потрібно індексувати, або посилання на сторінку, яку потрібно індексувати.

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

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

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


4
Googlebot читає і навіть виконує деякі JavaScript зараз. Дивіться googlewebmastercentral.blogspot.com/2011/11/…
jfrankcarr

2
Для цього конкретного питання це додаток для управління проектами. Напевно, не сайт, гідний SEO.
Йорданія

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


3

-Копіювання коду - Наприклад, код моделі. Мені доведеться створювати моделі як на стороні сервера (PHP у випадку), так і на стороні сервера в JavaScript.

Ви знаходитесь у світі PHP, але у світі .NET існують стратегії генерації коду для автоматичного створення проксі-серверів JavaScript WCF. Дивіться тут

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


0

Вибір не повинен бути тим чи іншим. JWt , наприклад, веб-інструментарій, який реалізує ідеальну ілюзію багатосторінкової веб-сторінки, але це одна сторінка. Крім того, він розпізнає google-боти та браузери, у яких немає JavaScript (спробуйте), і переключиться на традиційну багатосторінкову модель, коли їх виявить.

Коротко:

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

1
JWt - це інструментарій Java. Питання стосується PHP.
Joeri Sebrechts
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.