Какие скриптовые языки поддерживают браузеры
Ваш браузер настроен для оптимального просмотра страниц? Вы можете добавлять интерактивные элементы на страницу, изменять размер картинок в реальном времени. Как это сделать? Активируйте JavaScript. Рассмотрим, как использовать браузер с поддержкой JavaScript.
Что это такое
JavaScript — язык программирования. Применяется для создания динамических сайтов, приложений для смартфонов. Предоставляет возможность менять страницу в онлайн режиме. Изменения происходят сразу, не требуют перезагрузки страницы. Отключение JavaScript в обозревателе приводит к невозможности открытии ссылок. Как ее включить.
Яндекс.Браузер
Internet Explorer
Открываем настройки (значок шестеренки):
Перейдите:
Активируйте пункты как на скриншоте:
Изменения произойдут после перезагрузки ПК. Появится доступ к страницам, требующим активацию JavaScript.
Google Chrome
Перейдите:
Далее:
Откройте:
Выберите соответствующий пункт.
Перезагрузите страницу, чтобы активировать изменения.
Mozilla Firefox
Версия браузера начиная с двадцати третьей не требует ручной активации. Функция включится автоматически. Если установлен обозреватель старой версии — обновите его.
Opera
Установите «свежую» версию обозревателя. В последних версиях JavaScript активируется автоматически.
Браузер с поддержкой Java Windows
Не путайте технологию Java и JavaScript. Между ними есть разница. Java используется для создания приложений работающих автономно или открывающихся в обозревателе. JavaScript работает только в обозревателе. Его скрипт помещается в HTML-файл для обмена данными между браузером и страницей.
Браузер с поддержкой Java 2018 — устанавливаем плагин
Активация плагина
Установив Java активировался доступ к плагину. Проверьте его работоспособность.
Internet Explorer
Откройте раздел «Безопасность». Как это сделать было рассмотрено выше. Перейдите:
Активируйте опцию:
Google Chrome
Разработчики начиная с версии сорок два запретили запускать Java..
Firefox
Последние версии не поддерживают работу плагина. Чтобы задействовать технологию, скачайте старую версию браузера. До пятидесяти второй.
Java работает где используется технология NPAPI. Поддерживается не во всех обозревателях. Рассмотрим браузеры совместимые с этой технологией.
Pale Moon
Рекомендую использовать людям со слабомощными ПК. Разработчики поддерживают Java на всех платформах. Подробнее посмотрите в статье: «Конкурент популярным браузерам». Java активируется автоматически после инсталляции.
UC Browser
Яндекс Браузер поддержка Java
Официально работа с Java прекращена с 2016 года. Поэтому в свежей версии Яндекс.Браузера активировать ее не получится. Функция активна в старых версиях обозревателя. Не рекомендую устанавливать ее. Обозреватель будет незащищенным от злоумышленников.
Вместо вывода
Разработчики используют JavaScript при создании сайтов. Поэтому чтобы они корректно отображались, активируйте данную функцию.
Java считается устаревшим стандартом. Используется редко. Если возникло желание открыть старую игру, или протестировать программу в обозревателе — установите Pale Moon.
Какие есть особенности, преимущества и недостатки у Perl, Python, Ruby, Tcl, Lua?
Пробовал гуглить, находил такое сравнение, но тут нет Tcl, и идёт сравнение мелких деталей синтаксиса.
Какие есть нормальные сравнения этих языков? Какой язык стали бы изучать вы и почему?
Если вы какие-то из них уже хорошо знаете, то чем каждый из них вам нравится или не нравится и почему?
Perl — старьё
Python — говно
Ruby — хипстерство
Tcl — старьё
Lua — годнота
Иди ты в википедию, желательно со срезаным скором, чтоб неповадно было.
zloelamo ★★★★ ( 07.09.13 17:45:44 )
Последнее исправление: zloelamo 07.09.13 17:46:17 (всего исправлений: 1)
Самый практичный из них — пестон.
Что есть «нормальное сравнение»?
У меня скора на шесть звёзд, так что.
А википедия — это не то, там сравнение даже хуже чем на гиперглоте.
Xenius ★★★★★ ( 07.09.13 17:55:23 )
Последнее исправление: Xenius 07.09.13 17:58:12 (всего исправлений: 1)
Типа обзорной статьи, автор которой не является фанатом ни одного из языков.
Это не будет объективное сравнение, это будут мысли автора. Истина рождается в споре.
Ну, лучшего всё равно придумать нельзя. Не питон же в конце концов. Мне лично нравится lua-cb.
Все они динамически типизированное говно. Из них Perl и Python - платформы, Perl - замшелая и всё менее нужная, Python - вполне приличная.
Все они динамически типизированное говно.
А что тогда не говно? Хаскель?
Семейство ML, очевидно.
для каких целей то? или сферическое в вакууме сравнение нужно?
Как язык? *ML и, надеюсь, будет Rust.
Но я как-то сомневаюсь, что тебе нужен именно _язык_. Какой прок даже в хорошем языке, если у него нет библиотек и инструментов?
Хаскель - игрушка академиков и стенд для исследователей. Применять его могут только эстеты для одноразовых поделок.
Ради повышения кругозора и ещё выбора языка для решения тех или иных задач
или сферическое в вакууме сравнение нужно?
Из перечисленных ruby рвёт всех. И не надо верить слухам о его тормозах: он так не тормозит. На самом деле он тормозит минимум в 2 раза больше.
Плиз, дайте ссылку, где даётся объективное [1] сравнение производительности популярных скриптовых языков (обязательны: perl, ruby, python, tcl). Гугл даёт что-то левое и не удовлетворяет сноске [1].
[1] Объективное = не предвзятое, со множеством тестов (регекспы, io, вычисления. ).
не найдёшь
инфа 100%
гуру одного языка != гуру другого языка
потому тесты некорректны сами по себе
а с скриптовых ещё и куча делитантов/ламо - тут даже среднестатистический не показатель
успокойся
Не вижу там tcl
они _все_ ортогональны производительности
> Производительность скриптовых языков
ты себе и девушку выбираешь по массе мышц, цвету диплома или сколько литров пива она может выпить за 5 минут?
они все одинаково тормозные. серьезно.
Какая разница в 1100 раз что-то медленее сишечки работает или в 1200?
Если надо высокопроизводительный высокоуровневый язык с динамической типизацией, бери лисп. Вон SBCL по производительности можно вплоть до уровня Си надрочить, да и даже круче, если встроенным ассемблером пользоваться.
Все что в произвольно взятом скриптовом языке есть, там тоже есть(я имею ввиду, обычно какую-то конкретную скриптоту берут ради какого-либо определенного фреймворка, ну типа рабби для рельсов и т.п., но тебе походу все равно какой брать, так что проблемы нет). Базовый минимум библиотек берется в quicklisp'е, дополнительное - ну модули на си и прочем можно писать, как и в скриптовых языках. Встраивать тоже можно, по идее(я недавно ECL собрал - все ништяк работает, встраивается очень легко).
зато всё остальное есть
по идее groovy из-за того что транслируется в байт-код jvm должен рвать их всех по производительности, так что в приведенной во втором комменте ссылке цифры для явы относятся и к груви
раз тут предлагают встроенные ассемблеры и компанию - типа джита,то вообще питон круче выйдет - его можно овер шедскин в плюсы конвертнуть и скомпилять :3
А что, давно это плюсцы автоматически означают высокопроизводительный код?
Я тебя уверяю, я видел на плюсах проекты, которые работали быстрее после переписывания не то что на Java, так на тот самый Python.
ну. как писать
привет миры в разы быстрей овер конвертор
а если выхлоп ещё и перелопатить.
Вот как достало это бредовое, но распространенное, мнение, что де если есть какой-то язык под JVM, значит работать он будет так же быстро, как Java.
JVM такая штука, что заточена под один конкретный язык, угадай какой. И соответственно, более-менее быстро на JVM работает только он. Серьезно, жабовая виртуальная машина была спроектирована, да и сейчас дорабатывается, так, чтобы на ней именно и только Java и работала быстро. Это даже в названии у нее указано, прикиньте.
Плюс, Java - очень строгий язык, со статической типизацией, его легко компилировать в эффективный низкоуровневый код.
Другие JVM-языки, и особенно те, которые на Java нисколько не похожи, и особенно с динамической типизацией(типа IronPython etc. - зацените кто-нибудь на досуге), на JVM тормозят так, что их реализации и аналоги вне JVM кажутся просто каким-то адовым космолетом на термоядерном топливе.
По теме может кто-нибудь сказать? Без обсуждения — зачем это надо. И без рекламы лиспа и си. Я специально тему создавал не в Talks.
Учитывая, что в быстром темпе жизни все читают только начальные и конечные слова поста, закончу повтором:
обязательны: perl, ruby, python, tcl
Сначала скажи, зачем тебе это.
Хливких шорьков напикать.
Теперь по плану реклама Лиспа.
Ну тогда выбери один из них, смотря по тому, что тебе надобно с ними делать, и не мучайся.
ппц как тут трудно добиться прямого ответа на вопрос. Позовёте меня, когда будете рецепт яичницы с помидорами обсуждать?
Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками.
Возможности Groovy (отличающие его от Java):
— Статическая и динамическая типизация
— Встроенный синтаксис для списков, ассоциативных массивов, массивов и регулярных выражений
— Замыкания
— Перегрузка операцийБолее того, почти всегда java-код — это валидный groovy-код.
отличный тест, СИшка почти на одном уровне с питоном идёт.
лучше озвучь свою задачу
JVM такая штука, что заточена под один конкретный язык, ugoday какой.
JVM такая штука, что заточена под один конкретный язык, угадай какой. И соответственно, более-менее быстро на JVM работает только он. Серьезно, жабовая виртуальная машина была спроектирована, да и сейчас дорабатывается, так, чтобы на ней именно и только Java и работала быстро. Это даже в названии у нее указано, прикиньте.
синтепончик, ты вот адекватный чувак, но пока не вылезаешь за Lisp-domain, ну вот зачем ты это сказал, чтобы с тебя пруф попросили?
ппц как тут трудно добиться прямого ответа на вопрос.
какой вопрос задал, такие и ответы получи
Позовёте меня, когда будете рецепт яичницы с помидорами обсуждать?
говорящие помидоры. 111
Другие JVM-языки, и особенно те, которые на Java нисколько не похожи, и особенно с динамической типизацией(типа IronPython [..]
JVM - мать-героиня, и своих детей кучу вынашивает, и чужих не чурается
Блять, ну перепутал, вот придрался, а.
Jython имелся ввиду, да.
это лавсан то адекватный.
Давай прежде чем делать умный всёзнающий вид, оговоришь, какие именно пункты и тезисы вызывают сомнения?
Хотя, сначала попробую угадать. Я так понимаю, тебя смущает тезис о том, что рантайм JVM является субоптимальным для динамических языков, для функциональщины, а также языков с объектной моделью, отличной от жабовой(т.е. с прототипным ООП, с мультиметодами и т.п.)?
Ты никогда не думал, что для всех этих разных моделей языков программирования, нужны разные рантаймы, которые проводят разную оптимизацию, и оперируют совершенно разными объектами, и создать одну оптимальную для всех них платформу - невозможно(даже, допустим, x86е процессоры под такую не подходят, и заточены они фактически только под си-подобные языки(которые суть статическая типизация плюс единая линейная неуправляемая виртуальная память); но хрен с ними с процессорами, раз уж мы про VM работающие поверх них)? Не думал?
Если думал, могу продолжить. Если не думал - ну в этом случае я продолжать не буду, так как с дураками разговаривать бесполезно.
Я долго и честно терпел, но, наконец, не выдержал. Может мы вместе можем разобраться?
Итак, предположим некто решил создать _новый_ скриптовый язык. И, допустим, называет его Ruby. Давайте попробуем понять — зачем вообще это нужно делать? Что мы ожидаем от скриптового языка? Все это, на мой взгляд, достаточно очевидно, но желающие могут и похоливарить, конечно. Например, можно расписать преимущества и недостатки примерно так:
— новый синтаксис, требующий изучения;
— невысокая производительность в сравнении с native-кодом;
— автоматическая сборка мусора;
— синтаксический сахар;
— runtime-типизация;
— runtime-расширяемость объектов.
Примерно так. Таким образом, создатель скриптового языка первым делом _отказывается от производительности_ ради других преимуществ. Это очень важное архитектурное решение и мы вернемся к нему позже.
При создании нового скриптового языка — нужна связь VM (виртуальная машина, испольняющая скрипт) скрипта и внешнего мира. Нужны модули, библиотеки, фреймворки и прочие имплементации, простите мне это старинное русское слово. Рассуждая о возможностях того или иного скриптового языка, приверженцы скриптовых культов могут обсуждать следующие совершенно различные темы:
— о синтаксисе и удобстве самого языка (например, встроенный eval());
— о удобной реализации некоего функционала, который реализуется некоей библиотекой (например, регулярные выражения или встроенный веб-сервер);
— о скорости выполнения вычислений «внутри» VM (например, сортировка массива);
— о скорости выполнения вызовов из VM во внешний мир (библиотеку, ОС) (например, запись в файл).
Так вот. К скриптовому языку имеет отношение только первый пункт. Только он.
Все остальное имеет отношение к реализации. Не к самому языку.
Если скриптовый холиварщик рассуждает не о первом пункте, то ему следует тогда отметить, что он рассуждает уже не о языке, а о платформе: конкретной реализации скриптового языка на конкретной ОС или на конкретной VM.
Первый тезис. Преимуществом скриптового языка не может являться наличие библиотек, которые реализуют тот или иной функционал. Все это зависит исключительно от реализации скриптового языка. Возьмем, например, эту статью:
Здесь описывается реализация www-сервера на Ruby.
Но что здесь, собственно, от Ruby?
Вот смотрите я только что написал www-сервер на JavaScript:
var www_server = new WebServer('127.0.0.1', 3456);
Он принимает запросы и отдает файлы. Верите? А у меня есть такая вот реализация ввв-сервера. И теперь вы знаете, что JavaScript — хороший язык и на нем легко создавать веб-сервера, да? Вы знаете или не знаете?
Кстати, на JavaScript также легко запустить будет Doom 4. Ну, когда он выйдет. Вот смотрите:
var doom4 = new Doom4();
Клево, правда? В следующих бутылках мы продолжим знакомство с javascript, а теперь возвращаемся к нашей теме.
Берем теперь уже конкретно Ruby. Уж, извините, попался мне под руку, но это мог быть и любой другой язык, в принципе.
Вот, например, я читаю возможности Ruby и слегка офигеваю.
"
Имеет лаконичный и простой синтаксис, частично разработанный под влиянием Ада, Эйфель и Python.
Позволяет обрабатывать исключения в стиле Java и Python.
Позволяет переопределять операторы, которые на самом деле являются методами.
Полностью объектно-ориентированный язык программирования.
Не поддерживает множественное наследование, но вместо него может использоваться концепция «примесей», основанная в данном языке на механизме модулей.
Содержит автоматический сборщик мусора. Он работает для всех объектов Ruby, в том числе для внешних библиотек.
Поддерживает замыкания с полной привязкой к переменным.
"
Кхм. А чего из этого нет в JavaScript? Ну разве что переопределения операторов. И? Ради чего весь шум?
«В Ruby есть немало оригинальных решений, редко или вообще не встречающихся в распространённых языках программирования. Можно добавлять методы не только в любые классы, но и в любые объекты. Например, вы можете добавить к некоторой строке произвольный метод.»
«Любая конструкция в Ruby возвращает значение. Например:»
«Работа с массивами — одна из сильных сторон Ruby. Они автоматически изменяют размер, могут содержать любые элементы и язык предоставляет мощные средства для их обработки.»
Ну тут даже говорить-то не о чем. JavaScript просто выносит Ruby.
Тезис намба два. Синтаксис и возможности JavaScript полностью превосходят другие скриптовые языки, причем они _не зависят от реализации_, а уже являются частью языка. Небольшие преимущества, который дает синтаксический сахар конкурентов, быстро оказываются задавленными eval(), JSON, arguments и прочими приятными возможностями JavaScript.
Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python. Есть ли там null, обладающий особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом arguments? Могу ли я создать в них объект с данными и методами, написав:
Пожалуйста, напишите примеры. А то может я что-то упорно не понимаю и есть какие-то секретные знания о секретных возможностях этих скриптовых языков, которых постигли немногие просветленные?
И большая просьба — примеры того, чего НЕЛЬЗЯ сделать в JavaScript. Берем Ecma-262 за основу.
Чего можно написать такого в других скриптах, чего ну никак не сделаешь в JavaScript?
Теперь я просто хамски пройдусь по реализациям скриптовых этих языков. Тут уже JavaScript отдохнет.
Самое интересное наступает, когда вы начинаете выполнять много-много скриптов одновременно. И тут выясняется, что хваленые скриптовые машины быстро или медленно умирают.
При небольших разборках выясняется интересная деталь — разработчики этих скриптовых языков по какой-то странной и загадочной причине положили на производительность. Сразу! Их настолько увлекли эротические фантазии, связанные с удивительным новым синтаксисом, что никто в голову-то и не взял простую мысль: следует с самого начала предусмотреть реализацию, позволяющую выполнять быстро много скриптов.
В результате, читаем:
«Интерпретатор Ruby на сегодняшний день имеет следующие недостатки. Невысокая скорость работы. Ruby 1.8 является одним из самых медленных из используемых в практике веб-разработки языков программирования»
«PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode может быть оптимизирован с использованием необязательного оптимизатора, названного Zend Optimizer. В зависимости от скрипта, он может увеличить скорость выполнения PHP скрипта до 50%.
Раньше, после выполнения, opcode уничтожался. „
Лирическое отступление. Разве не гениально? Ну кто — кто бы во всем мире мог додуматься, что скомпилированные скрипты можно кешировать? Это ж надо быть… Биллом Гейтсом, наверное. Или двумя Гейтсами сразу.
Вы, надеюсь, понимаете над чем именно я иронизирую? Вот на этим: “раньше», «имел недостатки, которые были устранены», «был полным дерьмом до того, как». Я не понимаю — зачем начинать с дерьмовой производительности. Ну поясните мне! Пожалуйста! Ради чего тогда создается новый скриптовый язык?
Ну ладно, допустим Вы предлагаете свой новый супер-модный скриптовый язык для домашнего пользования и написания студенческих работ. Тогда я понимаю — производительность не имеет значения.
А вот если Вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня вот есть сильное такое подозрение, что производительность является _самым_важным_ критерием.
Так что следующий тезис не имеет отношения к JavaScript, это очередная порция яда в отношении прочих.
Тезис намба фри. Реализации новых скриптовых языков изначально не содержали исходного архитектурного решения, позволяющего выжать из них максимум производительности: многопоточное исполнение, пулы разделяемых внутренних структур (контекстов выполнения, например), предварительной компиляции, настроечной компиляции из промежуточного байт-кода. При этом большинство из этих языков предлагалось как раз для сектора, связанного с большой нагрузкой, например, веб-сервера.
И поэтому довольно забавно читать как PHP применяется для обработки веб-запросов. Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…
Вышло несколько сумбурно и местами резковато, возможно.
Надеюсь никто не воспринял мои замечания лично и не обиделся.
Буду рад найти истину вместе с вами.
Следующая часть книги расскажет о веб-браузерах. Без них не было бы JavaScript. А если бы и был, никто бы не обратил на него внимания.
Технологии веба с самого начала были децентрализованными – не только технически, но и с точки зрения их эволюции. Различные разработчики браузеров добавляли новую функциональность «по случаю», непродуманно, и часто эта функциональность обретала поддержку в других браузерах и становилась стандартом.
Это и благословление и проклятие. С одной стороны, здорово не иметь контролирующего центра, чтобы технология развивалась различными сторонами, иногда сотрудничающими, иногда конкурирующими. С другой – бессистемное развитие языка привело к тому, что результат не является ярким примером внутренней согласованности. Некоторые части привносят путаницу и беспорядок.
Сети и интернет
Компьютерные сети появились в 1950-х. Если вы проложите кабель между двумя или несколькими компьютерами и разрешите им передавать данные, вы может делать много удивительных вещей. А если связь двух машин в одном здании позволяет делать много разного, то связь компьютеров по всей планете должна позволять ещё больше. Технология, позволяющая это сделать, была создана в 1980-х, и получившаяся сеть зовётся интернетом. И она оправдала ожидания.
Компьютер может использовать эту сеть, чтобы кидаться битами в другой компьютер. Чтобы общение вышло эффективным, оба компьютера должны знать, что эти биты означают. Значение любой заданной последовательности битов зависит от того, что пытаются ими выразить, и какой механизм кодирования используется.
Стиль общения по сети описывает сетевой протокол. Есть протоколы для отправки е-мейлов, для получения е-мейлов, для распространения файлов и даже для контроля над компьютерами, заражёнными вредоносным софтом.
К примеру, простой протокол чата может состоять из одного компьютера, отправляющего биты, представляющие текст «ЧАТ?» на другой, а второго отвечающего текстом «ОК!», для подтверждения того, что он понял протокол. Дальше они могут перейти к отправке друг другу текстов, чтения полученных текстов и вывода их на экран.
Большинство протоколов построено на основе других протоколов. Наш протокол чата из примера рассматривает сеть как потоковое устройство, в которое можно вводить биты и заказывать их приход на конкретный адрес в правильном порядке. А обеспечение этого процесса – само по себе является сложной задачей. Transmission Control Protocol (TCP) – протокол, решающий эту задачу. Все устройства, подключённые к интернету, говорят на нём, и большинство общения в интернете построено на его основе.
Соединение по TCP работает так: один компьютер ждёт, или «слушает», пока другие не начнут с ним говорить. Чтобы можно было слушать разные виды общения в одно и то же время, для каждого из них назначается номер (называемый портом). Большинство протоколов устанавливают порт, используемый по умолчанию. К примеру, если мы отправляем е-мейл по протоколу SMTP, компьютер, через который мы его шлём, должен слушать порт 25.
Тогда другой компьютер может установить соединение, связавшись с компьютером назначения по правильному порту. Если машина назначения доступна, и она слушает этот порт, соединение устанавливается. Слушающий компьютер зовётся сервером, а соединяющийся – клиентом.
Такое соединение работает как двусторонняя труба, по которой текут биты – обе машины могут помещать в неё данные. Когда биты переданы, другая машина может их прочесть. Это удобная модель. Можно сказать, что TCP обеспечивает абстракцию сети.
World Wide Web, всемирная паутина (это не то же самое, что весь интернет в целом) – набор протоколов и форматов, позволяющий нам посещать странички через браузер. Веб, «паутина» в названии обозначает, что страницы можно легко связать друг с другом, в результате чего образуется гигантская сеть-паутина, по которой движутся пользователи.
Каждый документ имеет имя в виде универсального локатора ресурсов, Universal Resource Locator (URL), который выглядит примерно так:
HTML, или язык разметки гипертекста, Hypertext Markup Language – формат документа, использующийся для веб-страниц. HTML содержит текст и теги, придающие тексту структуру, описывающие такие вещи, как ссылки, параграфы и заголовки.
Простой HTML документ может выглядеть так:
Теги, окружённые угловыми скобками < и >, описывают информацию о структуре документа. Всё остальное – просто текст.
Документ начинается с , и это говорит браузеру, что его надо интерпретировать как современный HTML, в отличие от разных диалектов прошлого.
У HTML документов есть заголовок и тело. Заголовок содержит информацию о документе, а тело – сам документ. В нашем случае мы объявили, что название страницы будет «Моя домашняя страничка», затем описали документ, содержащий заголовок (, то есть heading 1, заголовок 1, самый крупный. Теги с по обозначают заголовки меньших размеров) и два параграфа
.
Некоторые теги ничего не окружают, и их не надо закрывать. Пример – тег картинки , который показывает картинку, находящуюся по заданному адресу URL.
Чтобы включать в текст документа угловые скобки, нужно пользоваться специальной записью, так как в HTML они имеют особое значение. Открывающая скобка (она же знак «меньше») записывается как "" («greater than», «больше, чем»). В HTML амперсанд &, за которым идёт слово и точка с запятой, зовётся сущностью и заменяется символом, который кодируется этой последовательностью.
Это похоже на обратные слэши, используемые в строках JavaScript. Из-за специального значения амперсанда его самого в текст можно включать в виде &. В атрибуте, заключаемом в двойные кавычки, символ кавычек записывается как ".
HTML разбирается парсером довольно либерально по отношению к возможным ошибкам. Если какие-то теги пропущены, браузер их воссоздаёт. Как именно это происходит, записано в стандартах, поэтому можно ожидать, что все современные браузеры будут делать это одинаково.
Следующий документ будет обработан так же, как и предыдущий.
Отсутствуют теги , и . Браузер знает, что должен быть в , а — в . Кроме того, параграфы не закрыты, поскольку открытие нового параграфа или конец документа означают их принудительное закрытие. Также адрес не заключён в кавычки.
В этой книге мы опустим теги , и для краткости. Но я буду закрывать теги, и заключать атрибуты в кавычки.
Также обычно я буду опускать doctype. Я не советую делать это вам – браузеры иногда могут творить странные вещи, когда вы их опускаете. Считайте, что они присутствуют в примерах по умолчанию.
HTML и JavaScript
В контексте нашей книги самый главный тег HTML — . Он позволяет включать в документ программу на JavaScript.
Такой скрипт запустится сразу, как только браузер встретит тег при разборе HTML. На странице появится диалог-предупреждение.
Включать большие программы в HTML непрактично. У тега есть атрибут src, чтобы запрашивать файл со скриптом (текст, содержащий программу на JavaScript) с адреса URL.
В файле code/hello.js содержится та же простая программа «alert('Привет!');». Когда страница ссылается на другой URL и включает его в себя, браузер подгружает этот файл и включает их в страницу.
Тег script всегда надо закрывать при помощи , даже если он не содержит кода и ссылается на файл скрипта. Если вы забудете это сделать, оставшаяся часть страницы будет обработана как скрипт.
Некоторые атрибуты тоже могут содержать программу JavaScript. У тега (на странице он выглядит как кнопка) есть атрибут onClick, и его содержимое будет запущено, когда по кнопке щёлкают мышкой.
Заметьте, что я использовал одинарные кавычки для строки в атрибуте onclick, поскольку двойные кавычки уже используются в самом атрибуте. Можно было бы использовать ", но это бы затруднило чтение.
Песочница
Запуск скачанных из интернета программ небезопасен. Вы не знаете ничего о тех людях, которые делали посещаемые вами сайты, и они не всегда доброжелательны. Запуская программы злых людей, вы можете заразить компьютер вирусами, потерять свои данные или дать доступ к своим аккаунтам третьим лицам.
Но привлекательность веба в том, что по нему можно сёрфить без обязательного доверия всем посещаемым страницам. Поэтому браузеры сильно ограничивают то, что может сделать программа JavaScript. Она не может открывать файлы на компьютере, или менять что-либо, не связанное со страницей, в которую она встроена.
Изолированное таким образом окружение называется песочницей – в том смысле, что программа безобидно играется в песочнице. Представляйте, однако, эту песочницу как клетку из толстых стальных прутьев.
Сложность в создании песочницы – позволять программам делать достаточно много, чтобы они были полезными, при этом ограничивая их от совершения опасных действий. Много из того, что делает пользователь, например общение с другими серверами или чтение содержимого буфера обмена, можно использовать для нарушения приватности.
Время от времени кто-то придумывает способ обойти ограничения браузера и сделать что-то вредное, от утечки некоей приватной информации до полного контроля над компьютером, где запущен скрипт. Разработчики исправляют эту дырку в браузере, и снова всё хорошо – до появления следующей проблемы, которая, можно надеяться, будет опубликована, и не тайно использоваться правительством или мафией.
Совместимость и браузерные войны
На ранних стадиях развития Веба браузер по имени Mosaic занимал большую часть рынка. Через несколько лет баланс сместился в сторону Netscape, который затем был сильно потеснён браузером Internet Explorer от Microsoft. В любой момент превосходства одного из браузеров его разработчики позволяли себе в одностороннем порядке изобретать новые свойства веба. Так как большинство людей использовали один и тот же браузер, сайты просто начинали использовать эти свойства, не обращая внимания на остальные браузеры.
Это были тёмные века совместимости, которые иногда называли «войнами браузеров». Веб-разработчики сталкивались с двумя или тремя несовместимыми платформами. Кроме того, браузеры около 2003 года были полны ошибок, причём у каждого они были свои. Жизнь людей, создававших веб-страницы, была тяжёлой.
Mozilla Firefox, некоммерческое ответвление Netscape, бросил вызов гегемонии Internet Explorer в конце 2000-х. Так как Microsoft особо не стремилась к конкуренции, Firefox отобрал солидную часть рынка. Примерно в это время Google представил свой браузер Chrome, а Apple – Safari. Это привело к появлению четырёх основных игроков вместо одного.
У новых игроков были более серьёзные намерения по отношению к стандартам и больше инженерного опыта, что привело к лучшей совместимости и меньшему количеству багов. Microsoft, видя сжатие своей части рынка, приняла эти стандарты. Если вы начинаете изучать веб-разработку сегодня – вам повезло. Последние версии основных браузеров работают одинаково и в них мало ошибок.
Нельзя сказать, что ситуация уже идеальная. Некоторые люди в вебе по причинам инерционности или корпоративных правил используют очень старые браузеры. Пока они не отомрут совсем, написание веб-страниц для них потребует мистических знаний об их недостатках и причудах. Эта книга не про причуды – она представляет современный, разумный стиль веб-программирования.
Читайте также: