Опубликован: 01.07.2011 | Доступ: свободный | Студентов: 6707 / 1193 | Оценка: 4.07 / 3.64 | Длительность: 10:34:00
Лекция 3:

Первое знакомство с JavaScript

< Лекция 2 || Лекция 3: 12 || Лекция 4 >

Куда поместить JavaScript

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

При классическом подходе сценарии помещают в заголовке head документа:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-en"> 
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title></title>
 <script type="text/javascript" src="myscripts.js"></script>
</head>
<body>
<!-код HTML здесь ->
</body>
</html>

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

Недостатки состоят в том, что сценарии задерживают отображение документа, и что сценарий не имеет доступа к HTML в документе. Поэтому требуется задержка выполнения любых сценариев, которые изменяют HTML документа, пока документ не завершит загрузку. Это можно сделать с помощью обработчика событий onload (http://www.onlinetools.org/articles/unobtrusivejavascript/chapter4.html) или одного из различных решений DOMready (http://dean.edwards.name/weblog/category/dom/onload/) или contentAvailable (http://developer.yahoo.com/yui/examples/event/event-timing.html) существующих в Web - ни одно из которых не является полностью надежным и большинство использует специфические особенности браузеров.

Специалисты по производительности в последнее время стали предлагать вместо этого размещение JavaScript в конце body:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-en"> 
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title></title>
</head>
<body>
<!-код HTML здесь ->
<script type="text/javascript" src="myscripts.js"></script>
</body>
</html>

Преимущество в том, что JavaScript не задерживает отображение HTML, а также, что уже доступен весь код HTML, который желательно изменить с помощью JavaScript.

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

Поэтому необходимо выбирать, что в большей степени подходит целям web-сайта, можно даже использовать смесь обоих подходов - поместить наиболее важные сценарии в head, и вызывать их в сочетании со сценариями "хорошо бы иметь" в конце документа.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-en"> 
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title></title>
 <script type="text/javascript" src="myimportantscripts.js"></script>
</head>
<body>
<!-код HTML здесь ->
<script type="text/javascript">
applyFunctionality();
</script>
<script type="text/javascript" src="myscripts.js"></script>
</body>
</html>

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

Безопасность JavaScript и ее отсутствие

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

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

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

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

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

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

Методы, которые желательно избегать

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

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

document.write() - можно вывести содержимое документа с помощью document.write(), но при этом возникает несколько проблем: необходимо смешивать код HTML и сценарий и добавлять узел сценария точно в том месте, где должно появится содержимое, что замедляет работу страницы. Это очень привлекательный способ быстро показать (например, в учебнике или при тестировании/отладке кода), каким будет результат фрагмента кода, но это плохой пример, чтобы показывать его людям, так как это никогда не должно использоваться в реальном коде.

<noscript></noscript> - как предполагает название, элемент noscript является противоположностью элемента script. Содержимое внутри него будет показано пользователям, которые отключили JavaScript. Основная причина использования noscript состоит в предоставлении альтернативного контента для пользователей, которые не имеют доступного JavaScript в браузере. Пользователи, которые не имеют JavaScript, делают это не для того, чтобы усложнить жизнь разработчикам - они могут делать это по соображениям политики безопасности, или потому что используемый браузер не поддерживает JavaScript. Но внутри noscript можно представить не так много информации, и, конечно, не стоит использовать это для указания пользователю включить в браузере JavaScript - для некоторых пользователей это невозможно.

<a href="javascript:doStuff()">…</a> - это был очень распространенный способ вызвать функцию JavaScript, чаще всего, когда кнопки были недоступны (в старых браузерах невозможно создавать кнопки). Проблема в том, что это некорректная ссылка, так как javascript не является протоколом интернет (как ftp:// или http://). Если интерпретатор JavaScript отключен, ссылка все равно появляется и создает у пользователя ложную надежду, что что-то произойдет.

document.layers и document.all - оба эти решения были эквивалентами DOM в старых браузерах (Netscape 4.x и Internet Explorer 4, соответственно) и если только вам не требуется их поддерживать (простите, если вы вынуждены), этот код совершенно лишний.

Заключение

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

Контрольные вопросы

  • Что делает следующая ссылка, и какие проблемы это может создавать?
    <a href="javascript: open('tac.pdf')">Read our Terms and Conditions</a>
  • Предоставление параметров для сценариев является мощным средством сделать их повторно используемыми. Очень важно при этом предоставлять компактные и легко используемые параметры. В чем недостатки следующего решения (которое предоставляет параметры, которые компактны и легко используемы)?
    <script src="badge.js">
      var color = 'blue';
      var background = 'yellow';
      var width = 400;
    </script>
  • В чем проблема с так называемыми "глобальными переменными", и как их можно избежать?
  • Где в документе необходимо поместить большой сценарий, который желательно иметь, но он не является жизненно необходимым для работы сайта? Почему?
  • В чем проблема с выполнением сценариев следующего вида:
    <body onload="init()">

Об авторе

Крис Хайлман работает Web-разработчиком уже десять лет, с тех пор как бросил радио-журналистику. Он работает для Yahoo! в Великобритании в качестве инструктора и ведущего разработчика, и осуществляет надзор за качеством кода внешнего представления для Европы и Азии.

Крис поддерживает блог на сайте Wait till I come (http://wait-till-i.com/) и доступен во многих социальных сетях под ником "codepo8".

Фото с разрешения: Bluesmoon (http://www.flickr.com/photos/bluesmoon/1545636474/)

< Лекция 2 || Лекция 3: 12 || Лекция 4 >
Сергей Крупко
Сергей Крупко

Добрый день.

Я сейчас прохожу курс  повышения квалификации  - "Профессиональное веб-программирование". Мне нужно получить диплом по этому курсу. Я так полагаю нужно его оплатить чтобы получить диплом о повышении квалификации. Как мне оплатить этот курс?

 

Галина Башкирова
Галина Башкирова

Здравствуйте, недавно закончила курс по проф веб программиованию, мне прислали методические указания с примерами тем, однако темы там для специальности 

Системный администратор информационно-коммуникационных» систем.
Мне нужно самой найти тему? или делать по высланным темам