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

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

Однако, поскольку мы можем указать тип пользовательского агента (например, тип и версию браузера) в HTTP-запросе, не можем ли мы заставить сервер хранить байт-код для каждого браузера и отвечать соответствующим образом, чтобы сэкономить время на клиенте?

Что мешает нам использовать этот подход? Я не думаю, что у браузеров не возникнет проблем, даже если некоторые файлы JavaScript будут представлены в байт-коде, а другие — в исходной строке. Точно так же у нас есть файлы .pyc в Python, и он хорошо работает с файлами .py.

[Обновление] Возможные преимущества, о которых я думаю, перечислены ниже.

  1. Вы можете сэкономить время анализа на клиенте. Синтаксический анализ выполняется быстро, но, возможно, его стоит сделать для слабых устройств.
  2. Вы можете поместить некоторые подсказки в байт-код. Например, JavaScriptCore (движок JavaScript WebKit, сокращенно АО) исправляет байт-код информацией, собранной во время выполнения, такой как типы. Байт-код АО разработан таким образом, что в нем есть слоты для такой информации.

С точки зрения ремонтопригодности сервер всегда может отправить исходную строку исходного кода, если браузер клиента не поддерживается, а различных движков JavaScript не так много. Поддержка четырех самых популярных браузеров (Chrome, Firefox, IE и Safari) кажется мне осуществимой. Кроме того, я не вижу частого изменения набора инструкций байт-кода.


person jray319    schedule 21.02.2015    source источник
comment
Что, если браузер отправляет обновление и изменяется внутренний формат байт-кода?   -  person Bergi    schedule 21.02.2015
comment
Какую проблему вы думаете, что это решает?   -  person Matt Ball    schedule 21.02.2015
comment
Было бы ужасно, если бы разработчикам браузерных сред выполнения JavaScript пришлось привязывать свои виртуальные машины к определенному набору инструкций. В нынешнем виде синтаксический анализ JavaScript поразительно быстр и полностью оправдывает свою цену (на мой взгляд).   -  person Pointy    schedule 21.02.2015
comment
Какие преимущества вы видите перед нынешним подходом? Не вижу причин увеличивать нагрузку на серверы.   -  person Bergi    schedule 21.02.2015
comment
Также подумайте о том, каким кошмаром может стать большой сайт, работающий со всеми активными версиями всех основных браузеров, включая браузеры мобильных устройств.   -  person Pointy    schedule 21.02.2015
comment
Распространять файлы .pyc — ужасная идея. Пожалуйста, не делайте этого.   -  person Antimony    schedule 21.02.2015
comment
Спасибо за все комментарии. Пожалуйста, прочитайте обновленный вопрос.   -  person jray319    schedule 21.02.2015
comment
@Antimony Почему распространение файлов .pyc — плохая идея?   -  person jray319    schedule 21.02.2015
comment
@ jray319 jray319 Потому что они зависят от версии и реализации, а это означает, что их можно правильно запустить только из того же интерпретатора, который их скомпилировал. Кроме того, это ломает некоторые инструменты самоанализа. Python — это не Java, где байт-код — это платформа. В Python исходный код — это платформа, а байт-код — просто недокументированная деталь реализации.   -  person Antimony    schedule 22.02.2015


Ответы (1)


  • Все движки должны будут сделать свой формат байт-кода общедоступным.
  • Сервер должен будет хранить очень много разных файлов байт-кода или даже компилировать их на лету.
  • Обнаружение браузера чревато опасностью (ложь агентов пользователя, кеш прокси)
  • Правила байт-кода могут меняться между младшими версиями браузера
  • Прирост производительности, вероятно, будет не таким значительным (особенно по сравнению со временем передачи по сети).
person Community    schedule 21.02.2015