JQuery против стандартного бэкэнда - PullRequest
10 голосов
/ 16 июня 2009

Мне интересно узнать предпочтения людей ...

Я недавно вошел в jQuery и мне это нравится. Однако я обнаружил, что заменяю многие (несколько тривиальные) бэкэнд-функции (tech: ASP.NET) крошечными функциями jQuery. Например, вместо того, чтобы назначить навигационную кнопку в качестве внутреннего элемента управления и изменить ее класс, когда ее страница находится на странице (т. Е. Выделить кнопку «около», когда на странице «о нас»), я просто проанализировал URL-адрес и добавил класс для кнопки:

var pathname = window.location.pathname;
if (pathname == "/about/") {
    $("#nav-about").addClass("selected");
}

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

EDIT

Я на самом деле не говорю об этом конкретном случае ... Я говорю о небольших улучшениях, подобных этому. Какую черту вы проводите, когда дело доходит до улучшений jQuery или просто делаете это на сервере? Спасибо:)

Ответы [ 10 ]

6 голосов
/ 16 июня 2009

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

Я бы даже сказал, что для каждого одностраничного интерфейса или RIA должна быть альтернатива с несколькими страницами.

Итак, чтобы ответить на ваш вопрос, это определенно то, что вы хотите написать на сервере, а не на клиенте.

5 голосов
/ 16 июня 2009

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

5 голосов
/ 16 июня 2009

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

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

В общем, я бы порекомендовал вам вернуться к серверному коду для этого. Там просто не нужно выбрасывать его.

4 голосов
/ 16 июня 2009

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

Лучше просто сделать что-то вроде серверной стороны (особенно, когда .NET уже создал Sitemap для вас)

2 голосов
/ 16 июня 2009

Как вы знаете, где ударить баланс между добрым старым надежным сервером код, который работает каждый раз и быстро, модный, блестящий JQuery, который работает довольно много каждый раз, кроме случаев, когда пользователь может быть JavaScript отключен?

Это может звучать тупо, но в пользу менее чем 5% пользователей ( и снижение ) несправедливо. Это также станет причиной кошмара пользовательского интерфейса для вас.

Просто не забудьте провести различие между сервером и клиентом. Код на стороне сервера - это просто код, который принадлежит серверу и не влияет на как клиент видит конечный продукт; давайте просто скажем, что он неизменен для клиента. Отображение конечного продукта изменчиво, и время от времени рекомендуется быстро его менять, чтобы обеспечить более глубокое взаимодействие с пользователем.

1 голос
/ 16 июня 2009

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

Тем не менее, я понимаю, что в то же время я люблю использовать jQuery и тот факт, что он дает мне лицензию на выполнение всевозможных классных выходок на стороне клиента за очень короткий промежуток времени. Так что я стремлюсь к созданию системы, которая является надежной (как в старые добрые времена, предшествовавшие всей этой бессмыслице сценариев :) и которая делает то, что должна. Достигнув этого, и для дополнительных похвал (и настоящего представителя) я буду использовать jQuery, чтобы сделать весь пользовательский опыт без компромиссов. Чтобы привести простой пример:

<a class="pageNo" href="/?p={$pageNo}">{$pageNo}</a>

- это ссылка на страницу, щелчок по которой приведет к загрузке результатов в div, реализация выглядит примерно так:

jQuery('.pageNumber').click(function(e) {

            //stop the link from firing
            e.preventDefault();

            //steal the page number from the tag
            var pageNo = jQuery(this).text();

            //assign it to a hidden field
            jQuery('#pageNo').val(pageNo);

            //use $.load to fill up a div with the results
            loadPage(pageNo);


        });

Ссылка указывает на ресурс на сервере, который выглядит как www.random.com/things/?p=2. Функция $.load в jQuery извлекает эту страницу и вставляет ее в div. Если Javascript дает сбой или недоступен, это не имеет большого значения, потому что ссылка срабатывает как обычно, и страница посещается, как в старые добрые времена. Кроме того, сервер настроен на различие между запросом XHTTP и обычным и отвечает соответствующим образом. В этом случае jQuery сделал действительно аккуратное усовершенствование, которое никак не сказалось на аспекте предоставления услуг в проекте.

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

1 голос
/ 16 июня 2009

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

Для меня программирование на стороне сервера должно быть как минимум таким же простым, как на стороне клиента.

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

У Джейсона есть другой подход: код, похожий на JavaScript, но на сервере, посмотрите на ItsNat . В настоящее время работает только на Java, а не .Net: (

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

0 голосов
/ 16 июня 2009

Так как я не могу оставлять комментарии здесь (пока), я ввожу это как ответ, хотя это скорее комментарий. (Хотя, вероятно, не вписался бы в комментарий!)

Для примера, который вы приводите в оригинальном сообщении (и я знаю, что вы сказали, что просите больше из общего, а не из этого конкретного смысла, поэтому я отвечаю общим решением), я предпочитаю это "навигация подсветкой" с чистым CSS.

Например, вы могли бы иметь страницу «о» следующим образом:

<body class="about-section">
  <h1>This is a page in our About section!</h1>
  ...
  <ul id="nav">
    <li id="nav-home"><a href="/">Home</a></li>
    <li id="nav-whatever"><a href="/whatever/">Whatever</a></li>
    <li id="nav-about"><a href="/about/">About</a></li>
  </ul>
</body>

И ваша таблица стилей:

    #nav a {
      color:#00F;
    }
    body.home #nav-home a,
    body.whatever-section #nav-whatever a,
    body.about-section #nav-about a {
      color:#F00;
    }

Добавление и поддержка страниц обрабатывается одной декларацией CSS. Это не требует никакого javascript NOR программирования на стороне сервера; вы просто объединяете класс тела (или другой идентификатор) с элементами, которые вы хотите оформить по-другому.

Удачи!
-Mike

0 голосов
/ 16 июня 2009

Мне самому нравится jQuery, но могут возникнуть проблемы с доступностью и функциональностью, о которых мне нужно беспокоиться. Я часто тестирую страницы с отключенным Javascript, чтобы убедиться, что он будет работать с этой аудиторией (общедоступные терминалы часто отключают Javascript IMHO) и в Lynx, чтобы получить представление о том, как программа чтения с экрана будет видеть мою страницу.

Вы можете проверить свою страницу по ряду инструментов здесь:

http://www.w3.org/WAI/ER/tools/complete

, чтобы обеспечить доступность ваших страниц.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...