Este artículo no tiene demasiadas pretensiones más allá de ser un recordatorio de que es, como funciona y que hace funcionar a JavaScript y que se escribe como consecuencia del olvido de algunos desarrolladores del contexto en que JavaScript puede funcionar y donde no.
No hace mucho una programadora, me cuestiono la forma que hay en la comunidad de enseñar JS, según sus palabras: “Se debería enseñar desde el motor de renderizado para entender mejor las posibilidades y limitaciones del lenguaje”. Esas palabras me han calado fondo y las entendí mucho mejor cuando leí tuits donde se escribía que JavaScript se puede usar para escritorio, móvil, web front, web back e incluso IoT y, por lo tanto, no valía la pena aprender otros lenguajes.
Partiré diciendo que aunque, como, pago facturas y realizo mi trabajo (o parte de él) gracias a JavaScript, en realidad los tuits que se mencionan anteriormente (y que espero que fueran ironía o en broma, aunque no lo pareciera) es en realidad una referencia al desconocimiento del funcionamiento del script más popular en programación.
Comencemos por el inicio: ¿Qué es JavaScript?.
JavaScript es un lenguaje de programación interpretado que nació en la el navegador Netscape en 1995.
¿Cómo funciona JavaScript?
Decíamos que JavaScript es un lenguaje interpretado, o sea, el código escrito en JS no es comprensible por el entorno (sistema operativo, navegador, servidor, etc.) en donde se ejecuta.
Imposible comunicación
Ni los escritorios, ni los móviles, ni los navegadores están desarrollados en JavaScript. Al ser lenguajes diferentes, la comunicación directamente con código interpretado es imposible.
Esa no es una particularidad exclusiva de JavaScript, otros lenguajes como Python o PHP también son interpretados, pero lo que le da JS el toque de distinción es que en realidad no hay un intérprete único o universal del lenguaje. Python, por ejemplo, cuenta con un binario (código comprensible por el sistema operativo) en cada uno de los sistemas operativos que permite ejecutar cualquier código Python (la complejidad de Python no se queda ahí, pero es la referencia que nos interesa por ahora) al igual que PHP (un lenguaje centrado casi exclusivamente en servidores) tiene intérpretes para los sistemas operativos más populares y los servidores más utilizados (apache y nginx por ejemplo).
En cambio, JavaScript tiene múltiples intérpretes que no siempre siguen exactamente las mismas reglas (como referencia se puede revisar el sistema de módulos y su historia), esta característica tiene una doble interpretación, ya que aunque parece ser caótico (se está encaminando hacia una forma única de hacer las cosas) también le da cierta flexibilidad a la hora de presentar nuevas soluciones a los diferentes problemas.
Pero ¿cada intérprete puede tomar el código de manera diferente? Por supuesto que si, pero eso si sería caótico y por eso existen los estándares.
Sin estándar
En este caso se entiende JavaScript, pero cada intérprete tiene sus propias reglas, por lo que el mismo código es interpretado de diferente manera.
ECMA-262
Primero veamos que es ECMA, que según su propia web (https://www.ecma-international.org/) es:
“Ecma International is a Swiss based not-for-profit association officially established on 17 May 1961. It is headquartered in Geneva to be near the headquarters of other standards developing organizations such as the International Electrotechnical Commission (IEC), the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU).”
“Ecma International es una asociación sin ánimo de lucro con sede en Suiza, creada oficialmente el 17 de mayo de 1961. Tiene su sede en Ginebra, cerca de las sedes de otras organizaciones de normalización, como la Comisión Electrotécnica Internacional (CEI), la Organización Internacional de Normalización (ISO) y la Unión Internacional de Telecomunicaciones (UIT).”
Esa asociación mantiene múltiples estándares de los sistemas de comunicación e información.
Una lista completa de los estándares es: (https://www.ecma-international.org/publications-and-standards/standards/?order=category)
El modo de funcionar de la asociación, sus miembros actuales, la relación con otros estándares y más se puede consultar en el siguiente PDF: https://www.ecma-international.org/wp-content/uploads/presentingecma.pdf
Existen 4 estándares ECMA relacionados con JS:
– 262 – ECMAScript, especificaciones del lenguaje: https://www.ecma-international.org/publications-and-standards/standards/ecma-262/
– 402 – Las especificaciones de la internacionalización del ECMAScript: https://www.ecma-international.org/publications-and-standards/standards/ecma-402/
– 414 – El conjunto de estándares ECMAScript y la relación entre ellos: https://www.ecma-international.org/publications-and-standards/standards/ecma-414/
– 419 – Especificación de sistemas embebidos para ECMAScript: https://www.ecma-international.org/publications-and-standards/standards/ecma-419/
pero aquí nos interesa el ECMA-262 que define las reglas del ECMAScript que es el estándar que define JavaScript.
El primer ECMA-262 fue publicado en junio de 1997, 1 año y medio después de la creación de JS (diciembre 1995).
A partir de 2015 (esta versión fue muy significativa. Muchos la conocen como ECMA 6,una denominación coloquial, ya que en realidad es ECMA-262 6th publicación.) se publica anualmente en junio una actualización del estándar.
Hay mucho que decir sobre los estándares, sin duda, pero con este acercamiento nos alcanza para continuar.
Por lo pronto tenemos un lenguaje que el entorno en donde se usa no comprende, un estándar que define sus reglas para una lógica común se use donde se use y es evidente lo que nos falta: ¿Cómo funciona realmente JavaScript?
Completo
Cada entorno tiene su intérprete según su conveniencia y se sigue un estándar para permitir los mismos resultados con el mismo código. Entiéndase que un navegador limita las funcionalidades por razones de seguridad.
Intérpretes de JavaScript.
Un lenguaje interpretado necesita un medio para comunicarse con su entorno. Lo podemos llamar traductor si queremos tener una visualización más asociada a la interacción entre personas.
Estos intérpretes o traductores son desarrollados en lenguajes compilados cuyo código final es entendido de forma nativa por el entorno en cuestión. Ahora haremos un repaso a varios entornos populares donde se usa JavaScript, que interprete permite su “entendimiento” por el entorno y que lenguaje ha sido utilizado para realizar el intérprete.
Comencemos por los navegadores:
En este momento solo hay 3 motores diferentes de navegadores web: Chromium (Chrome), Mozilla Firefox y Safari.
Chromium emplea V8 para la interpretación de JavaScript. V8 está desarrollado en un 68,7% en C++. Además de usarse en Chromium, es usado por Node, Electrón, NWJS, y todos los navegadores que usan Chromium como base (Brave, Opera, Epic, y un largo etcétera)
Safari (al igual que Epiphany de Gnome) emplea WebKit que integra JavaScriptCore para la interpretación de JS en el navegador. JavaScriptCore está escrito mayormente en C++ (no tengo disponible los porcentajes).
FireFox utiliza SpiderMonkey, el primer intérprete de JS desarrollado por Brendan Eich (creador de JS) en 1995 y actualmente mantenido por la fundación Mozilla. En este momento sus lenguajes de desarrollo son C++ y Rust que también se implementa en otros proyecto (por ejemplo MongoDB)
¿Qué sucede cuando hay una nueva publicación del ECMA-262? Recordemos que esto sucede, en la actualidad, anualmente cada junio.
Lo que sucede es muy simple, hay que implementar los cambios publicados en el intérprete para que los programadores de JS puedan aprovechar (o no) los cambios.
En pocas palabras: JS funciona en muchos entornos gracias al trabajo en lenguajes como C, C++, Rust (incluso Java) por muchos programadores y grupos de trabajo anónimos que dan el poder a los programadores JS (a quienes no hay que quitarles merito por sus logros con JS) para poder desarrollar las soluciones en los diferentes entornos.
En un mundo universal como es el de la programación, el ego puede cegar la realidad de las cosas y por ello siempre es bueno tener claro como funciona nuestro entorno.
Para completar un repaso a otros intérpretes conocidos:
Capacitor: Convierte código JS, HTML, CSS a código nativo Android o iOS. Desarrollado en: Java, TypeScript, Swift, Objective-C, JS, C y Ruby: https://github.com/ionic-team/capacitor
React Native: Creación de aplicaciones nativas con la lógica de React adaptada a entornos móviles: Desarrollado en: JS, Java, C++, Objective-C, Objetive-C++, Starlak y otros: https://github.com/facebook/react-native
Native Script: Permite crear aplicaciones móviles con una lógica alineada con la lógica web pero respetando las características móviles (los layouts por ejemplo): Desarrollada en TypeScript, Java, JavaScript, Objective-C, CSS y Shell: https://github.com/NativeScript/NativeScript
Titanium: (open source y core principal del proyecto appcelerator (fue discontinuado el 1 / 3 / 2022 https://blog.axway.com/mobile-apps/changes-to-application-development-services) ) Permite crear aplicaciones nativas para Android e iOS usando JavaScript y una implementación de XML que respeta los layouts naturales de los sistemas operativos móviles. Desarrollado en: Objetive-C, Java, JavaScript, Roff, C++, EJS y otros: https://github.com/tidev/titanium_mobile
Seguramente me falta algún intérprete más (por ejemplo para IoT) pero ya nos vamos haciendo una idea clara de la integración antes mencionada.
Hasta aquí el artículo y recuerden, las comunidades unidas son fuertes como murallas de acero, las comunidades desunidas son como plumas al viento. No nos atropellemos entre nosotros y seamos capaces de generar comunidades fuertes que sirvan de inspiración para las siguientes generaciones.
