В целом: только JS и веб-приложения на основе страниц - PullRequest
6 голосов
/ 29 декабря 2010

При разработке веб-приложения по сравнению с веб-сайтом, какие причины использовать несколько страниц HTML, а не одну HTML-страницу и делать все через Javascript?

Я бы ожидал, что это зависит от приложения - может быть, - но был бы признателен за любые мысли по этому вопросу.

Заранее спасибо.

РЕДАКТИРОВАТЬ:

Основываясь на ответах здесь и некоторых моих собственных исследованиях, если вы хотите создать одностраничный сайт, полностью работающий на JS, некоторые полезные инструменты могут включать:

Подключаемые модули JQuery:

JQuery History: http://balupton.com/projects/jquery-history

JQuery Адрес: http://plugins.jquery.com/project/jquery-address

JQuery Pagination: http://plugins.jquery.com/project/pagination

рамочные:

SproutCore http://www.sproutcore.com/

Каппучино http://cappuccino.org/

Возможно, JMVC: http://www.javascriptmvc.com/

Ответы [ 10 ]

5 голосов
/ 29 декабря 2010

приложений на основе страницы обеспечивают:

  • способность работать на любом браузере или устройстве
  • более простая модель программирования

они также предоставляют следующее (хотя они разрешимы многими js-фреймворками):

  • bookmarkability
  • история браузера
  • Обновить или F5 повторить действие
  • индексируемость (если приложение является публичным и открытым)
2 голосов
/ 29 декабря 2010

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

Выполнение всего в javascript усложнит поисковым системам сканирование всего содержимого вашего веб-сайта и, следовательно, его полную индексацию.Есть способы обойти это (с недавними руководящими принципами SEO AJAX от Google), но я не уверен, что все поисковые системы поддерживают это.Кроме того, это немного сложнее, чем просто создавать отдельные страницы.

Большая проблема, решите ли вы создать несколько HTML-страниц, или вы решите использовать какую-то инфраструктуру или CMS для их генерациидля вас, это то, что различные разделы вашего сайта имеют уникальные URL.Например, раздел about будет иметь URL-адрес, такой как mywebsite.com/about, и этот URL-адрес используется для фактической ссылки about на веб-сайте.

1 голос
/ 29 декабря 2010

По запросу ОП я собираюсь обсудить свой опыт работы с сайтами, предназначенными только для JS.Я написал четыре соответствующих сайта: два JS-heavy ( Slide и SpeedDate ) и два JS-only ( Yazooli и GameCrush ).Имейте в виду, что я фанат JS-сайта, поэтому вы в основном читаете Джона Хинкли на тему Джоди Фостер.

  1. Идея действительно работает.Это производит изящно, отзывчивые сайты при очень низких эксплуатационных затратах.По моим оценкам, затраты на пропускную способность, ЦП и т. Д. Составляют 10% от стоимости работы аналогичного сайта на основе страниц.
  2. Вам нужно меньше, но лучше (или, по крайней мере, лучше обученных) программистов,JavaScript - мощный и элегантный язык, но у него есть огромные проблемы, которых нет у более жесткого и невообразимого языка, такого как Java.Если на вас работает целая куча посредственных парней, рассмотрите JSP или Ruby вместо JS-only.Если вам необходимо использовать PHP, просто застрелитесь.
  3. Вы должны сохранить базовое состояние сеанса в теге привязки.Пользователи просто ожидают, что URL-адрес представляет состояние сайта: перезагрузка, закладка, назад, вперед.Плагин jQuery's Address сделает большую часть работы за вас.
  4. Если SEO представляет для вас проблему, исследуйте Google Ajax Crawling .По сути, вы делаете очень простой параллельный сайт, только для поисковых систем.

Когда бы я не использовал только JS?Если бы я создавал сайт, который был почти полностью наполнен контентом, где пользователь ничего не делал, кроме как переходил из одного места в другое, никогда не взаимодействуя с сайтом сложным образом.Итак, Википедия и ... ну, вот и все.Большой справочный сайт, с большим количеством данных для чтения пользователем.

1 голос
/ 29 декабря 2010

Одним из самых больших недостатков одностраничных сайтов с поддержкой Ajax является сложность. То, что в противном случае может быть распространено на несколько страниц, внезапно попадает в одну огромную главную страницу. Кроме того, может быть сложно координировать состояние страницы (например, отслеживание, если вы находитесь в режиме редактирования или в режиме предварительного просмотра и т. Д.) И настройку интерфейса для соответствия.

Кроме того, одна главная страница, тяжелая для JS, может привести к снижению производительности, если она должна загружать несколько больших JS-файлов.

0 голосов
/ 01 января 2011

stofac, прежде всего, спасибо за ссылку на Манифест одностраничного интерфейса (SPI) (я автор этого скучного текста)

Сказал это, SPI! = Все делал через Javascript

Посмотрите на этот пример (ориентированный на сервер): http://www.innowhere.com/insites/

То же самое в GAE: http://itsnatsites.appspot.com/

Подробнее о подходе GAE: http://www.theserverside.com/news/thread.tss?thread_id=60270

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

0 голосов
/ 31 декабря 2010

Дополнительные сведения можно найти в Манифесте об одностраничном интерфейсе и некоторой (в основном) отрицательной реакции на него в Hacker News (ссылка внизу страницы SPI):

