¿Qué pasa si JavaScript gana?

JavaScript ahora es parte del conjunto de herramientas de la mayoría de los desarrolladores que trabajan. ¿Qué pasa si los efectos de red lo convierten en el primer lenguaje de programación verdaderamente dominante?

Hace aproximadamente una década, una gran parte de la cultura de codificación cambió.

Lo que a menudo había sido una búsqueda solitaria, o una en la que la colaboración tuvo lugar con un grupo definido de colegas dentro de una empresa o proyecto de código abierto, se abrió paso en una experiencia social mucho más intrínseca. Todo, desde cómo compartimos código hasta cómo encontramos respuestas a cómo descubrimos nuevas tecnologías, se relacionó mucho más con las actitudes y acciones de otros programadores.

En resumen, las personas que fabrican software se conectaron en red al igual que sus computadoras en las décadas anteriores.

Las redes

El impacto de los efectos de red en la cultura de codificación se ha manifestado de muchas maneras, pero vale la pena examinar algunos de los más visibles:

  • Para el conocimiento sobre problemas de codificación y respuestas a preguntas comunes, Stack Overflow aumentó y rápidamente se convirtió en una fuente dominante de información confiable sobre programación. (Exención de responsabilidad requerida: estoy en el directorio de Stack Overflow, aunque mi experiencia aquí se basa en ser un codificador que solo confía en él para obtener respuestas útiles). Aunque las barreras para participar en la comunidad de Stack Overflow son bien conocidas, hay Sin duda, su habilitación de una red de conocimiento en torno a la codificación de respuestas amplificó la capacidad de descubrimiento de la información de programación y aceleró la idea de que la señal social sea un componente fuerte de la adopción de tecnología. Es mucho más probable que un framework o kit de herramientas que tenga su propia etiqueta con respuesta activa en Stack Overflow obtenga nuevos adoptantes.
  • Se siguió un patrón similar para colaborar en torno al código: GitHub surgió hace una década como una plataforma poderosa para compartir cada compromiso con un proyecto. Aunque su valor se presentó como la popularización de la herramienta de control de versiones distribuida GitHub, entonces naciente, el valor social de GitHub se ha extendido a ser una señal del valor o la fiabilidad del software alojado en la plataforma. Contar el número de estrellas, tenedores o observadores en un proyecto actúa como un proxy de cuánto se puede confiar en el código. GitHub tiene barreras reales, como la dificultad de aprender git o lo obtuso de organizarse en torno a los cambios en un proyecto, en lugar del proyecto en sí, y todos estos factores pueden dificultar la participación de algunos usuarios en la red. Pero a pesar de esas barreras, las señales sociales en GitHub configuran profundamente la adopción de herramientas y tecnologías por parte de los desarrolladores.
  • Finalmente, están las fuentes de información en red para noticias y discusión, entre las cuales las principales son Hacker News. Aunque es notoriamente la más hostil de estas grandes comunidades codificadoras en red, sin duda ayuda a promover y elevar nuevas tecnologías y nuevas ideas sobre cómo crear software. La amplificación de herramientas de Hacker News a menudo los ayuda a alcanzar una masa crítica en la adopción, y la discusión de un producto es otra forma de señal social que muchos en el mundo de la codificación usan para juzgar una plataforma en particular. En menor grado, las comunidades más centradas en el producto, como Product Hunt, también cumplen parte de esta función. (Y Product Hunt hace esto mientras es mucho más acogedor).

En cada uno de estos casos, si miramos más allá de los defectos de las comunidades que los habilitan, vemos un patrón más profundo: el software se evalúa en función de su éxito social y sus méritos sociales, en lugar de solo algunos méritos técnicos aparentemente "objetivos".

La tecnología siempre ha existido en un contexto social, y las evaluaciones del riesgo o la confiabilidad de una plataforma tecnológica siempre se han basado en indicadores sociales. Pero la aceleración de estos patrones, y la extensión de las redes sociales en torno al código para incluir a la mayoría de los codificadores que trabajan, significa que los indicadores institucionales (como "¿qué compañía financia su desarrollo?") Ahora ocupan el segundo lugar después de las señales comunitarias.

