Является ли обычной практикой минимизация использования JavaScript при создании сайта? [закрыто]

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

Это хороший / уважаемый подход?

У большинства программистов есть инстинкт сокращения всех видов кода. Чем меньше кода, тем меньше сложностей и меньше точек возможных ошибок в указанном коде. Это правило относится к Javascript так же, как и к другим языкам. Ты просто придерживаешься традиции.

Используйте Javascript по мере необходимости / желательно на страницах HTML ... но нет причин использовать его, когда он на самом деле не нужен.

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

И есть много фреймворков, таких как JQuery, чтобы обойти браузер несовместимости. ИМХО, сегодня нет реальной причины, по которой вы должны ограничивать себя, не используя Javascript для своего веб-сайта - единственная причина может заключаться в том, что вы его не используете.

РЕДАКТИРОВАТЬ: другой вопрос заключается в следующем: если вы должны предоставить некоторые минимальные функциональные возможности вашего веб-сайта, когда у ваших посетителей не включен JS - это в основном хорошая идея, по причинам, указанным некоторыми комментаторами.

РЕДАКТИРОВАТЬ 2: безусловно, для каждого веб-сайта необходимо найти баланс между удобством для пользователя, удобством для поисковых систем и усилиями по разработке. ИМХО сегодня Javascript может помочь улучшить этот баланс - если использовать его с умом. Сказал, что я думаю, что больше нет необходимости вообще сводить к минимуму использование Javascript сегодня, чтобы сохранить этот баланс. Используйте это с осторожностью, и не демонизируйте это.

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

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

Вы должны изучить концепцию «прогрессивного улучшения», когда вы создаете сайт для работы без javascript, а затем добавляете слой javascript сверху, чтобы улучшить взаимодействие с пользователем. Таким образом, у вас будет сайт, который, по крайней мере, будет полезен людям без JavaScript.

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

Другие ответы, похоже, сосредоточены на том, «не должен ли я когда-либо использовать JavaScript», поэтому я думаю, что они упускают суть. Вы не должны использовать JavaScript, если вам это не нужно. Некоторые люди используют JavaScript для всего :

• Эффекты наведения (должен быть CSS)
• AJAX (должен иметь, hrefкогда это разумно)
• Позиционирование (должно быть CSS)

Преимущества такие вещи, как:

• Сайт отображается быстрее
• CSS значительно менее сложен, чем JavaScript в большинстве случаев
• Наличие резервных hrefссылок помогает поисковым системам, пользователям, которые хотят открывать ссылки на других вкладках, и пользователям, которые ненавидят JavaScript

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

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

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

Вам действительно нужно оживить это?

... или ...

Действительно ли необходимо обходить весь DOM для такого тривиального селектора? Не могли бы вы ограничить это с помощью контекста, и нужно ли нам это в первую очередь?

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

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

Я считаю, что, будучи относительно новым и молодым веб-разработчиком (около 4 лет), мне пришлось много исследовать этот вопрос, поскольку javascript есть везде.

Что я пытаюсь сделать в своих проектах, так это убедиться, что сайт функционирует без javascript, а затем добавить javascript там, где это имеет смысл (проверка на стороне клиента, улучшение пользовательского интерфейса и т. Д.). Это своего рода прогрессивное улучшение, которое заботится о SEO, отключенном JavaScript и несовместимости старых браузеров.

Этот же вопрос был задан на SO, но я не могу ради любви вспомнить, где.

Использование JavaScript может быть ограничено в нескольких случаях:

• Проверка. Это должно быть сделано на стороне сервера. Иногда в веб-приложениях происходит быстрая проверка на стороне клиента, но одного этого недостаточно.
• Чрезвычайно важные задачи. Пользователи могут отключить скрипты своих браузеров, поэтому код JS не будет работать вообще. Если вы хотите быть уверены, что что-то будет работать в любом случае в любом браузере, не доверяйте это JS.
• Скорость. Код JS должен быть отправлен клиенту, и чем больше кода вы пишете, тем больше времени занимает. Хотя небольшие объемы кода не будут иметь практического эффекта.

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

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

1. Контентно-ориентированные сайты . В первом случае магические слова - это «прогрессивное улучшение»; ограничьте JavaScript избыточными функциями, которые могут быть предоставлены с классическим доступом к контенту через простой HTTP.

2. Веб-приложения . Для приложений вы используете Интернет вместо программной платформы. Приложения основаны на некоторых предположениях относительно доступного программного обеспечения - современные браузеры, последние версии популярных библиотек javascript, доступ к рабочему столу с помощью мыши и / или планшетов с поддержкой multi-touch.

Интернет как программная платформа

Минимальные требования к доступу приемлемы, если вы действительно создаете приложение - вы нацеливаетесь на какую-то конкретную платформу, чтобы получить расширенные функции, которые невозможно построить иначе. Это похоже на разработку для Python, Java или .Net. Не позволяйте таким модным словечкам, как HTML5 и обещанию «бежать куда угодно», обмануть вас; Вы можете иметь переносимый код между устройствами, только если на них поддерживается вся платформа. Любые изменения в стеке разработки, и программное обеспечение сломается.

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

Интернет как доставка контента

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

• Мобильные устройства, поддерживающие меньше, чем самые последние и самые дорогие навороты
• Старые пользователи браузера, которые не могут (на предприятии) или не знают (дома), как обновить
• Будущие версии популярных движков, которые не поддерживают свои старые API

