¿Cómo se convirtió Javascript en el más popular en el desarrollo web, mientras que los programadores a menudo dicen que es un mal lenguaje?

Se ha dicho que la democracia es la peor forma de gobierno, excepto todos los demás que se han probado.

– Winston Churchill

Porque es la única opción para el desarrollo web. Porque si esperamos hasta que tengamos un conjunto perfecto de herramientas con las cuales crear, entonces nunca se construirá nada. Debido a que todos estaríamos sentados alrededor de nuestras cuevas quejándose de que la primera rueda no es lo suficientemente suave para nuestro gusto (entonces, ¿por qué usar ruedas?), O que las ramitas que solían encender el fuego nos da astillas (entonces, ¿por qué no disfrutar comer 100? % crudo y con frío todo el tiempo?).

Piénselo: todo el mundo comienza con herramientas que son menos que ideales. Todos y sus vecinos, compañeros de cuarto y primos segundos expulsados ​​dos veces tienen quejas o sugerencias sobre lo que podría ser mejor. Hay personas que hacen esto extensamente, en lugar de construir algo nuevo. Se convierte en la razón de por qué están esperando algo, luego otro, y luego otro, como requisito previo antes de que “algún día” implementen una idea brillante de ellos. Para muchas de estas personas, “algún día” nunca llega.

Para todos los que hacen cosas, tenemos una forma diferente de ver las cosas:

Hacemos lo mejor que podemos con lo que tenemos, y luego trabajamos para mejorar lo que tenemos.

Ha pasado más de una década. Javascript hoy es muy superior a lo que era en 1995. Los motores WebKit y V8 modernos con compiladores JIT se acercan al rendimiento nativo de C, mientras que ES6 / ES7 / etc. han agregado funciones poderosas que con mayor frecuencia fueron citadas como “faltantes” en comparación con otros idiomas. Y lo más importante, es la única opción que está disponible de manera ubicua.

Al final, cada idioma tendrá críticas perfectamente válidas. La gente dice que Perl, Python, PHP, etc. son malos lenguajes. Y con la excepción de PHP, en muchos casos, es la mejor herramienta para el trabajo. O hará el trabajo, y es gratis, por lo que es mejor que una herramienta que no tiene, no sabe o no puede pagar.

Elija un idioma, cualquier idioma, y ​​construya algo, cualquier cosa, y luego descubra cómo mejorar lo que tenemos. Te deseo la mejor de las suertes.

Aquí están algunos de mis pensamientos sobre esto:

1. Muchos programadores con títulos (en los años 90) no tenían Javascript cuando estaban en la escuela. En su mayoría era C o C ++, por lo tanto, las mismas personas no pueden reprogramar fácilmente sus cerebros para usar un lenguaje de tipo más dinámico frente a uno de tipo más fuerte.
2. Se parece a C pero se comporta de manera diferente y este hecho solo molestaría a muchos programadores.
3. La abstracción fue fácil en un lenguaje C frente a Javascript.
4. Los programadores sin experiencia no tienen idea de cómo adaptarse y los programadores autodidactas hacen lo suyo independientemente de los principios de ingeniería de software.
5. Su código incorrecto puede ser visto fácilmente en público, por cualquier navegador. A los malos programadores no les gusta esto, la falta de habilidad ahora es visible para todo el departamento.
6. Falta de buenas herramientas de depuración y administración de memoria. (Chrome no existía cuando el idioma estaba allí)
7. DOM es MUDO para muchos (todavía hay programadores que no saben qué demonios era DOM incluso después de que comenzaron a usar JS).
8. En el contexto de la Web, hay demasiado código de spaghetti / no optimizado y el navegador se obstruye.
9. Uno nunca puede ser un experto, ya que el conocimiento del dominio JS no está restringido a un área, cualquier persona que quiera aprender a programar puede comenzar a escribir código que funcione (bueno o malo vendría con experiencia).
10. Legibilidad horrible: no es un factor importante para muchos, pero conozco personas que ponen todo el código en un archivo. Cuando otro programador recoge este archivo para re-factorizar, es una gran pérdida de tiempo, desplazarse hacia arriba y hacia abajo.
11. Demasiadas bibliotecas que conducen al problema de “demasiados cocineros en la cocina”, un elemento disuasorio para los novatos.
12. Diferencia entre falso, nulo, NaN e indefinido -> simplemente molesto.