Манифест об одностраничном интерфейсе: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

0 голосов
/ 29 декабря 2010

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

Вот причины, по которым я расстроен:

  • Мне нравитсямногие, я пользователь NoScript и мне это нравится.Страницы загружаются быстрее, я чувствую себя в большей безопасности и избегаю отвлекающей рекламы.Последний пункт может показаться плохим для веб-мастеров, но я не хочу, чтобы кто-то получал вознаграждение за то, что он бросил мне в лицо раздражающие кричащие вещи, если бестактные рекламодатели обанкротились, я считаю это естественным отбором.
    Очевидно, это означает, что некоторыепосетители вашего сайта либо будут отвергнуты, либо испытывают затруднения из-за необходимости предоставить временное исключение.Это уменьшает вашу аудиторию.
  • Вы дублируете усилия.В браузере уже есть отличная функция истории, и вам не нужно заново изобретать колесо, перерисовывая предыдущую страницу при нажатии кнопки «Назад».Что еще хуже, возврат страницы не требует повторного рендеринга.Я предполагаю, что я учусь в школе «Если это не сломано, не починить ее» (из «Не повторяй себя»).
  • Нет HTTP-заголовков, когдаПроходя "страницы" в JS.Это означает, что нет элементов управления кэшем, нет срока действия, содержимое не может быть изменено для запрошенного языка и местоположения, нет значимых ответов «страница не найдена» и «недоступен».Вы можете написать подпрограммы обработки ошибок на своей uber-странице, которые отвечают на неудачные выборки AJAX, но это более сложная задача и переизобретения, она избыточна.
  • Для меня нет кеширования, без прокси не может работать эффективнои кэширование имеет наибольшее из всех эффектов снижения нагрузки.Опять же, вы можете имитировать некоторое кэширование в своем приложении JS, но это еще больше усложняет и резервирует, увеличивает использование памяти и в целом ухудшает пользовательский опыт.
  • Время начальной загрузки больше.Загружая столько Javascript при первом посещении, вы вызываете более длительную задержку.
  • Большая сложность JavaScript означает больше отладки в различных браузерах.Обработка на стороне сервера означает отладку только один раз.
  • Расстойка (средство отслеживания ошибок) оставила плохой вкус.Один из моих самых неприятных веб-опытов был вынужден использовать эту услугу со стороны работодателя.На первый взгляд, он хорошо подходит;JS-тяжелый раздел является закрытым, поэтому не нужно беспокоиться о поисковых системах, его будут использовать только повторные посетители, поэтому имейте время отключить защиту и не обращайте внимания на начальную загрузку библиотеки JS.
    Но это использованиеJS бессмысленен, большая часть контента статична.«Страницы» все еще выбирались (через AJAX), поэтому задержка такая же.С преимуществом AJAX он должен опрашивать в фоновом режиме, чтобы проверить изменения, но я не буду получать уведомления, когда видимая страница была изменена.Разделы имели разные стили, поэтому при их обходе происходил неуклюжий рендеринг, загрузка внешних таблиц стилей с помощью Javascript - это Bad Practice ™ .Простота использования была принесена в жертву из-за быстрых возможностей «взглянуть на наш Web 2.0».Такое бизнес-ориентированное приложение должно быть сконцентрировано на скорости поиска, но в итоге оно оказалось медленнее.
    В конце концов мне пришлось отказаться от его использования, так как это нарушало рабочий процесс команды.Это плохо для отношений между клиентом и поставщиком.
  • Динамические страницы сложнее сохранить для автономного использования.Некоторым мобильным пользователям нравится загружать файлы заранее и отключать их, чтобы сэкономить электроэнергию и данные.
  • Динамические страницы труднее анализировать программами чтения с экрана.Хотя число слепых пользователей, вероятно, меньше, чем у тех, кто пользуется NoScript или мобильной связью, игнорировать доступность непростительно, а в некоторых странах даже незаконно, см. «Закон о дискриминации инвалидов» (1999 г.) и «Закон о равенстве» (2010 г.).

Как уже упоминалось в других ответах, "Прогрессивное улучшение", nee " Ненавязчивый Javascript ", является лучшим подходом. Когда мне требуется создать сайт только для JS (помните, я не возражаю против этого в принципе, и бывают моменты, когда он действителен), я с нетерпением жду возможности осуществления вышеупомянутого сканирования AJAX и надеюсь, что в будущем он станет более стандартизированным.

0 голосов
/ 29 декабря 2010

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

.. оно стало грязным

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

Таким образом, родился мой Франкенштейн.

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

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

  • Затопление глобального пространства имен (если у вас еще нет собственного ... создание одного )
  • Организация кода может легко получить... из-под контроля
  • Контекст - очень просто

Я уверен, что есть еще ...

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


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

Идея слишком ...

  1. Разработка хорошо отформатированного, полнофункционального приложениябез любого JavaScript
  2. Стиль
  3. Оберните все это с помощью JavaScript

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

0 голосов
/ 29 декабря 2010

Выполнение всего на одной странице с использованием ajax повсеместно нарушит функциональность браузера / кнопку возврата назад и будет раздражать пользователя.

0 голосов
/ 29 декабря 2010

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

...