Voy a agregar una actualización a esto porque creo que la aparición de JS en la web del lado del cliente ha sido mal entendida en algunos puntos clave a lo largo de los años.
No fue Ajax
No digo que Ajax no fuera importante para la evolución de la comprensión de JS como lenguaje, pero la lucha por el dominio del navegador del lado del cliente terminó mucho antes de que se acuñara el término Ajax.
No fue porque era el único juego en la ciudad.
Había Java Applets, Flash y VBScript. Escuché que incluso había otras opciones de secuencias de comandos en los años 90 (pero requerían los complementos IIRC). Java es muy popular pero los applets fueron un fracaso total. Eran feos y, a menudo, de queso suizo de seguridad, pero lo que es más importante, no creo que Java sea una buena opción por las razones que abordaré más adelante. Flash fue muy popular y tuvo una sólida posición durante varios años, pero incluso cuando Flash finalmente tenía opciones de SEO, no se usaban normalmente, lo que hacía que los sitios exclusivamente Flash fueran muy difíciles de descubrir. Incluso ahora, la mayoría de nosotros actualizamos Flash regularmente para poder ver películas, pero ese es el verdadero talón de Aquiles. La tecnología patentada en los navegadores es molesta. Y, por supuesto, VB, que solo funcionaría con IE, así que no.
El lugar correcto en el momento correcto es relevante pero no la respuesta completa
Sí, sin la ola web para montar, es posible que nunca hayamos visto JavaScript o un lenguaje de uso popular como lo hicimos tan pronto como lo hicimos. O tal vez tendríamos ...
Terminó siendo la herramienta perfecta para el dominio del problema
Yo diría que alrededor del año 2000 tuvimos los siguientes problemas:
- IE y Netscape solo habían acordado comenzar a jugar bien atendiendo a los mismos estándares DOM API y CSS y hemos tenido que lidiar con una tonelada de problemas heredados de navegador cruzado JS desde entonces, que apenas comienzan a ser manejables. sin la ayuda de herramientas de normalización JS DOM como jQuery post IE8
- Hubo toda una nueva generación de desarrolladores / diseñadores web que no eran todos necesariamente pesos pesados como programadores que buscaban mejorar su juego después de .com-bubble-burst cuando dejaron de darte un salario decente por presentarte en la puerta sin nada más. que la alfabetización básica en HTML y algunas habilidades de Photoshop.
- Había un nuevo chico CSS en la ciudad que ofrecía posibilidades intrigantes para lo que finalmente se llamaría DHTML, (más apropiadamente) DOM Scripting, (ahora de manera inapropiada) HTML5 (zomghtml5!).
Así que necesitábamos un lenguaje que fuera profundo, que ofreciera la capacidad de estructurar y diseñar una aplicación más avanzada con componentes portátiles / reutilizables en el lado del cliente pero también accesible para personas que no sabían mucho y solo necesitaban cosas aparecer / reaparecer al hacer clic en un botón.
Además, MS es la bestia desgarbadora / incompetente y / o dominada a través de prácticas anticompetitivas que a veces son, no pudo realmente tocar su implementación de API DOM no compatible durante una buena década sólida, aunque lograron agregue algo ocasional como el objeto XHR original y querySelectors en IE8.
Lo importante a tener en cuenta es que alrededor de 2005 habíamos logrado enterrar por completo la complejidad involucrada en el manejo de problemas entre navegadores que ya no era realmente un problema grave en el frente de JavaScript. La incapacidad de soportar CSS2 correctamente durante el tiempo que lo hicieron causó mucho más dolor. Para tener una idea del gran volumen y la profundidad de los problemas, recomiendo visitar quirksmode.org . No creo que esta sea una hazaña que podría haberse logrado con tanta facilidad y en tantas bibliotecas en Java, ciertamente no en VB y definitivamente no con ninguna estrategia de complemento cuyo objetivo es evitar todo el problema convirtiéndose en un tema completamente nuevo tipo de molestia
Otras características del lenguaje que tienen mucho sentido para la interfaz de usuario:
Funciones de primera clase: en mi experiencia, nada se presta mejor para el procesamiento asíncrono y los paradigmas basados en eventos que un lenguaje que haga que sus funciones sean de primera clase. Ambas preocupaciones se abordan regularmente en el trabajo de IU.
Tipos dinámicos: La conversión y verificación de tipos es una necesidad muy rara en JavaScript que ayudó a mantener el código conciso y ajustado. Las preocupaciones sobre la interfaz de usuario pueden volverse complejas y desordenadas muy rápidamente. Mantener el código estricto y ser absolutamente claro sobre el flujo de datos es fundamental para comprenderlo y modificarlo / mantenerlo.
No es proteccionista: durante muchos años, alguien ha estado predicando que debe protegerse de sus propios errores y de las cosas tontas que el otro tipo podría hacer con su código al hacer construcciones de código altamente rígidas e inflexibles e imposibles de entrometerse con la intención original que era escrito con y mucha gente ha estado escuchando. No diré que siempre están equivocados (podría pensarlo), pero diré que es el enfoque incorrecto para la interfaz de usuario web y creo que es un fenómeno que hemos estado produciendo, manteniendo y modificando clientes. Las interfaces gráficas de usuario secundarias a un ritmo mucho más rápido y con mayor facilidad que dicho trabajo se realizaban en lenguajes más restrictivos en el pasado. Ser capaz de cambiar las cosas sobre la marcha rápida y fácilmente hace que sea mucho más fácil tener esquemas de arquitectura dinámica / fluida que no requieran cantidades monumentales de indirección y abstracción, lo que en última instancia hace que sea más fácil ver qué demonios está sucediendo en su código y adelantar o manejar excepciones mucho más limpiamente. Es más fácil de mantener simplemente a través de la pura virtud de hacer posible ser más directo en todo lo que haces y con mucho menos código del que tomaría dada la otra filosofía.
¿Cómo se hizo popular JS? Ha demostrado ser una excelente herramienta para el trabajo una y otra vez. No es el lenguaje con el que estamos "atrapados" Es el lenguaje que puede haber inspirado una gran evolución en los idiomas populares en general. Y por eso, puedes agradecer a Brendan Eich y a todos los contemporáneos que ayudaron a poner la idea en su cabeza, por considerar a Scheme como una inspiración de diseño adecuada para el problema en cuestión más de lo que le gustaba Java.