Como lo veo, la belleza de WWW es que solo hay 3 idiomas en los que el servidor habla al cliente CSS, JS, HTML (sí, sé que simplifico demasiado).

Esto permite tanto: crear nuevos sitios web sin preocuparse de que algún navegador no lo entienda (al menos hasta cierto punto), y crear nuevos navegadores sin tener que proporcionar soporte para demasiados idiomas.

Cambiar a un idioma diferente parece un problema de huevo y gallina. Pero en realidad hay algunas formas de escapar de esto:

– puede “compilar” otros lenguajes a javascript (mecanografiado, elm, haxe, script de café, jsx …)

– podría intentar convencer a los proveedores de navegadores de que lo que realmente necesita es una especificación de un código de bytes de máquina virtual (como lo hicimos con Java o .Net), y luego tratar de establecer este nuevo lenguaje de bajo nivel como estándar de comunicación (que como explicado anteriormente fallaría por no ser compatible con versiones anteriores): este tipo falló y tuvo éxito, ya que ahora hay asm.js, que es un subconjunto de JavaScript (por lo que es compatible con versiones anteriores) que se ve tan bajo que puede compilar juegos escritos en C ++

– evolucione el lenguaje – Creo que este está más en línea con la forma de pensar de las personas que empujan a WWW hacia adelante durante décadas. Puede ver que la especificación Ecma Script 7 contiene muchas cosas nuevas. No estoy diciendo que todos los silbatos nuevos en ES7 sean movimientos en una buena dirección, pero sin un grupo de mutaciones, la evolución no tiene carne contra la cual presionar selectivamente. Puede ver cómo JS evolucionó de imperativo, global, hakish, “window.onclick = alert (‘lolz’);” en lenguaje casi funcional que usamos hoy

Existe la posibilidad de que ya lo supieras, y que la pregunta es más bien: ¿cómo es que incluso cuando hay TypeScript, ELM, Haxe, Coffe Script, ClosureScript, etc., las personas todavía acuden a JavaScript?

Bueno, no lo se. ¿Tal vez se trata de marketing o de recursos disponibles para las personas que desean aprender?

Personalmente uso TypeScript, pero veo que JS elige cada vez más todas las características de TypeScript que necesitaba, así que quizás algún día vuelva a JS vanilla.

En pocas palabras, JavaScript es el único idioma nativo del navegador web.

Es importante recordar que hasta principios de la década de 2000, JavaScript era un lenguaje de programación ampliamente despreciado. Casi todos trataron de evitarlo. Al mismo tiempo, varios otros idiomas intentaron insertarse en el navegador web … y fallaron.

Desde principios de la década de 2000, JavaScript se ha utilizado cada vez más para el desarrollo web front-end . En el back-end, gobernaron lenguajes como Java, PHP, Python, C ++, Ruby y Perl. Luego, en 2009, alguien pensó que era una buena idea poner este lenguaje retrasado en el fondo, y nació Node.

Por lo tanto, la popularidad de JavaScript en el desarrollo web es principalmente un fenómeno posterior a 2009. Personalmente, recuerdo que en los días previos al Nodo, a los programadores generalmente no les gustaba JavaScript y solo lo usaban de mala gana. ¡Cómo han cambiado las cosas!

Todavía no usaré JavaScript. Para el desarrollo front-end, prefiero los idiomas transpilados. Mi favorita es Amber Smalltalk.

Tenga en cuenta que, a pesar de los esfuerzos de ECMA para mejorar JavaScript, sigue siendo un lenguaje basura.

Javascript es un ejemplo perfecto del dicho “Las herramientas no son malas. Hay malas formas de usar herramientas ”. Javascript solía ser malo para el lado del servidor debido a sus limitaciones, hasta que hay una gran cantidad de otras tecnologías creadas que aumentaron las limitaciones de Javascript, y ahora de repente Javascript es perfecto. Los programadores que todavía dicen que Javascript es un mal lenguaje lo hacen porque no entienden el cambio radical que ha sucedido en la última década.

Debe comprender por qué el script Java solía ser malo para el lado del servidor

Javascript no tiene seguridad de tipo de tiempo de compilación

