Почему на стороне клиента все еще используется интерпретированный язык?
Насколько мне известно, JavaScript является единственным языком, который будет выполняться на стороне клиента после получения HTML-файла с сервера. Насколько я знаю, JavaScript ни в коем случае не компилируется, и поэтому является интерпретируемым языком.
Веб становится все более и более популярным, настолько, что некоторые говорят, что мобильные и настольные приложения скоро прекратят свое существование.
Мы видим новые технологии, такие как WebGL, который использует JS.
Когда я разрабатываю для WebGL, мне нужно гораздо больше оптимизировать для достижения приемлемого уровня производительности, чем то, что мне нужно для ПК или консоли.
Так почему же мы до сих пор используем интерпретированный язык на стороне клиента? Это проблема безопасности, аппаратная (кроссплатформенная) проблема или просто потому, что сложно внести такое большое изменение в веб-архитектуру? Я знаю, что у веб-разработчиков есть головные боли даже из-за самых маленьких и простых изменений, таких как использование CSS 3, просто потому, что не у всех есть свой браузер в актуальном состоянии.
Правильно ли я считаю, что взаимодействующие языки работают медленнее, чем скомпилированные? Имею ли я смысл или мои предположения совершенно неверны? Я ни в коем случае не JS/ веб-эксперт, пожалуйста, просветите меня.
3 ответа
Насколько мне известно, JavaScript является единственным языком, который будет выполняться на стороне клиента после получения HTML-файла с сервера.
Это не верно. По крайней мере, в HTML 4.01 <script> элемент имеет type атрибут, который позволяет указать любой язык, который вы хотите. Сама спецификация HTML 4.01 имеет примеры в VBScript и Tcl.
Например, более старые версии Internet Explorer поддерживают VBScript в качестве альтернативного языка сценариев ECMAScript. Существуют версии Chrome, которые поддерживают Dart в качестве альтернативного языка сценариев. Был проект, который добавил поддержку Firefox для PHP, Perl, Python, Ruby, Tcl и других.
Вы также можете использовать любой язык, который имеет компилятор, который выводит ECMAScript, и почти каждый язык в настоящее время имеет такой, например, есть компиляторы, которые могут компилировать C, C++, Java, Scala, Ruby, C♯, F♯ и многие другие ECMAScript. Существуют также языки, которые были специально разработаны как надмножества ECMAScript (например, TypeScript), семантически близкие к ECMAScript (например, CoffeeScript) или легко компилируемые в ECMAScript (например, Dart).
Насколько я знаю, JavaScript ни в коем случае не компилируется, и поэтому является интерпретируемым языком.
Это не верно. Все существующие в настоящее время в браузере механизмы исполнения ECMAScript имеют как минимум один компилятор. У многих есть несколько компиляторов. По крайней мере, ни у кого нет переводчика:
- V8 чисто скомпилирован, никакой интерпретации не происходит, он всегда компилирует исходный код ECMAScript в двоичный машинный код. В оригинальной версии был один компилятор, в текущей версии - два.
- SpiderMonkey всегда компилирует ECMAScript в байт-код SpiderMonkey. Этот байт-код затем сначала интерпретируется несколько раз для сбора статистики, а затем "горячие" части компилируются в двоичный машинный код одним из нескольких компиляторов.
- Nitro всегда компилирует ECMAScript в Nitro байт-код. Затем этот байт-код сначала интерпретируется несколько раз для сбора статистики, а затем "горячие" части компилируются в двоичный машинный код другим компилятором.
- Чакра всегда компилирует ECMAScript в байт-код чакры. Затем этот байт-код сначала интерпретируется несколько раз для сбора статистики, а затем "горячие" части компилируются в двоичный машинный код другим компилятором.
На самом деле, термины "интерпретируемый язык" и "скомпилированный язык" даже не имеют смысла. Языки не интерпретируются и не компилируются. Языки просто есть. Компиляция и интерпретация - это не черты языка, а черты компилятора или интерпретатора (да!) Язык - это набор математических правил и ограничений. Ничего более. Понятие "язык" и понятие "интерпретация" живут на двух совершенно разных уровнях абстракции. Если бы английский был типизированным языком, термин "интерпретируемый язык" был бы ошибкой типа.
Любой язык может быть реализован интерпретатором, и каждый язык может быть реализован компилятором. Есть интерпретаторы для C и C++, есть компиляторы для ECMAScript, PHP, Python и Ruby.
Правильно ли я считаю, что взаимодействующие языки работают медленнее, чем скомпилированные?
Во-первых, как я объяснил выше, просто не существует такой вещи, как интерпретируемый или скомпилированный язык. Существуют только интерпретированные или скомпилированные реализации языков. Во-вторых, не имеет смысла говорить, что язык медленнее, чем другой язык. Все, что вы можете сказать, это то, что какая-то конкретная программа при выполнении определенной версией конкретной реализации в конкретной среде на конкретной машине работает быстрее, чем другая программа, выполняемая другой версией другой реализации в другой среде на потенциально другой машина.
В целом, производительность типичных программ в конкретной реализации в основном зависит от того, сколько денег, ресурсов, усилий, умственных способностей, исследований, инженерии и рабочей силы было потрачено на это, а не на какую-либо конкретную черту языка. Oracle HotSpot JVM работает быстро не потому, что это скомпилированная реализация, не потому, что Java статически типизирована (на самом деле, это совершенно неважно, потому что HotSpot JVM выполняет байт-код JVM, она даже ничего не знает о Java!), А потому что Oracle и Sun вложила в него огромное количество ресурсов. По иронии судьбы, Java была довольно медленной, пока Sun не купила компанию Smalltalk(!!!) и их технологию виртуальных машин. Да, верно: HotSpot JVM на самом деле представляет собой просто слегка модифицированную виртуальную машину Smalltalk, то есть виртуальную машину для динамического языка.
На самом деле, VM HotSpot основана на открытом исходном коде, а также на VM V8 (что неудивительно, так как V8 был разработан теми же людьми, которые разработали JVM HotSpot и Smalltalk VM, на которой он базировался). на).
Обратите внимание, что есть две попытки получить новый язык, принятый поставщиками браузеров:
asm.js - это язык, который является синтаксическим и семантическим подмножеством ECMAScript (имеется в виду, что любая программа asm.js также является семантически идентичной программой ECMAScript, и браузер, который ничего не знает о asm.js, просто подумает, что это ECMAScript и выполнить его как ECMAScript, и он будет просто работать) с некоторыми ограничениями, которые делают его хорошей целью для компиляторов (например, относительно легко создать компилятор, который компилирует C в asm.js) и в то же время хорошим источником для нативного кода поколение (то есть его семантика относительно близка к семантике современных основных процессоров общего назначения).
Аналогично, WebAssembly - это (бинарный) язык, который имеет в основном те же цели, что и asm.js, за исключением того, что не требуется, чтобы он был надлежащим подмножеством ECMAScript. Это собственный независимый язык, основанный на asm.js, бит-коде LLVM, ANDF, CIL, байт-коде JVM, P-коде Pascal и других.
Asm.js уже имеет некоторую поддержку браузера, и из-за того, что это всего лишь подмножество ECMAScript, работает даже в браузерах без поддержки... просто медленнее. WebAssembly набирает обороты, хотя все еще находится на стадии экспериментов и прототипирования.
Насколько мне известно, JavaScript является единственным языком, который будет выполняться на стороне клиента после получения HTML-файла с сервера.
Не всегда правда. Тем не менее у нас есть другие варианты. как ActionScript, который работает во Flash Player, или VB Script. Но они вышли из моды.
Когда я разрабатываю для WebGL, мне нужно гораздо больше оптимизировать для достижения приемлемого уровня производительности, чем то, что мне нужно для ПК или консоли.
Да, я думаю, что мы можем сделать действительно хорошую графику с WebGL. но он все еще работает в песочнице браузера. как ведут себя js, так же ведет себя и WebGL в смысле доступа к файлам или других основных критериев. Думайте так, если вы разрабатываете массовую смелую игру, такую как сторожевые собаки или гта. Как вы думаете, браузер может справиться с этими возможностями. Но ПК, Консоль делают.
Так почему же мы до сих пор используем интерпретированный язык на стороне клиента? Это проблема безопасности, аппаратная (кроссплатформенная) проблема или просто потому, что сложно внести такое большое изменение в веб-архитектуру?
Я думаю, что они оба. скомпилированный код запускается прямо на машине. тогда какова роль для браузера здесь. поэтому мы теряем безопасность Также JavaScript имеют большой размер сообществ. если нам нужно полностью изменить веб-архитектуру, нам нужен совершенно другой клиент. этот клиент заменит все текущие браузеры. это совсем не возможно. но будет меняться день ото дня. ES6 - хорошее начало.
Я знаю, что у веб-разработчиков есть головные боли даже из-за самых маленьких и простых изменений, таких как использование CSS 3, просто потому, что не у всех есть свой браузер в актуальном состоянии.
Да, на 100% верно. Но другого пути для решения этой проблемы нет. Как разработчик должен сохранять совместимость.
Правильно ли я считаю, что взаимодействующие языки работают медленнее, чем скомпилированные?
Да, это будет быстро. Но последние браузеры имеют хорошие движки JS, такие как V8, которые используют Chrome. это действительно быстро, чем мы прогнозируем. Основная вещь, которую JS представляет как легковесную архитектуру. В те дни, когда сервер отправляет html, JS изменяет DOM, если требуется, но в последние дни сервер только отправляет данные, JS создает DOM. так что нагрузка больше на стороне JS. Это идет хорошо с помощью хороших двигателей JS.
JavaScript загружается как исходный код, поэтому его необходимо интерпретировать.
Вы не могли бы иметь намного более низкие уровни кода, поскольку он больше не будет повсеместно совместим между устройствами.
Одним из преимуществ JavaScript является то, что ваш код будет работать практически на любых устройствах веб-браузера.
Если вы скомпилируете этот код, он станет специфичным для архитектуры / устройства.
Естественно, что интерпретируемые языки будут работать медленнее, чем скомпилированные языки, поскольку скомпилированный код может запускаться вслепую ЦП, где скомпилированный код необходимо проверять / выполнять построчно; однако вы можете применить оптимизации, чтобы ограничить это.