Del mismo modo, las indicaciones de arriba hacia abajo de madurez técnica como la documentación (a menudo un artefacto de inversión externa para hacer que una tecnología sea accesible para una nueva audiencia) se complementan, o incluso se eclipsan, mediante indicadores de abajo hacia arriba, como cuántas personas han marcado un marco, o cuántas personas responden comentarios sobre un juego de herramientas. Incluso los factores puramente sociales, como la cantidad de participantes en una sala de chat de Gitter o Slack sobre un proyecto, o la cantidad de personas que siguen un proyecto en las redes sociales, se evalúan cuando observamos las nuevas tecnologías.

Luego está la ley

Aunque casi todo lo que comparte en las redes sociales en estos días me dan ganas de golpear mi cabeza contra mi escritorio, el blogger de software Jeff Atwood ha tenido una serie de ideas valiosas a lo largo de los años. Quizás ninguno fue más profético que la idea capturada en su ley homónima:

[Una] aplicación que se puede escribir en JavaScript, eventualmente se escribirá en JavaScript.

La inspiración de Jeff se basa en el perspicaz "principio del menor poder" tal como lo articula Tim Berners-Lee, padre de la web. Pero especialmente cuando Jeff escribió esa publicación de blog, JavaScript todavía se consideraba algo así como un juguete (por ejemplo, Node.js no se inventaría por otros 2 años), y la idea de que todo se transfiriera al lenguaje parecía un poco absurdo . Naturalmente, como Internet es internet, casi una docena de años después, hay una comunidad entera dedicada a documentar las cosas que se transfieren o reescriben a JavaScript.

Pero la ley de Atwood habla de la capacidad de volver a implementar casi cualquier otro código en JavaScript. Dado que cualquier lenguaje completo de Turing debería ser capaz de implementar funcionalidades escritas en otros idiomas, esto hace que esta observación sea divertida, pero no particularmente reveladora sobre qué tipos de comportamientos podrían surgir como resultado. La ley de Atwood no dice nada sobre la adopción de JavaScript, solo su potencial para expresar ideas implementadas en otros idiomas.

Pero, ¿y si JavaScript es una red?

Hay muchas cosas que se consideran "JavaScript" en estos días. Existe el lenguaje abierto descrito en el estándar ECMAscript. Hay lenguajes adyacentes como TypeScript que ofrecen detalles a los codificadores a cambio de compatibilidad con el ecosistema de JavaScript. Hay entornos como Node. Existe el poder del acceso instantáneo a años de esfuerzo de codificación a través de herramientas de administración de paquetes como npm. Hay una cantidad casi infinita de infraestructura alrededor del idioma, e incluso más infraestructura que usa el idioma para proporcionar herramientas de construcción o automatización para otros idiomas. Y luego está la ubicuidad de la interpretación de JavaScript dentro de los navegadores web en miles de millones de dispositivos en todo el mundo.

Esta amplitud de contextos explica la popularidad y el dominio de JavaScript. De hecho, la encuesta más reciente de desarrolladores de Stack Overflow enumera casi el 70% de ellos que afirman que JavaScript es uno de los idiomas que usan. (Como se indicó anteriormente, algunos de los obstáculos para la participación en la comunidad de Stack Overflow pueden sesgar este tipo de encuesta, por lo que debemos tener en cuenta esos efectos distorsionadores, pero la tendencia general aquí es clara, incluso si tenemos en cuenta esas preocupaciones). El porcentaje de codificadores que usan JavaScript sigue aumentando, aumentando en aproximadamente un 15% en los últimos años, incluso a medida que otros lenguajes como Python siguen creciendo también.

