НОУ ИНТУИТ | Основы JavaScript. Лекция 3: Первое знакомство с JavaScript

Учитесь и получайте официальные документы БЕСПЛАТНО. Вы можете поддержать наш проект.

Регистрация Вход

Твой путь к знаниям!

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

Темы: Интернет-технологии, Программирование

Специальности: Программист, Разработчик интернет-проектов

|

Вам нравится? Нравится 87 студентам

| Поделиться |

Поддержать курс

| Скачать электронную книгу

Куда поместить 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 и сценарий и добавлять узел сценария точно в том месте, где должно появится содержимое, что замедляет работу страницы. Это очень привлекательный способ быстро показать (например, в учебнике или при тестировании/отладке кода), каким будет результат фрагмента кода, но это плохой пример, чтобы показывать его людям, так как это никогда не должно использоваться в реальном коде.

<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/)

Дальше >>

Авторизоваться

Основы JavaScript

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