¿Python sería demasiado lento para el uso del lado del cliente en los navegadores?

17

He escuchado la afirmación de que Python sería demasiado lento para ser de alguna utilidad en los navegadores.

Creo que Javascript es solo superior en este aspecto porque las compañías como Google lo necesitan rápido (y lo hicieron rápido) porque lo necesitan para sobrevivir, pero podría estar equivocado.

¿Hay alguna diferencia en la forma en que Python y Javascript están diseñados que tengan un impacto en cómo se comportarían en los navegadores?

_{Como a partir de ahora no hay una implementación de Python del lado del cliente, mi pregunta proviene de la declaración que alguien hizo, por lo que tal vez tenga algo que ver con los lenguajes en sí (aunque no lo creo).}

— Profpatsch
fuente

2

Python en el navegador? ¿Cuando pasó eso?

— Yannis

66

No lo hizo. Observe el would?

— Profpatsch

16

Bueno, si no ha sucedido, entonces no veo de qué se trata la pregunta. Cuando hablamos de rendimiento, no estamos hablando de lenguajes, sino de implementaciones de lenguajes (y existen varias implementaciones para Python al igual que para Javascript). Si no hay una implementación de Python del lado del cliente, ¿de qué hay que hablar?

— Yannis

1

Ciencia teórica! : D Mi pregunta proviene de la declaración que alguien hizo, por lo que tal vez tenga algo que ver con los idiomas en sí (aunque no lo creo).

— Profpatsch

1

Hubo una vez una implementación de integración de Python para Internet Explorer, a través de la interfaz COM que también habilitó una opción de VBScript para ejecutar el DOM. Creo que MS suspendió la opción de usar la integración COM en la versión 5 o 6, no puedo recordar.

— Martijn Pieters

23

Para empezar, debemos hacer una distinción clara entre lenguajes e implementaciones . Un lenguaje es algo abstracto, la implementación es algo concreto que puede medir el rendimiento. Por ejemplo, Lisp alguna vez se consideró demasiado ineficiente para uso práctico, pero los compiladores siguieron madurando y, finalmente, se desarrolló un hardware dedicado para ello; en un momento en la década de 1980 fue la plataforma de desarrollo elegida para el desarrollo de estaciones de trabajo de alto rendimiento.

Dicho esto, la respuesta más simple es que una implementación rápida de Javascript como el V8 de Google elimina la implementación estándar de Python (CPython) fuera del agua . V8 es una máquina virtual altamente optimizada con un JITer que es increíblemente rápido, mientras que CPython es una VM bastante simple en comparación. Hay una implementación de Python con un JIT, pero eso solo es aproximadamente 5-6 veces más rápido.

Hace cinco años hubiera sido una historia diferente. Los navegadores tenían implementaciones de Javascript simplistas porque la velocidad no era una preocupación, ya que nadie construía un software 'real' y Python habría sido igual, si no más rápido.

— Sean McSomething
fuente

Esta es la respuesta más perspicaz hasta ahora. Entonces no es potencial, sino tiempo y dinero.

— Profpatsch

77

"Hace cinco años hubiera sido una historia diferente" ... y dentro de cinco años podría ser diferente nuevamente.

— Bryan Oakley

1

>> Un lenguaje es algo abstracto, la implementación es algo concreto que puede medir el rendimiento. << Sí, una implementación de lenguaje de programación es algo concreto. No, una implementación de lenguaje de programación no tiene un rendimiento de propiedad medible. El rendimiento es una propiedad de programas particulares que usan una implementación de lenguaje, en un contexto particular.

— igouy

2

@igouy Entonces, si tuviera que escribir dos programas funcionalmente idénticos, uno en C y otro en Python, ¿consideraría que la diferencia de rendimiento es una propiedad de la aplicación y no la implementación del lenguaje?

— ConditionRacer

1