Lo que esto sugiere es que JavaScript puede estar alcanzando la velocidad de escape como una red y como un ecosistema de tecnologías relacionadas. Para ser claros, aquí no hay un ganador se lleva todo: los idiomas específicos del dominio siempre tendrán sus áreas de enfoque únicas y valiosas. ¿Pero para la codificación de uso general? Todo, desde las macros de las hojas de cálculo hasta el hardware de Internet de las cosas, parece ser que tener JavaScript como una de las principales formas de hacer que las cosas sean programables.

Es imposible decir si esta idea de evaluar un lenguaje de programación como red social es una forma válida de juzgar la tecnología. Pero todo indica que el ciclo de retroalimentación alrededor del ecosistema de JavaScript está aumentando en fuerza. Aunque la mayoría de las herramientas de desarrollo "serias" son insistentemente políglotas (y, de hecho, todo indica que la mayoría de los codificadores que trabajan hacen uso de más de un idioma en su trabajo), puede tener sentido que las plataformas con visión de futuro inviertan desproporcionadamente en JavaScript para su futuros.

Glitch ❤ JavaScript

Por supuesto, trabajo en Glitch todo el día, así que sabes que nuestro equipo tiene una opinión al respecto. No se preocupe: Glitch puede ejecutar código en casi cualquier idioma común. Tenemos proyectos de Python, PHP y Ruby funcionando felizmente en la comunidad.

Pero hemos elegido JavaScript (y Node) como nuestra plataforma principal para Glitch, la que presentamos en nuestro trabajo. Hay muchas razones para esto (quiero decir, ¿has visto la depuración completa que Glitch te permite hacer?) Pero una de ellas es que somos un equipo pequeño y queremos asegurarnos de apostar. La tecnología que proporcionará el mayor valor para nuestra comunidad. Y creemos que nuestra inversión en el ecosistema de JavaScript solo se volverá más valiosa con el tiempo.

También observamos el valor de la red de aplicaciones, bibliotecas, módulos y fragmentos de código que viven en el ecosistema Glitch, y creemos que enfocar nuestra atención generará dividendos a medida que comenzamos a construir más herramientas para codificadores y aplicamos desarrollos más nuevos en el aprendizaje automático para Ayuda a facilitar la codificación. Elegir un dominio ayuda a garantizar que las cosas que creamos sean valiosas y aplicables e inmediatamente útiles, en lugar de esfuerzos difusos para servir a todos los idiomas sin elegir realmente uno para ser excelente.

Ahora, esto no está tallado en piedra. Si Haskell sale de la nada y se cuece en mil millones de navegadores y comienzan a enseñárselo a los niños en la escuela primaria, Glitch estará allí. Y definitivamente hay personas en el equipo de Glitch que desearían poder ofrecer una experiencia tan excelente en otros idiomas como lo hacemos en JavaScript. Pero con las tendencias donde están ahora, queríamos explicar nuestra lógica detrás de hacer una apuesta más grande en JavaScript y en Node, en lugar de simplemente decir "somos independientes del lenguaje". Hay teoría, y pensamiento, y un poco de historia, y una cantidad bastante buena de datos, y todas esas señales indican que algo especial está sucediendo aquí.

La verdad es que nunca hemos visto un lenguaje abierto convertirse en un lenguaje de programación casi universal para los codificadores. No sabemos qué tipo de beneficios podrían acumularse si la mayoría del esfuerzo de codificación comienza a suceder en un idioma, a menos que haya una razón particular para usar un lenguaje específico de dominio que insista en que lo hagamos de otra manera.

Podríamos estar en el precipicio de una era en la codificación sin precedentes, en la que podríamos ver algo nuevo en los patrones de adopción y uso de todo un lenguaje de programación. Ese potencial nos tiene entusiasmados y esperando con aliento para ver cómo se desarrolla todo el ecosistema. Pero aún más que eso, estamos entusiasmados de que todos estos desarrollos permitirán a la comunidad de Glitch crear aplicaciones que sean aún más expresivas y significativas, a la vez que sean aún más fáciles de realizar en código.

¡Estamos ansiosos por ver lo que creas!