JavaScript vs. Python en 2017

De hecho, el ecosistema de JavaScript ofrece todo tipo de herramientas para acelerar este proceso utilizando demonios y almacenamiento en caché, pero usted o alguien de su equipo debe invertir bastante tiempo investigando, ensamblando y manteniendo una cadena de herramientas JavaScript para su proyecto antes de que nadie pueda escribe una línea de JavaScript "moderno". Aunque en última instancia, puede lograr un buen flujo de trabajo de edición / actualización, ciertamente no tendrá uno listo para usar como lo haría en Python.

" JavaScript ya no es un lenguaje de edición / actualización. "

Otra diferencia refrescante entre JavaScript y Python es la naturaleza de "pilas incluidas" de Python. Si miras la biblioteca estándar que viene con JavaScript, es bastante mínima. El entorno de Nodo hace un trabajo modesto de aumentar lo que proporciona la biblioteca estándar, pero la mayoría de la funcionalidad que necesita inevitablemente tiene que ser extraída de npm. Específicamente, considere la siguiente funcionalidad que se incluye en la biblioteca estándar de Python, pero debe obtenerse de npm para un proyecto de nodo:

Como puede ver, para muchas de estas características, hay varias bibliotecas de terceros que proporcionan funcionalidad superpuesta. (Por ejemplo, si estuviera buscando un analizador JSON, ¿elegiría parse-json , safe-json-parse , fast-json-parse , jsonparse o json-parser ?) Para empeorar las cosas, los nombres de los módulos npm son aprobados por orden de llegada. Al igual que los nombres de dominio, esto significa que los grandes nombres a menudo se destinan a proyectos que no lo merecen. (Por ejemplo, a juzgar por su conteo de descargas, el módulo npm denominado logging convierte en uno de los paquetes de registro menos populares para JavaScript.) Esto hace que la comparación de los módulos de terceros consuma más tiempo ya que la calidad del nombre es no es una señal útil para la calidad de la biblioteca.

Es posible que el ecosistema de terceros de Python sea tan malo como el de las npm. Lo que es impresionante es que no tengo idea si ese es el caso, porque es tan raro que tenga que buscar un paquete de Python de terceros para obtener la funcionalidad que necesito . Soy consciente de que los científicos de datos dependen mucho de paquetes de terceros como NumPy, pero a diferencia del ecosistema Node, hay un paquete NumPy que todos usan en lugar de una letanía de competidores llamados numpy-fast , numpy-plus , simple-numpy , etc. .

"Deberíamos dejar de limitar las npm como testimonio de la diversidad del ecosistema de JavaScript, sino citarlo como una falla de la biblioteca estándar de JavaScript".

Para mí, una de las grandes ironías en todo esto es que, posiblemente, la presencia de una sólida biblioteca estándar en JavaScript sería la más apalancada en comparación con otros lenguajes de programación. ¿Por qué? Porque hoy en día, cada sitio web no trivial requiere que descargue underscore.js o lo que sus autores hayan elegido para compensar el núcleo débil de JavaScript. Cuando considera el impacto adverso agregado que esto tiene sobre el tráfico de la red y los tiempos de carga de la página, los números son alarmantes.

Entonces … ¿Estás diciendo que JavaScript ha muerto?

No, no, yo no. Si está construyendo UI utilizando tecnologías web (que son muchos desarrolladores), aún creo que JavaScript es su mejor opción. Modulo a la aparición de Web Assembly (que vale la pena prestarle atención), JavaScript sigue siendo el único lenguaje que se ejecuta de forma nativa en el navegador. Ha habido muchos intentos de tomar un lenguaje de programación existente y compilarlo en JavaScript para evitar "tener que" escribir JavaScript. Hay casos en que los resultados fueron buenos, pero nunca parecieron ser geniales. Tal vez una cadena de herramientas de transpilación finalmente logre destrabar JavaScript como el idioma para escribir en la web, pero sospecho que todavía tendremos la mayoría de los desarrolladores web escribiendo JavaScript por bastante tiempo.

