Браузер является транслятором языка программирования

До сих пор в нашей истории браузера браузер получал байты данных из сетевого HTTP-запроса и декодировал их в кодовые точки Unicode, кодировку. Требуемую веб-стандартами. Наша конечная цель, помните, состоит в том, чтобы “превратить байты в деревья”. Чтобы браузер имел правильные инструкции для рендеринга. Если вы хотите сделать шаг назад и прочитать его, Часть 1 здесь.
Что дальше? Что делает браузер с кучей U+74 U+68 U+69 U+73? Well…it анализирует эти единицы, чтобы извлечь из них смысл. Это большая тема, и пока я исследовал ее, у меня было очень классное ага! момент. Который действительно помог укрепить мою ментальную модель HTML и CSS как языков программирования.

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

Как мы обсуждали в части 1, байты, которые получает браузер, декодируются в HTML. CSS и JS. Дело в том, что эти языки не могут быть понятны компьютеру или браузеру. Это фундаментальная проблема в информатике: необходимость преобразования кода, который мы, люди, понимаем, в инструкции. Которые может выполнить компьютер.

Метафора

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

Может быть, вы подумали: “Фу, как бы я хотел, чтобы это было написано простым языком!”. Это то же самое, что чувствует компьютер (за исключением того, что у компьютеров нет чувств…верно?) когда он видит инструкции. Которые мы пишем на языках программирования. Компьютер ничего не может сделать с кодом. Который мы пишем, должен быть дополнительный шаг. Который читает этот код для компьютера.

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

Да, эти байты имеют тот же формат, который мы видели, поступая в браузер через HTTP.

Таким образом, весь код, который мы пишем – независимо от языка – должен в конечном итоге стать числовым машинным кодом. Который может понять аппаратное обеспечение. Чем дальше язык от машинного кода, тем выше уровень языка – с другой стороны, языки, которые ближе к машинному коду. Являются языками более низкого уровня. Программные инструкции, написанные на HTML и CSS, являются очень высокоуровневыми. В то время как инструкции на Rust или C++-языках. Используемых при разработке браузеров. – являются языками более низкого уровня и

, так сказать, “ ближе к металлу“.

Интерпретаторы против компиляторов

Существует два основных термина, используемых для описания процесса перевода инструкций, написанных на языке программирования. В инструкции машинного кода: компилятор и интерпретатор.

Если вы, как и я, занимаетесь веб-разработкой, возможно. Слышали термин “компилятор” в контексте Sass и других препроцессоров; компилятор Sass преобразует Sass. Который мы пишем, в CSS. Который браузер может читать. Однако я не могу сказать. Что у меня есть определенная ассоциация веб-разработки с термином

интерпретатор.

Давайте рассмотрим несколько определений для обоих типов, начиная с компилятора:

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

Гики для гиков

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

Википедия

Конечно, это имеет смысл и хорошо вписывается в мое понимание компилятора Sass. Теперь несколько определений для интерпретатора:

Интерпретатор непосредственно выполняет инструкции, написанные на языке программирования или скриптов. Без предварительного преобразования их в объектный или машинный код.

Вундеркинды для вундеркиндов

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

Википедия

Подожди…что? Разве это не было бы невозможно? Разве перевод на машинный язык не является фундаментальным для работы компьютеров?

Разве переводчик пропускает этот шаг?! Нет, он, конечно, не пропускает этот шаг, но это нюанс.

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

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

“Интерпретатор” в современном массиве языков программирования, однако, кажется, немного уловка-все термин. Это не традиционный компилятор? Это интерпретатор…и обратите внимание, что многие интерпретаторы содержат компиляторы!

При использовании в контексте описания языков программирования можно сказать. Что Sass является компилируемым языком программирования точно так же. Как C++ является компилируемым языком программирования. Python-это интерпретируемый язык программирования. JavaScript компилируется и интерпретируется.