Esto solía ser un gran problema en los buenos tiempos de C / C ++. En aquel entonces, cuando tomabas un número entero y lo pegabas en una variable flotante, el compilador no generaba código para convertirlo. Simplemente trataría la misma secuencia de bits que comprendía el entero como un número flotante. Por lo tanto, no solo obtendrá un número extraño, sino que podría encontrarse con una situación en la que alguna operación podría anular el búfer y causar errores extraños y problemas de seguridad. Entonces, los lenguajes de programación tenían que ver con la seguridad del tipo de tiempo de compilación. Necesitabas el compilador para comprobar que no estás insertando un entero en un flotante sin llamar a la función correspondiente que convierte el entero en flotante

Esencialmente, OOP ha resuelto esto. Si cada constante está representada por una clase que tiene operaciones de lanzamiento asociadas con ella, entonces el compilador / intérprete básicamente puede llamarla para lanzarla detrás de escena sin que el programador especifique un lanzamiento explícito. Esencialmente, si todo es un Objeto, entonces el lenguaje proporciona una abstracción que facilita al programador.
En los años 90, no podíamos hacer de todo un Objeto, porque la memoria era costosa, y cualquier lenguaje que representara cada literal como un objeto era visto como ineficiente. Esto estuvo bien en el lado del cliente porque el Javascript solo estaría haciendo una cosa, pero en el servidor donde la granja de servidores está haciendo cientos de cosas simultáneamente, entonces cada bit de sobrecarga se multiplica
En la década de 2000, no nos importa si cada literal es un objeto. Las máquinas virtuales son mucho mejores en optimizaciones. Los objetos ya no son tan caros. La memoria es barata. En Javascript, cuando agrega un entero a una cadena, no se bloquea ni se queja, solo convierte el entero en una cadena y lo concatena. Esto es algo bueno ahora. Hace 30 años esto sería lento como el infierno

Lo que antes era malo ahora es bueno

Javascript se interpreta

Sí, lo mismo que la gente hablaba de Java. Java es lento porque se interpreta. Javascript es lento porque está interpretado. Sin embargo, resulta que los lenguajes que se ejecutan en máquinas virtuales pueden ejecutarse rápidamente en la mayoría de los casos porque la máquina virtual puede JIT compilación y optimización

Además, los idiomas compilados deben compilarse. Y la compilación es un dolor en el bubkiss para el programador … En serio. Los lenguajes que tienen compilación JIT dan un gran impulso de productividad al programador a costa de requerir más memoria y una CPU más rápida. En una era donde el costo de los programadores aumenta y el costo de la memoria / CPU baja, descargar algo de trabajo a la CPU / memoria es algo bueno

Lo que antes era malo ahora es bueno

Javascript no tiene subprocesos múltiples

Sí no. De hecho, se basa en los bucles de eventos para hacer varias cosas al mismo tiempo. ¿Sabes quién hizo esto? Windows 3.1 Sí Sí, muchos programadores más nuevos que son fanáticos de JavaScript no se dan cuenta de esto. Javscript comparte uno de sus principios básicos de diseño de un sistema operativo archiac. Recuerde que Windows 3.1 fue diseñado para ejecutarse en hardware con un solo subproceso. En aquel entonces, las aplicaciones GUI no le permitían tener múltiples ventanas abiertas. Windows 3.1 resolvió este problema al tener un bucle de eventos. El sistema operativo proporcionará una cola de eventos a una aplicación. La aplicación tenía bucles que capturaron un evento de la cola, hicieron algo con él y volvieron al siguiente evento. Cada acción en la interfaz de usuario publicó un evento en el bucle. Además, si deseaba hacer algo en segundo plano (por ejemplo, guardar un archivo), tenía que guardar una porción de datos, actualizar la IU para mostrar el progreso, escribir un evento en el bucle para guardar la siguiente porción, etc. . El sistema operativo / lenguaje no proporcionó una abstracción de devolución de llamada, pero esencialmente estaba implementando sus propias devoluciones de llamada