@ConditionRacer: hay muchas formas diferentes de escribir el mismo programa, por lo que incluso si una versión de Python del programa tuviera características de rendimiento diferentes de una versión en C, no probaría que ninguna versión de Python podría ser equivalente a la versión en C. Vea cosas como asm.js ... en cualquier idioma, puede usar una matriz gigante para almacenar todo el estado de su programa, y puede usar un pequeño subconjunto fácilmente optimizable de las operaciones primitivas del lenguaje. (Como dicen "puedes escribir C en cualquier idioma".)

— Mankarse

5

En los viejos tiempos de la web, cuando los applets de Java eran la única forma ~~principal~~ de contenido interactivo del lado del cliente, las personas se daban cuenta de que tenía que haber una forma de obtener formularios en una página web para poder interactuar con los applets en la página web.

A partir de esto, se creó un lenguaje de secuencias de comandos para vincular el applet de Java a la página web con el nombre ... javascript.

Uno puede ver los vestigios de este legado con preguntas SO tales como [ 1 ], [ 2 ], [ 3 ] - y los dos documentos oficiales: Invocación de código JavaScript desde un applet e Invocación de métodos de applet desde código JavaScript

Con dicho lenguaje disponible, los navegadores de la época (Netscape es el predominante) pusieron javascript disponible como una ventaja competitiva (javascript diseñado en Netscape: Netscape fue el primer javascript del lado del servidor con su servidor en el '94, casi dos décadas antes del nodo .js). Otros navegadores hicieron lo mismo. La gente escribía páginas que usaban JavaScript, otros intentos de secuencias de comandos del lado del cliente significarían páginas completamente incompatibles entre cosas que funcionan y cosas que no funcionan, o la duplicación de código (aquí está el bloque {insert language here} que hace esto para no javascript navegadores y aquí está el bloque javascript para todos los demás).

Como Netscape fue el navegador dominante durante un período, JavaScript se apoderó. Si bien el legado de Netscape se pierde en las notas a pie de página de los archivos fuente de Mozilla, javascript sigue vivo y nada ha sido capaz de sobrepasar su lugar.

El problema persiste para cualquier otro lenguaje de script de diapositivas de cliente. Javascript es compatible con todos los navegadores. Si se hiciera un navegador que admitiera Python (por ejemplo) en lugar de JavaScript, no sería capaz de utilizar la gran mayoría de los sitios web. Además, a menos que ese navegador pueda obtener una parte significativa del tráfico del navegador, los diseñadores web no desean crear dos conjuntos de páginas con diferentes lenguajes de script para la misma página.

Uno podría intentar crear un complemento de script de Python para algún navegador que habilitara un script de Python en la página ... similar a cómo funciona vrml en la actualidad. Pero a menos que haya escuchado y visto una página web que usa vrml, es probable que una encuentre uso para otra página web para otro lenguaje de secuencias de comandos.

— Comunidad
fuente

1

Esta es una muy buena descripción general de "cómo sucedió ..." y aunque quisiera marcarla como respuesta correcta, responde a la pregunta "¿Por qué se usa Javascript el lenguaje del lado del cliente hoy?", No " ¿Hay algún problema de diseño que haga que Python sea demasiado lento para el uso del lado del cliente? ”

— Profpatsch

VRML ... wow, eso me lleva de vuelta!

— FrustratedWithFormsDesigner

1

@Profpatsch no hay ningún problema de diseño técnico con JavaScript que lo haga inapropiado para ser un lenguaje del lado del cliente, aparte de que nada lo usa y, a menos que ofrezca alguna ventaja significativa (probablemente incluyendo la interactividad con los applets de Java), nada lo hará. Los problemas no son técnicos y, a menos que uno comprenda la historia de "por qué javascript", no puede responder "por qué no Python".

2

@MichaelT: Usted escribió "no hay ningún problema de diseño técnico con JavaScript que lo haga inapropiado por ser un lenguaje del lado del cliente". ¿Quieres decir Python no JS?

— Carl Smith

@CarlSmith Ahh sí. Mi error ... y no puedo editar comentarios más allá de cierto tiempo. Gracias por la corrección.

4

No creo que Python sea demasiado lento en absoluto. No hay nada en el lenguaje que evite que se ejecute lo suficientemente rápido como para que coincida con JavaScript. Se puede compilar en JavaScript, por lo que, si nada más, podría incluir un compilador en el navegador y solo aumentar potencialmente los tiempos de carga de la página.

ACTUALIZACIÓN: consulte los comentarios a continuación sobre por qué compilar Python a JS sería considerablemente más costoso de lo que aquí se implica.

El problema es tratar de convencer a los proveedores de navegadores y al W3C de que primero elijan Python, en lugar de Ruby o cualquier otro lenguaje de script agradable, luego definan un subconjunto estandarizado, ya que no pueden permitir llamadas al sistema, etc., y luego implementarlo bien, todo mientras compatible con JavaScript todavía. Eso no va a suceder, pero si sucediera, dudo que la velocidad se convierta en un problema grave.

— Carl Smith
fuente

77

Tu primer punto no sigue. Todo se puede compilar en casi todo (incluido el código de máquina), pero eso no significa que un programa escrito en algún lenguaje L y compilado en algún lenguaje C sea tan rápido como un programa equivalente escrito en el lenguaje C.

1

Bueno, CoffeeScript es esencialmente una sintaxis diferente para los mismos conceptos centrales que JavaScript, y C es esencialmente un lenguaje ensamblador portátil. Python y Javascript, por otro lado, difieren bastante. Para implementar Python correctamente, debe admitir (entre miles de millones de otras cosas) el modelo de clase, la sobrecarga del operador, las metaclases, etc. y la mayoría de eso no se asigna a JavaScript de manera fácil y eficiente. Mismo problema con la compilación de cualquiera de ellos en C o código de máquina. Un JIT especializado puede ser su única esperanza, pero los compiladores JIT que apuntan a JS aún no se han demostrado prácticos.

3

Un problema será el hecho de que no puede comprimir Python como puede JS: elimine todos esos espacios y líneas nuevas, ¡y ahí va su alcance! Así que terminará con tiempos de carga más largos para cualquier fragmento significativo de Python.

— TMN

1

Punto interesante de @TMN, aunque uno esperaría que la expresividad de Python sirviera para mitigar eso (y sí, eso es contar líneas, no caracteres, pero aún así, Python es un lenguaje bastante expresivo).

— Daniel B

2

@TMN Lo que dijo Daniel B, y también gzip debería reducir la diferencia. Ah, y Python no necesita la mayoría de esas nuevas líneas y espacios. Muchas (aunque no todas) líneas se pueden unir muy bien en Python, por ejemplo, a = something(); frobincate(a); return quuxy if condition: react()son una sola línea cada una. Y n niveles de sangría solo necesitan n espacios, no n * 4 espacios.

2

Creo que Python tiene su propia máquina virtual. No tengo mucha experiencia con Python, pero no veo ninguna razón por la que no funcione tan bien como un motor JavaScript no optimizado.

Algunos pensamientos al azar:

(1) Probablemente podría ejecutar Python localmente a través de un applet de Java utilizando Jython. Lo difícil que veo aquí es que los applets son muy restrictivos, por lo que es posible que deba modificar Jython para que se ajuste a las restricciones de acceso. Por ejemplo, si escribe en un archivo de registro, es posible que deba eliminar el código de registro. Un applet no necesita ser notablemente visible.

(2) Alguien podría construir un "compilador" / convertidor de Python a JavaScript. Esto sería mucho trabajo.

— Aaron S
fuente

55

Someone could build a Python-to-JavaScript "compiler"/converterBueno, alguien ya lo hizo .

— Yannis

Brython también

— Ingeniero mundial

Nunca tuve que hacer esto yo mismo, pero soy consciente de que las personas han escrito applets de Java utilizando Jython. Sin embargo, eso no es lo mismo que reemplazar Javascript en el navegador con Python.

— Martijn Pieters

Brythonfunciona de forma interesante y rápida, al menos para partes bastante aisladas en las páginas (baja interacción con el DOM tree).

— Profpatsch

@Profpatsch Desde el estado en que lo vi la última vez, ni siquiera implementa partes muy grandes del lenguaje Python. Convenientemente, entre las características no implementadas se encuentran aquellas que son difíciles de implementar bien sobre JavaScript. Parafraseando a uno de los autores de PyPy: es fácil hacer un subconjunto no trivial de Python rápido, Python completo es donde se vuelve difícil.

1

Depende de la implementación del lenguaje y no necesariamente del lenguaje en sí. La mayoría de los intérpretes de JavaScript son mucho más rápidos que casi todas las implementaciones de Python.

Esto no significa que el lenguaje Python no se pueda usar a casi la misma velocidad que JavaScript. Opal implementa casi todo el lenguaje Ruby y la biblioteca estándar en el navegador compilando el código Ruby en código JavaScript envuelto en cierres. Dejando a un lado la sobrecarga de incluir la biblioteca Opal, su velocidad es mucho más cercana a la de JavaScript directo que cualquier otro intérprete de Ruby que conozca.

No sé si hay un equivalente en Python de Opal, pero tal proyecto probablemente significaría que la respuesta a su pregunta es "no". Con el uso creciente de JavaScript como un "lenguaje ensamblador para la web", no me sorprendería si se usará cada vez más como plataforma para otros idiomas, especialmente a medida que aumenta la potencia de la informática móvil y la sobrecarga de tener un idioma implementado en JavaScript se vuelve cada vez más negligente.

EDITAR: Aquí hay una lista de implementaciones de Python para el navegador que compila / ejecuta en JavaScript.

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

Y en caso de que esté interesado, puede consultar Opal, que realmente me gusta.

http://opalrb.org/

Dado que dudo que los navegadores alguna vez vengan con soporte para intérpretes separados, tales compiladores son probablemente el camino del futuro en términos de uso de otros idiomas además de JavaScript. Incluso ahora, obtendrá un rendimiento comparable en la mayoría de las áreas. Sin embargo, esta es mi opinión, así que tenlo en cuenta.

— Ravenstine
fuente

0

Incluso cuando hizo esta pregunta, ya había una serie de implementaciones de Python disponibles en JavaScript que se pueden usar en las páginas web de hoy.

Eche un vistazo a http://www.skulpt.org/ o http://www.brython.info/ para empezar.

El rendimiento no parece ser demasiado malo, pero debe probarlos usted mismo y descubrirlo.

— fabspro
fuente

-4

Python es un lenguaje de "consola" que se ejecuta en el servidor

Javascript es un lenguaje de "navegador" que se ejecuta en el cliente

Como tal, no compiten directamente

... por supuesto, hay node.js y probablemente complementos del navegador Python, pero luego es más una cuestión sobre el rendimiento de una implementación en particular.

Además, para la mayoría de las aplicaciones, Python funcionará bien, excepto si tiene que hacer algún tipo de cálculos extensivos y exprimir los ciclos de la CPU.

Como última nota, python y javascript comparten muchas similitudes. Debido a su naturaleza dinámica, ambos deben interpretarse en tiempo de ejecución y no pueden compilarse con tanta fuerza como los lenguajes de tipo estático. Como tal, supongo que su rendimiento alcanzable sería similar.

— dagnelies
fuente

2

El lado del servidor javascript estaba en el '94. jscle permite trabajar con javascript como consola, de forma muy similar a lo que se obtendría si escribiera pythonen una consola.

@MichaelT: Ok, edité mi respuesta en consecuencia

— dagnelies

2

También puede escribir aplicaciones de escritorio en Python ... No veo ninguna razón real para la distinción que está haciendo.

— Chris Travers

Además, la herramienta de modelado 3D Blender usa Python para todo, desde la interfaz de usuario hasta la generación de mallas. Si eso no es performativamente competitivo, ¿qué es?

— Andrew Gray

@Chris: la distinción es que javascript es principalmente una tecnología de navegador, mientras que python es principalmente una tecnología de escritorio / consola. Mi punto era que comparar ambos tiene poco sentido porque sirven para propósitos completamente diferentes.

— Dagnelies