Вы потеряете их все, если вам потребуется текущая порода javascript, которая постоянно развивается. В этом контексте сломанный JavaScript, который препятствует доступу к контенту, является грехом.

Каждый, кто говорит, что «использование javascript должно быть сведено к минимуму», поддерживает этот стиль. Это нормально , чтобы включить некоторые JS, заметьте, но все функции должны быть избыточными с основными Accesss к контенту , который может быть достигнут на стороне сервера:

• Проверка ввода данных
• Обновление содержимого AJAX для быстрой навигации (которая, тем не менее, работает без JS)

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

Я работаю в правительстве штата, и в результате большая часть моей разработки связана с интерактивными веб-сайтами, основанными на данных. Запросы к историческим данным, отправка форм и тому подобное. Мы держим наш Javascript на абсолютном минимуме по следующим причинам:

1) Проверка входных данных формы всегда должна происходить на стороне сервера, а не на стороне клиента. Если вы попытаетесь проверить свои входные данные на стороне клиента, все, что нужно сделать хакеру, - это создать локальную копию вашей веб-страницы и переписать Javascript, чтобы разрешить то, что он хочет вам отправить (внедрение SQL и т. Д.). Ваша проверка должна проходить где-то под вашим исключительным контролем, то есть на сервере.

2) Многие пользователи либо отключают Javascript, либо используют браузер, который может не реализовать его должным образом. Будучи правительством, мы должны поддерживать всех, даже если они используют действительно ДЕЙСТВИТЕЛЬНОЕ старое оборудование. HTML работает везде; Javascript, не так много. Не используя Javascript на своих веб-страницах, вы предоставляете им очень малую площадь на клиентском компьютере, используя мало ресурсов. Это максимизирует количество людей, которые могут получить доступ к вашему контенту. По той же причине, вы не должны быть слишком сумасшедшим с вашим CSS. Сохраняйте это простым, держите его в чистоте, и пусть маленькие старушки увидят ваш сайт, даже если их компьютер был куплен в 1999 году (кстати, мы получаем звонки в службу технической поддержки от таких людей).

3) Javascript, будучи инструментом, предпочитаемым «веб-разработчиками», а не программистами на стороне сервера, имеет тенденцию быть довольно уродливым. А дизайнеры (каковыми обычно являются веб-разработчики, если вы хотите быть честными в этом), как правило, не видят проблемы с загрузкой «скриптов» из случайных мест в сети. Они говорят такие вещи, как "зачем изобретать велосипед?" и "Не изобретено здесь". Поэтому вместо того, чтобы писать собственный код, они часто просто выходят и берут что-то с другого сайта, думая, что если это в Интернете, то это честная игра. С этим есть две проблемы: A) они могут непреднамеренно опубликовать какой-нибудь вредоносный Javascript, который займет у вас некоторое время, чтобы поймать, и B) они могут нарушить чьи-то авторские права и привлечь вас к ответственности. Обе ситуации следует избегать.

В общем, Javascript - плохая идея. Любой код на стороне клиента - плохая идея. Клиентская сторона должна содержать только язык разметки и CSS; позвольте серверной стороне справиться с тяжелой работой.

Это зависит.

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

Примеры включают в себя:

• поисковые системы (Google запускает некоторый javascript, но, конечно, не все, и если вы используете навигацию для javascript, поисковые роботы могут не найти весь ваш контент)
• агрегаторы и скребки
• текстовые браузеры (хотя их используют не многие)
• программы для чтения с экрана и другие средства для чтения
• (некоторые) мобильные браузеры

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

Старомодный подход полностью устарел. Например, я сделал ajax-удаление для модератора на одном из сайтов, и он просто счастлив из-за очевидного увеличения скорости.

Конечно, разработчик может сделать две версии как для пользователей JS, так и для пользователей, не являющихся JS, но в большинстве случаев это чрезвычайно дорого и не стоит 1-2% аудитории сайта (если вы, конечно, не Google).

Поэтому мой ответ будет НЕТ - JavaScript - это ответ на многие вопросы, связанные с пользовательским интерфейсом, почему я не должен его использовать?

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

Создание приложений для клиентов - это не только скорость и безопасность. Заказчик хочет сосредоточиться на удобстве использования и использовании технологии AJAX. Без использования JavaScript это не сработало бы так хорошо. PostBacks все время для некоторых очень маленьких задач, таких как расчет или что-то подобное, для большинства компаний не вариант.

Когда мы думаем о текущей ситуации в крупных компаниях, есть еще один показатель, почему JavaScript в настоящее время является обязательным. Посмотрите на системы CMS, которые в настоящее время работают в бизнесе. Большинство из них используют Microsoft SharePoint или Adobe CQ, некоторые из них Drupal или любые другие и так далее. Все эти системы опираются на JavaScript. Без javascript большая часть приложения не будет работать, как того ожидают пользователи.

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

Многие корпоративные сети отреагировали на это отключением JS, политика, которая (правильно или неправильно) все еще существует во многих организациях сегодня.

Проще говоря, я полагаю, что ни один сайт не должен полагаться на JS для работы

Как объясняет большинство ответов здесь, использование javascriptне вредит. Если вы хотите сохранить свой код и грязно выглядящий исходный код, попробуйте, coffee-scriptчто сэкономит много усилий при наборе текста javascript.

http://coffeescript.org/