Además, el navegador no es el único lugar donde los desarrolladores construyen UI utilizando tecnologías web. Otros dos ejemplos destacados son Electron y React Native . Electron es atractivo porque le permite escribir una vez para Windows, Mac y Linux, mientras que React Native es atractivo porque le permite escribir una vez para Android e iOS. Ambos también son empoderantes porque los ciclos de edición / actualización que usan esas herramientas son mucho más rápidos que sus equivalentes nativos. Desde una perspectiva de contratación, parece que los desarrolladores que conocen las tecnologías web (1) están disponibles en mayor número que los desarrolladores nativos, y (2) pueden admitir más plataformas con equipos más pequeños en comparación con los desarrolladores nativos.

De hecho, podría imaginar formas en que estas plataformas podrían modificarse para admitir Python como el lenguaje de scripting en lugar de JavaScript, lo que podría cambiar el cálculo. Sin embargo, una cosa que todas las herramientas locas que existen en la comunidad de JavaScript han dado paso a las cadenas de herramientas de Transpiler como Babel, que hacen que sea más fácil para los desarrolladores comunes (que no tienen que ser piratas informáticos) experimentar con la nueva sintaxis de JavaScript. En particular, esta herramienta ha allanado el camino para cosas como JSX , que sostengo que es una de las características clave que hace que React sea una tecnología tan agradable para construir UI. (Tenga en cuenta que puede usar Reaccionar sin JSX, pero es tedioso).

A mi leal saber y entender, la comunidad de Python no tiene un mecanismo popular equivalente para experimentar con DSL dentro de Python. Así que, aunque podría ser sencillo agregar enlaces de Python en estos entornos existentes, no creo que sea suficiente para que los desarrolladores de productos cambien a Python a menos que también se realicen cambios en el lenguaje que hace que sea tan fácil expresar el código de UI en Python. como está en JavaScript + JSX hoy.

Puntos clave

Python 3.6 tiene soporte integrado para tipado gradual y async / await. A diferencia de JavaScript, esto significa que puede escribir el código de Python que utiliza estas características de idioma y ejecutar ese archivo directamente sin ninguna herramienta adicional. Además, su biblioteca estándar rica significa que debe dedicar poco tiempo a buscar y evaluar bibliotecas de terceros para completar las lagunas que faltan. Es mucho más un lenguaje de scripting del lado del servidor "hacer las cosas", que requiere mucho menos andamiaje que JavaScript para despegar un proyecto. A pesar de que Mypy puede no ser tan efectivo o funcional como Flow o TypeScript en la actualidad, la velocidad de ese proyecto es algo a lo que voy a prestarle atención.

En comparación, espero que JavaScript siga siendo fuerte entre los desarrolladores de productos, pero aquellos que usen Node hoy para el código del lado del servidor o las herramientas de línea de comandos probablemente estarían mejor usando Python. Si la comunidad Nodo quiere resistir este cambio, creo que se beneficiarían de (1) expandir la API de nodo para hacerlo más completo, y (2) reducir el tiempo de inicio para Nodo. Sería aún mejor si pudieran modificar su tiempo de ejecución para reconocer cosas como el tipo de anotaciones y JSX de forma nativa, aunque eso requeriría cambios en V8 (o Chakra, en Windows), que espero que sea difícil de mantener y / o en sentido ascendente. Obtener TC39 para estandarizar cualquiera de esas características del lenguaje (lo que obligaría a la mano de Google / Microsoft a agregar soporte nativo en sus tiempos de ejecución JS) también parece una venta difícil.

En general, estoy emocionado de ver cómo funcionan las cosas en ambas comunidades. Nunca se sabe cuándo alguien lanzará una nueva tecnología que obsoleta toda su cadena de herramientas durante la noche. Por lo que sé, podríamos despertarnos mañana y todos decidimos que deberíamos escribir OCaml . Mejor configura tu despertador.

Esta publicación apareció originalmente en bolinfest.com .

Hacker Noon es cómo los hackers comienzan sus tardes. Somos parte de la familia @AMI . Ahora estamos aceptando presentaciones y estamos felices de conversar sobre oportunidades de publicidad y patrocinio .

Para obtener más información, lea nuestra página acerca de , como / envíenos un mensaje en Facebook , o simplemente, tweet / DM @HackerNoon.

Si disfrutaste esta historia, te recomendamos que leas nuestras últimas historias tecnológicas e historias tecnológicas de tendencia . Hasta la próxima, ¡no des por sentado las realidades del mundo!