Más tarde, los desarrolladores del sistema operativo crearon esta abstracción llamada hilo. Un subproceso es una unidad de ejecución, y un programador escribe una rutina que se ejecuta en el subproceso. El sistema operativo gestiona la programación de subprocesos. Ejecutará un poco de código en ThreadA. Cuando el subproceso A requiere IO, coloca el subproceso A en el costado y comienza a ejecutar el código en el subproceso B. Cuando el subproceso que completa el subproceso A, reanuda el subproceso A desde donde se fue. De esta manera, cambia de un lado a otro entre los subprocesos A y B y parecen ejecutarse en paralelo. Lo bueno de esto es que simplificó el trabajo del programador de aplicaciones. Ahora, si necesita escribir una rutina que guarde el archivo, no necesita publicar eventos en el bucle. Simplemente tiene un bucle for que escribe una porción de datos a la vez, y mientras su programa está haciendo IO, el sistema operativo le da la CPU a algún otro hilo. Esto fue genial porque hace que los programadores trabajen más fácilmente

Finalmente, el hardware se puso al día para hacer posible el subprocesamiento múltiple real a nivel de la CPU, y el modelo de subprocesamiento fue excelente porque permitió que el mismo código se ejecute en una CPU de múltiples núcleos sin ningún cambio de código. Los desarrolladores que crecieron aprendiendo esto vieron esto como una gran cosa. Ven los hilos como geniales, y consideran que es realmente genial si el lenguaje les permite crear sus propios hilos. El middleware evolucionó para tener enormes servidores de aplicaciones que se ejecutan en máquinas de metal desnudo. Los servidores de aplicaciones como Apache / Tomcat tendrían un grupo de subprocesos para manejar cada solicitud. Una vez que se recibió una solicitud, llamará al código de la aplicación que atiende la solicitud en uno de los hilos. La aplicación hará lo que tiene que hacer y regresará y el servidor de aplicaciones devolverá el hilo al grupo. Esto funcionó bien durante décadas

Excepto que los hilos no son tan geniales. El mayor problema con los hilos es que hacer un seguimiento de los hilos y cambiar entre ellos es costoso para el sistema operativo. Muchos desarrolladores (especialmente muchos desarrolladores de Java) no entienden que no se puede iniciar un centenar de hilos. El segundo problema con los hilos es toda esta noción de escribir código seguro. No desea compartir el estado entre hilos, y si lo desea, puede minimizar la contención.

Al final del día, escribir código de subprocesos múltiples es difícil, y una cosa que hemos aprendido es que los subprocesos son geniales hasta que se los entreguemos a los desarrolladores. a) No queremos que los desarrolladores de aplicaciones inicien hilos yb) el lenguaje no debe permitir que los desarrolladores escriban código de tipo inseguro. Una forma de hacer lo primero es usar un lenguaje que se construya alrededor de la noción de objetos inmutables. Esa es una forma de hacer las cosas, pero no vamos a ir allí. Otra forma de hacerlo es hacer que cada servidor de aplicaciones tenga un solo subproceso. Puede ejecutar una granja de servidores de aplicaciones de subproceso único. ¡Los desarrolladores de aplicaciones no pueden arruinar la seguridad de los subprocesos si no pueden iniciar varios subprocesos y su código se llama en un solo subproceso! ¡Windows 3.1 nunca tuvo problemas de concurrencia! ¡Resulta que la programación basada en bucles de eventos es una programación segura para subprocesos!
¡Otra ventaja de un evento en bucle es que es mucho más liviano! No tiene la sobrecarga de cambio de contexto de subproceso. ¡Puede atender múltiples solicitudes simultáneamente usando un bucle de eventos! Recuerde que estamos llegando a los límites físicos de la CPU ahora. Literalmente no podemos hacer CPU mucho más rápido o más hilos. Ese limón ha sido exprimido. La única forma en que podemos ser más rápidos ahora es tener más CPU funcionando en paralelo y haciendo un mejor uso de la CPU. Por lo tanto, cualquier cosa que haga un mejor uso de la CPU (incluso a costa de la memoria y el tiempo del programador) es algo bueno. Además, la noción de funciones de devolución de llamada facilita el manejo del bucle de eventos.

Lo que antes era malo ahora es bueno

Los idiomas son herramientas. Las herramientas en sí mismas no son buenas ni malas. Así es como los usas. Un bolígrafo en sí mismo es un instrumento de escritura horrible si está escribiendo sobre losas de piedra. Sin embargo, cuando diseñas papel, el bolígrafo se convierte en un increíble instrumento de escritura.