А как насчет HTML и CSS? Хмм…Я пока не хочу отвечать на этот вопрос.

Мне нравится это чувство от Мэтта Эша в этом потоке StackOverflow: помните, использование терминов, скомпилированных и интерпретированных для описания языка программирования. Описывает реализацию языка программирования. А не характеристики самого языка.

Назад к метафорам

В нашей метафоре жаргонного текста, приведенной в начале этого поста, компилятор-это друг. Который написал перевод жаргона и передал вам текст на простом языке для чтения. Переводчик — это друг. Который читает и переводит вам текст строчка за строкой.

Вы также можете посмотреть это потрясающее винтажное видео об инопланетянах в качестве компиляторов и интерпретаторов!

Какое это имеет отношение к браузеру?

О боже, все! Идея браузера не просто “пукнула” из ниоткуда. Сэр Тим Бернерс-Ли, компьютерный ученый и изобретатель Всемирной паутины. Был очень осведомлен о компиляторах и интерпретаторах. Термин компилятор был придуман еще в 1950-х годах Грейс Хоппер, а интерпретатор — вскоре после этого Стивом Расселом.

Концепция интерпретатора имеет все, что связано с браузером…потому что это то, что есть! На высоком уровне сэр Тим Бернерс-Ли создал интерпретатор HTML. Браузер делает много других вещей, таких как предоставление интерфейса для просмотра.

Через HTTP – запросы наши компьютеры получают программные инструкции-от кого угодно. Где угодно (вау!) – что браузер читает и выполняет на наших собственных. Персональных компьютерах. HTML. CSS и JavaScript-это языки программирования, интерпретируемые браузером. Веб-это домен для обмена программами, написанными на этих языках. Так круто!

Интересно, что современные браузеры также содержат компиляторы, называемые Just-in-time compilers (JITs). Которые обеспечивают гибкость интерпретаторов наряду со скоростью компиляции. JIT-компиляторы компилируют и кэшируют исходный код по частям, а не компилируют его весь сразу. У меня такое чувство, что эта тема будет обсуждаться в другом посте. Поэтому пока я оставлю вам отличное иллюстрированное объяснение JIT-компиляторов Лина Кларка и список ресурсов для TurboFan, компилятора. Включенного в JavaScript-движок Google V8.

(Спасибо Саре за то. Что втянула меня в JITs ^^!)

Вопрос и ответ

Когда я писал этот пост, я подумал: разве веб – сайты не были бы намного быстрее, если бы HTML. CSS и JS были скомпилированы на серверах. А затем байты машинного кода –байт-код-были отправлены по HTTP. Немедленно исполняемые на наших персональных компьютерах? Почему мы посылаем байты исходного кода, которые должны быть интерпретированы? Почему браузер больше не похож на компилятор HTML. CSS и JS?

Моя первая мысль была, что это делает Веб открытым. Если бы мы отправили машинный код в браузеры, не было бы никакого “Источника просмотра”. Еще одна причина, имеющая более серьезные последствия. — это безопасность. Что, если в этих байтах была куча вредоносной ерунды, и принимающий компьютер просто запустил ее, не задавая вопросов? Кроме того, у разных машин разные процессоры, поэтому отправка исполняемого байт-кода означала бы. Что все процессоры должны были бы читать одни и те же байты. И это просто не так.

Эти причины, а также существование JIT-компиляторов и тот факт, что синтаксический анализ не так уж громоздок, означают. Что мы не увидим HTML/CSS-компиляторы в ближайшее время.

(Спасибо Эмилио за то. Что он прояснил это для меня!)

С этим я собираюсь закрыть Часть 2! На данный момент планируется. Что Часть 3 будет глубоким погружением в этапы интерпретации HTML. CSS и JS (и многих других языков программирования!): синтаксический анализ. Токенизация и создание дерева.

Источники

Есть ли часть 3? Я люблю эти статьи. 🙂