Будет ли Python слишком медленным для использования на стороне клиента в браузерах?

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

Я считаю, что Javascript превосходит только в этом аспекте, потому что такие компании, как Google, нуждаются в этом быстро (и сделали это быстро), потому что им это нужно, чтобы выжить, но я могу ошибаться.

Есть ли различия в том, как Python и Javascript разработаны, которые влияют на то, как они (будут) работать в браузерах?

_{Поскольку на данный момент нет реализации Python на стороне клиента, мой вопрос связан с утверждением, которое кто-то сделал, так что, возможно, оно как-то связано с самими языками (хотя я в это не верю).}

Для начала мы должны провести четкое различие между языками и реализациями . Язык - это абстрактная вещь, реализация - это конкретная вещь, которая может измерять производительность. Например, когда-то Lisp считался слишком неэффективным для практического использования, но компиляторы продолжали развиваться, и, в конце концов, для него было разработано специальное оборудование; однажды в 1980-х годах она стала платформой для разработки высокопроизводительных рабочих станций.

При этом самый простой ответ заключается в том, что быстрая реализация Javascript, такая как Google V8, вырывает из воды стандартную реализацию Python (CPython) . V8 - это высокооптимизированная виртуальная машина с JITer, которая удивительно быстра, а CPython - относительно простая виртуальная машина по сравнению с ней. Есть реализация Python с JIT, но она все еще примерно в 5-6 раз быстрее.

Пять лет назад это была бы другая история. У браузеров были упрощенные реализации Javascript, потому что скорость не была проблемой, так как никто не создавал «реальное» программное обеспечение с ним, и Python был бы равным, если не быстрее.

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

Исходя из этого, был создан язык сценариев для связи Java-апплета с веб-страницей с именем ... javascript.

Можно увидеть остатки этого наследия с SO вопросами, такими как [ 1 ], [ 2 ], [ 3 ] - и двумя официальными документами: вызов кода JavaScript из апплета и вызов методов вызова апплета из кода JavaScript

Благодаря такому доступному языку браузеры того времени (Netscape был преобладающим) сделали javascript доступным в качестве конкурентного преимущества (javascript, разработанный в Netscape - Netscape был первым javascript на стороне сервера с его сервером еще в 1994 году - почти за два десятилетия до появления узла .js). Другие браузеры последовали его примеру. Люди писали страницы, которые использовали javascript, другие попытки сценариев на стороне клиента означали бы совершенно несовместимые страницы между тем, что работает, и тем, что не работает, или дублированием кода (вот блок {insert language here}, который делает это для не-javascript браузеры и вот блок javascript для всех остальных).

Поскольку Netscape был доминирующим браузером в течение некоторого времени, появился javascript. В то время как наследие Netscape потеряно для сносок исходных файлов Mozilla, javascript живет, и ничто не может перевернуть его место.

Проблема остается для любого другого языка сценариев слайдов клиента. Javascript поддерживается в любом браузере. Если бы нужно было создать браузер, который бы поддерживал Python (например), а не javascript, он не смог бы использовать подавляющее большинство веб-сайтов. Кроме того, если этот браузер не смог получить значительную долю трафика браузера, веб-дизайнеры не хотят создавать два набора страниц с разными языками сценариев для одной и той же страницы.

Кто-то может попытаться создать плагин сценариев Python для какого-либо браузера, который включает сценарий Python на странице ... Сродни тому, как работает vrml сегодня. Но если вы не слышали и не видели веб-страницу, которая использует vrml, то с такой же вероятностью можно найти применение для другой веб-страницы для другого языка сценариев.

Я не думаю, что Python будет слишком медленным. В языке нет ничего, что мешало бы ему работать достаточно быстро, чтобы хотя бы соответствовать JavaScript. Его можно скомпилировать в JavaScript, так что, если ничего другого, вы можете включить компилятор в браузер и только увеличить время загрузки страницы.

ОБНОВЛЕНИЕ: Пожалуйста, смотрите комментарии ниже, обсуждающие, почему компиляция Python для JS будет значительно дороже, чем подразумевается здесь.

Проблема состоит в том, чтобы убедить производителей браузеров и W3C сначала выбрать Python вместо Ruby или любого другого приятного языка сценариев, затем определить стандартизированное подмножество, поскольку они не могут разрешать системные вызовы и т. Д., А затем реализовать его хорошо, все время, пока поддержка JavaScript до сих пор. Этого не произойдет, но если это произойдет, я сомневаюсь, что скорость окажется серьезной проблемой.

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

Несколько случайных мыслей:

(1) Вы, вероятно, могли бы запустить Python локально через апплет Java, используя Jython. Сложная часть, которую я вижу здесь, состоит в том, что апплеты очень ограничены, поэтому вам может потребоваться изменить Jython, чтобы он соответствовал ограничениям доступа. Например, если он записывает в файл журнала, вам может потребоваться удалить код журнала. Апплет не должен быть заметно видимым.

(2) Кто-то может создать «компилятор» / конвертер Python-to-JavaScript. Это было бы много работы.

Это зависит от реализации языка и не обязательно самого языка. Большинство интерпретаторов JavaScript намного быстрее, чем почти все реализации Python.

Это не означает, что язык Python не может использоваться почти с той же скоростью, что и JavaScript. Opal реализует почти полный язык Ruby и стандартную библиотеку в браузере, компилируя код Ruby в код JavaScript, завернутый в замыкания. Если оставить в стороне затраты на включение библиотеки Opal, ее скорость намного ближе к скорости обычного JavaScript, чем любой другой интерпретатор Ruby, о котором я знаю.

Я не знаю, есть ли Python-эквивалент Opal, но такой проект, вероятно, будет означать, что ответом на ваш вопрос будет «нет». С ростом использования JavaScript в качестве «языка ассемблера для Интернета» меня не удивит, если его все больше будут использовать в качестве платформы для других языков, особенно с ростом мощности мобильных вычислений и накладных расходов на использование языка. реализованный в JavaScript становится все более небрежным.

РЕДАКТИРОВАТЬ: Вот список реализаций Python для браузера, которые компилируются / запускаются на JavaScript.

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js#python

А если вам интересно, вы можете посмотреть Опал, который мне действительно нравится.

http://opalrb.org/

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

Даже когда вы задали этот вопрос, в javascript уже было несколько реализаций Python, которые можно использовать на веб-страницах сегодня.

Взгляните на http://www.skulpt.org/ или http://www.brython.info/ для начала.

Производительность не так уж плоха, но вы должны проверить их сами и выяснить.

Python - это «консольный» язык, работающий на сервере

Javascript - это язык браузера, работающий на клиенте

Как таковые, они не конкурируют напрямую

... конечно, есть node.js и, возможно, плагины для браузера Python, но тогда вопрос больше в производительности конкретной реализации.

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

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