Eso es lo que sucedió con Javascript. Javascript es esa pluma. La mayoría de las personas que afirman que Javascript es horrible son personas que se pasaron la vida troceando trozos de piedra.

El dominio de Javascript (como el lenguaje de secuencias de comandos en el navegador ahora estándar del lado del cliente que hace posible la funcionalidad en la página web sin recargar páginas) no es realmente un caso de popularidad.

Más bien es un caso de haber sido improvisados ​​gradualmente para un propósito único, y finalmente haber ganado una guerra de estándares. La popularidad es impulsada por una amplia masa de personas que eligen en el mercado. Por el contrario, la mayoría de las masas desconocen por completo las guerras de estándares y las causas que eventualmente conducen a la adopción de estándares de interoperabilidad.

Javascript ganó la guerra de los estándares porque los fabricantes de navegadores y los desarrolladores web lo apoyaron, y con el tiempo, las alternativas se desvanecieron en desuso porque los fabricantes de navegadores y los desarrolladores web no los respaldaron.

Los mejores no siempre ganan las guerras de estándares. Es por eso que terminamos con Windows inestable pero llamativo en lugar de OS / 2 sólido como una roca, y es por eso que Chrome está eclipsando actualmente a Firefox.

Los mejores a menudo ni siquiera están en la carrera. La estandarización no se trata de lo mejor. Tiene más que ver con quién está tirando dinero a dónde y cuándo.

No me importa mucho Javascript, pero es mejor que los que desplazó, especialmente VBScript, que fue uno de los muchos intentos de Microsoft para abrir autocráticamente sus propios caminos, esperando que el mundo lo siga; en lugar de cumplir con estándares como el resto del mundo buscaba hacer.

Entonces el mejor (Javascript) ganó, entre las opciones disponibles.

Javascript es mejor en términos de cumplimiento de estándares y soporte amplio, que es el nombre del juego de interoperabilidad. La mayoría de los desarrolladores web se preocupan más por la estandarización que por lo divertido que es trabajar con un idioma determinado.

En mi opinión no tan humilde, JS y sus variantes son realmente horribles. Esto se debe especialmente a su actitud extremadamente flexible hacia las estructuras de datos y el flujo de programas en general. En general se dice que C es un lenguaje tipado débil. Yo, como programador en C, me siento inseguro en el entorno de manejo de datos JS. Además, aunque no es causado directamente por JS, las posibles variaciones entre la ejecución y las diferencias de representación entre los navegadores desarrollan una mentalidad de que es normal tener diferentes salidas del mismo programa. Esto es muy inquietante si no eres un programador autodidacta.

Debido a que tanto los analizadores como los intérpretes eran fáciles de incorporar en los navegadores, cuando apareció Javascript por primera vez.

WWW estaba en su infancia, y los navegadores eran algo rudimentarios. Javascript permitió a los desarrolladores crear muchas cosas que el propio HTML no permitía ni admitía. Es importante tener en cuenta que Javascript sobrevivió a la prueba del tiempo: casi todas las demás extensiones web están en declive (applets de Java) o han quedado en desuso (Adobe Flash recientemente, Microsoft Active-X).

El mal estigma proviene de los abusos: los desarrolladores frecuentemente empujan una tecnología más allá de su propósito original, y a veces esto fracasa.

Por lo que me han explicado, la única razón por la que JS es grande y popular es por el tiempo de ejecución de Chrome JS y todos los proyectos que han surgido debido a él, como Node.js y mongoDB. Node es muy potente y fácil de configurar, y mongoDB es una de las principales soluciones noSQL más populares. Además, JS se ejecuta en máquinas cliente al acceder a una página web, no al servidor, por lo que a principios de Internet su infraestructura no se atascaría y se hizo muy popular en el mundo de desarrollo web.

Obviamente, casi todas las respuestas hasta ahora provienen de programadores que no tienen JavaScript o scripters front-end casuales.

Comencé a programar en BASIC en el VIC 20 y desde entonces me he movido a través de C, VB, VBScript, JavaScript, Java, ActionScript, ActionScript 3, C # y F #. La mayor parte de mis años profesionales los he pasado programando en C #, pero ahora casi todo lo que hago es JavaScript. Y eso es por elección ya sea para automatizar mi vida, construir drones, construir API: s, construir aplicaciones de navegador o teléfono o integrar sistemas.

