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

17

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

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

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

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

— Profpatsch
источник

2

Python в браузере? Когда это произошло?

— Яннис

6

Это не так. Заметьте would?

— Profpatsch

16

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

— Яннис

1

Теоретическая наука! : D Мой вопрос исходит из заявления, которое кто-то сделал, так что, возможно, это как-то связано с самими языками (хотя я в это не верю).

— Profpatsch

1

Когда-то была реализация интеграции Python для Internet Explorer через интерфейс COM, который также включал опцию VBScript для сценариев DOM. Я думаю, что MS прекратил возможность использовать интеграцию COM в версии 5 или 6, не могу вспомнить.

— Мартин Питерс

23

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

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

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

— Шон Максомт
источник

Это самый проницательный ответ. Так что это не потенциал, а время и деньги.

— Profpatsch

7

«Пять лет назад это была бы другая история» ... а через пять лет все могло бы быть иначе.

— Брайан Оукли

1

>> Язык - это абстрактная вещь, реализация - это конкретная вещь, которая может измерять производительность. << Да, реализация языка программирования - это конкретная вещь. Нет, реализация языка программирования не имеет измеримых характеристик свойств. Производительность - это свойство определенных программ, которые используют языковую реализацию в определенном контексте.

— igouy

2

@igouy Итак, если бы я написал две функционально идентичные программы, одну на C, а другую на Python, вы бы сочли разницу в производительности свойством приложения, а не языковой реализацией?

— ConditionRacer

1

@ConditionRacer: Есть много разных способов написания одной и той же программы, поэтому, даже если версия программы на python имела характеристики производительности, отличные от версии C, это не доказало бы, что ни одна версия python не может быть эквивалентной версии C. Посмотрите такие вещи, как asm.js ... на любом языке, вы можете использовать гигантский массив для хранения всего состояния вашей программы и использовать небольшое легко оптимизируемое подмножество примитивных операций языка. (Как говорится, «Вы можете написать C на любом языке».)

— Mankarse

5

В давние времена в Интернете, когда 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, то с такой же вероятностью можно найти применение для другой веб-страницы для другого языка сценариев.

— Сообщество
источник

1

Это очень хороший обзор того, «как это произошло ...», и, хотя я бы хотел отметить его как правильный ответ, он отвечает на вопрос «Почему Javascript является клиентским языком, используемым сегодня?», А не « Есть ли проблема дизайна, которая делала бы Python слишком медленным для использования на стороне клиента? »

— Profpatsch

VRML ... вау, что возвращает меня!

— FrustratedWithFormsDesigner

1

@Profpatsch: нет никаких технических проблем с дизайном javascript, которые делают его неприемлемым для использования на стороне клиента - кроме того, что он ничем не используется и если он не дает каких-либо существенных преимуществ (вероятно, включая интерактивность с java-апплетами), он никогда не будет. Проблемы не являются техническими, и если человек не понимает историю «почему javascript», он не может ответить «почему не python».

2

@MichaelT: Вы написали, что «нет никаких технических проблем с дизайном javascript, которые делают его неуместным для языка клиента». Вы имеете в виду Python, а не JS ??

— Карл Смит

@ CarlSmith Ааа, да. Моя ошибка ... и я не могу редактировать комментарии после определенного времени. Спасибо за исправление.

4

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

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

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

— Карл Смит
источник

7

Ваш первый пункт не следует. Все может быть скомпилировано практически во все (включая машинный код), но это не означает, что программа, написанная на некотором языке L и скомпилированная на некотором языке C, работает так же быстро, как и эквивалентная программа, написанная на языке C.

1

Ну, CoffeeScript - это, по сути, другой синтаксис для тех же основных понятий, что и в JavaScript, а C - это по сути переносимый язык ассемблера. Python и Javascript, с другой стороны, сильно различаются. Для правильной реализации Python вам необходимо поддерживать (среди миллиардов других) модель классов, перегрузку операторов, метаклассы и т. Д., И большинство из них не отображаются в JavaScript легко и эффективно. Та же проблема с компиляцией любого из них в C или машинный код. Специализация JIT может быть вашей единственной надеждой, но JIT-компиляторы, ориентированные на JS, еще не доказали свою практичность.

3

Одной из проблем будет тот факт, что вы не можете сжать Python так же, как вы можете JS - устраните все эти пробелы и переводы строк, и все будет в порядке! Таким образом, вы получите более длительное время загрузки для любых значительных кусков Python.

— TMN

1

Интересный момент @TMN, хотя можно было бы надеяться, что выразительность Python будет иметь большое значение для смягчения этого (и да, это подсчет строк, а не символов, но все же Python - довольно выразительный язык).

— Даниэль Б

2

@ TMN То, что сказал Дэниел Б., а также gzip, должно уменьшить разницу. О, и Python не нуждается в большинстве этих новых строк и пробелов. Многие (хотя и не все) строки могут быть просто отлично соединены в Python, например, a = something(); frobincate(a); return quuxи if condition: react()являются одной строкой каждая. И n уровней отступов требуют только n пробелов, а не n * 4 пробелов.

2

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

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

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

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

— Аарон С
источник

5

Someone could build a Python-to-JavaScript "compiler"/converterНу, кто-то уже сделал .

— Яннис

Brython, а также

— мировой инженер

Мне никогда не приходилось делать это самостоятельно, но я знаю людей, которые писали Java-апплеты с использованием Jython. Это не то же самое, что замена Javascript в браузере на Python.

— Мартин Питерс

Brythonработает интересно быстро, по крайней мере, для довольно изолированных частей на страницах (слабое взаимодействие с DOM tree).

— Profpatsch

@Profpatsch Из того состояния, которое я видел в прошлый раз, он даже не реализует очень большие части языка Python. Удобно, что среди нереализованных функций есть те, которые трудно реализовать на JavaScript. Перефразируя одного из авторов PyPy: легко сделать нетривиальное подмножество Python быстрым, полный Python - то, где это становится трудным.

1

Это зависит от реализации языка и не обязательно самого языка. Большинство интерпретаторов 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. Даже сейчас вы получите сопоставимую производительность в большинстве областей. Однако это мое мнение, так что имейте это в виду.

— Ravenstine
источник

0

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

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

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

— fabspro
источник

-4

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

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

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

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

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

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

— dagnelies
источник

2

Серверный JavaScript был примерно в 94 году. jscпозволяет вам работать с javascript в качестве консоли, почти так же, как если бы они печатали pythonна консоли.

@MichaelT: Хорошо, я соответственно отредактировал свой ответ

— dagnelies

2

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

— Крис Треверс

Кроме того, инструмент трехмерного моделирования Blender использует Python для всего, от пользовательского интерфейса до создания сетки. Если это не конкурентоспособно, то что?

— Эндрю Грей

@Chris: различие в том, что javascript - это, прежде всего, браузерная технология, а python - это, в основном, десктоп / консольная технология. Моя точка зрения заключалась в том, что сравнивать оба смысла мало, потому что они служат совершенно другим целям.

— dagnelies