La razón es esta: me hace feliz al permitirme concentrarme en lo que estoy tratando de construir. Es como un retroceso a los días pasados ​​por mi VIC 20 y C64 cuando todo era posible y el mundo estaba a mis pies.

Entonces, ¿eso significa que JS no es un lenguaje mal construido? No Hay algunas rarezas reales en el lenguaje de las que nunca podemos deshacernos debido a la compatibilidad con versiones anteriores. Y se están haciendo elecciones para la evolución del lenguaje con las que no estoy de acuerdo (estoy mirando sus clases).

Pero usar JavaScript es como estar de excursión en un paisaje sin pistas. Tienes que mirar hacia dónde vas o caerás en un arroyo o en un acantilado. Pero si trabaja en ello (y escucha a sus compañeros más experimentados) lo pasará en grande y encontrará los mejores y más efectivos caminos para avanzar con la sensación de satisfacción que se obtiene al tener el control.

En lenguajes más estrictos como Java y C #, siento que soy un niño de jardín de infantes en medio de una ciudad. Tengo que pasar la mayor parte de mi tiempo buscando la forma de seguir el idioma para permitirme ir a donde quiero. ¡No es tan divertido!

En primer lugar, realmente disfruto de Javascript. No obstante, hago esta pregunta todos los días sobre PHP; Quizás la respuesta sea la misma. Hasta cierto punto, la conveniencia y la facilidad sobrepasan las reglas de “corrección” o “bondad” de un idioma, y ​​si ese grado lo lleva más allá de la masa crítica en el ecosistema (entonces ahora tiene el incentivo de soporte, bibliotecas y marcos) entonces cómo “Bueno” el lenguaje no importa mucho, hasta que hay algunos manifestantes lo suficientemente fuertes.

No es el mejor lenguaje para el desarrollo web del lado del cliente, es el único lenguaje para el desarrollo web del lado del cliente.

El único lenguaje que los programadores creen que no es malo son los que nadie usa. Cada idioma es malo de una forma u otra.

Es el IMO más popular porque es el más fácil para principiantes. Esta baja barrera de entrada ha impulsado su crecimiento, creado una generación de programadores “casuales” y probablemente influyó en la dirección de JavaScript en su conjunto para continuar siendo lo más accesible posible. Con la accesibilidad vienen compromisos, y muchas áreas en las que JavaScript debe ajustarse como lenguaje solo comienzan a suceder lentamente con ECMCAcript 6 y más allá. Mientras tanto, seguirá teniendo una mala reputación.

Porque es esencial para muchas cosas que puede hacer en un navegador (es decir: validación de formularios, animaciones, etc.). Creo que dicen que es horrible debido a la portabilidad: si su javascript funciona como se esperaba en Chrome, Firefox, hay muchas posibilidades de que no lo haga en Internet Explorer (y aquí el problema proviene de IE).

Dos razones conectadas:

1. Cualquier programa que necesite ejecutarse en un navegador debe hacerse en Javascript.
2. Cada vez se pasa más tiempo del usuario en un navegador.

Obviamente hay más que eso, pero ese es el quid de la cuestión.

JavaScript ofrece a los desarrolladores front-end muchísimas opciones, realmente me dice si uno dice que es un mal lenguaje. ¿Comparado con que? Ni siquiera se le acerca nada que tenga como objetivo dar a los desarrolladores las mismas herramientas. Claro, siempre se puede refinar: ¿pero malo? No. Creo que la mayoría de los programadores que se quejan de JavaScript son personas que están acostumbradas a lenguajes que no hacen cosas muy impresionantes, lo que por supuesto es menos complejo y, por lo tanto, se rinden rápidamente tratando de comprender la sintaxis (“Nah man, JS apesta. “).

Divertidamente, la respuesta a ambas preguntas “¿Cómo se hizo tan popular JS?” Y “¿Por qué tantos desarrolladores odian a JS?” Es la misma:

Es el único juego en la ciudad.

Javascript es el único idioma que se ejecuta en los navegadores sin más complementos. Esa es la única razón por la cual el idioma es popular.