Portada
mis comunidades
otras secciones
!['Lo mejor que podemos hacer hoy a JavaScript es retirarlo', dice el creador de JSON, Douglas Crockford [ENG]](https://cdn.mnmstatic.net/cache/38/8d/media_thumb_2x-link-3706314.jpeg?1659965406)
#1:
Traducción automática:
JavaScript, el lenguaje de programación más popular del mundo según la mayoría de las encuestas, se ha convertido en una barrera para el progreso, según Douglas Crockford, creador de la especificación JSON (JavaScript Object Notation) utilizada en todas partes para serializar datos en las aplicaciones web.
Crockford hizo esta afirmación en una entrevista el mes pasado:
"Lo mejor que podemos hacer hoy a JavaScript es retirarlo. Hace veinte años, yo era uno de los pocos defensores de JavaScript. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JavaScript, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JavaScript".
Según una encuesta de StackOverflow realizada a principios de este año, JavaScript es utilizado por más del 65% de los desarrolladores, muy por delante del segundo clasificado, Python, con un 48% (sin tener en cuenta HTML, CSS y SQL, que no son lenguajes de propósito general). Se trata de un logro improbable teniendo en cuenta sus orígenes.
Brendan Eich inventó el lenguaje para Netscape en 1995, aparentemente en sólo 10 días. "En mayo hice 10 días de trabajo duro, no dormí mucho", dijo Eich en la conferencia dot.JS en 2018. En 2012 Eich dijo a Charles Severance de Computer que: "Entré a hacer... un lenguaje de programación para HTML, para que los diseñadores y programadores web lo usaran, incrustado directamente en la página web... no como Java, que era un lenguaje de profesionales en el que se ejecutaba código real con declaraciones de tipo, y había que escribir de forma que se compilara". Añadió que "el nombre es una total mentira. No está tan relacionado con Java como con un ancestro común, C, en la sintaxis".
Eich calificó el trabajo de "trabajo apresurado", pero también dijo que "sabía que habría errores, que habría lagunas, así que lo hice muy maleable como lenguaje. Eso ha permitido a los desarrolladores web hacer que sea lo que quieran".
¿Por qué JavaScript ha tenido un éxito tan rotundo?
Hay múltiples razones, entre ellas la previsión de Eich, la facilidad de aprendizaje y la tolerancia al código que sería un error en muchos lenguajes, como comparar cadenas con números y obtener un resultado de sentido común -aunque Eich calificó más tarde esto como "un gran arrepentimiento, porque eso rompe una importante propiedad matemática".
Otro factor importante es que la determinación de Google de hacer que las aplicaciones basadas en el navegador sean competitivas con el escritorio dio al mundo el motor V8 (2008), que junto con el SpiderMonkey de Mozilla y el JavaScript Core de Apple dieron al lenguaje un rendimiento asombroso compilado en JIT. En 2009, Ryan Dahl ideó Node.js, que permitía a V8 ejecutarse fuera del navegador. Dahl tenía en mente las aplicaciones de servidor, pero hoy en día Node.js y NPM (Node Package Manager) son también esenciales para el proceso de desarrollo de la mayoría de las aplicaciones web.
¿Proceso de desarrollo? Parte del problema al que se refiere Crockford es que, junto con el aumento de la capacidad, JavaScript ha adquirido mucha complejidad, y una aplicación típica hoy en día incluye un proceso de construcción utilizando WebPack, Rollup o algún otro bundler, muy lejos del concepto original de Eich.
Además, muchos desarrolladores web no escriben JavaScript, sino que escriben TypeScript, que compila a JavaScript. TypeScript fue inventado por Anders Hejlsberg en Microsoft, con la justificación de que la maleabilidad de JavaScript y la falta de seguridad de tipos lo hacían inadecuado para las aplicaciones grandes. TypeScript es ahora el lenguaje número tres en la encuesta mencionada anteriormente, y es una prueba de que JavaScript no es del todo querido. La llegada de WebAssembly, un formato binario al que pueden dirigirse lenguajes como C, C++, C# y Rust, es otra innovación que puede socavar el dominio de JavaScript.
"JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.
JavaScript está evolucionando con muchas nuevas características y el progreso puede seguirse aquí, aunque las demandas de compatibilidad significan que algunos defectos no pueden corregirse, y en el otro extremo la hinchazón de características es un riesgo constante.
El elegido por Crockford para sustituir a JavaScript, E, es un caso atípico. Creado por Mark Miller, Crockford y otros, E es un lenguaje orientado a objetos diseñado para la computación segura y, en palabras de Crockford, "elimina muchas de las partes malas de Java".
Sin embargo, Crockford también señala que JavaScript será difícil de cambiar, en particular porque es el lenguaje soportado por todos los navegadores para la manipulación del DOM (Document Object Model). Preguntado sobre qué puede sustituirlo ahí, Crockford dijo: "Hay dos dificultades. En primer lugar, aún no tenemos el siguiente lenguaje. Tiene que ser un lenguaje actor basado en capacidades mínimas y diseñado específicamente para la programación distribuida segura. No hay que pensar en nada menos.
"En segundo lugar, necesitamos que todos los fabricantes de navegadores lo adopten y que, al mismo tiempo, sustituyan el DOM por una interfaz bien diseñada. Buena suerte con eso".
JavaScript, el lenguaje de programación más popular del mundo según la mayoría de las encuestas, se ha convertido en una barrera para el progreso, según Douglas Crockford, creador de la especificación JSON (JavaScript Object Notation) utilizada en todas partes para serializar datos en las aplicaciones web.
Crockford hizo esta afirmación en una entrevista el mes pasado:
"Lo mejor que podemos hacer hoy a JavaScript es retirarlo. Hace veinte años, yo era uno de los pocos defensores de JavaScript. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JavaScript, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JavaScript".
Según una encuesta de StackOverflow realizada a principios de este año, JavaScript es utilizado por más del 65% de los desarrolladores, muy por delante del segundo clasificado, Python, con un 48% (sin tener en cuenta HTML, CSS y SQL, que no son lenguajes de propósito general). Se trata de un logro improbable teniendo en cuenta sus orígenes.
Brendan Eich inventó el lenguaje para Netscape en 1995, aparentemente en sólo 10 días. "En mayo hice 10 días de trabajo duro, no dormí mucho", dijo Eich en la conferencia dot.JS en 2018. En 2012 Eich dijo a Charles Severance de Computer que: "Entré a hacer... un lenguaje de programación para HTML, para que los diseñadores y programadores web lo usaran, incrustado directamente en la página web... no como Java, que era un lenguaje de profesionales en el que se ejecutaba código real con declaraciones de tipo, y había que escribir de forma que se compilara". Añadió que "el nombre es una total mentira. No está tan relacionado con Java como con un ancestro común, C, en la sintaxis".
Eich calificó el trabajo de "trabajo apresurado", pero también dijo que "sabía que habría errores, que habría lagunas, así que lo hice muy maleable como lenguaje. Eso ha permitido a los desarrolladores web hacer que sea lo que quieran".
¿Por qué JavaScript ha tenido un éxito tan rotundo?
Hay múltiples razones, entre ellas la previsión de Eich, la facilidad de aprendizaje y la tolerancia al código que sería un error en muchos lenguajes, como comparar cadenas con números y obtener un resultado de sentido común -aunque Eich calificó más tarde esto como "un gran arrepentimiento, porque eso rompe una importante propiedad matemática".
Otro factor importante es que la determinación de Google de hacer que las aplicaciones basadas en el navegador sean competitivas con el escritorio dio al mundo el motor V8 (2008), que junto con el SpiderMonkey de Mozilla y el JavaScript Core de Apple dieron al lenguaje un rendimiento asombroso compilado en JIT. En 2009, Ryan Dahl ideó Node.js, que permitía a V8 ejecutarse fuera del navegador. Dahl tenía en mente las aplicaciones de servidor, pero hoy en día Node.js y NPM (Node Package Manager) son también esenciales para el proceso de desarrollo de la mayoría de las aplicaciones web.
¿Proceso de desarrollo? Parte del problema al que se refiere Crockford es que, junto con el aumento de la capacidad, JavaScript ha adquirido mucha complejidad, y una aplicación típica hoy en día incluye un proceso de construcción utilizando WebPack, Rollup o algún otro bundler, muy lejos del concepto original de Eich.
Además, muchos desarrolladores web no escriben JavaScript, sino que escriben TypeScript, que compila a JavaScript. TypeScript fue inventado por Anders Hejlsberg en Microsoft, con la justificación de que la maleabilidad de JavaScript y la falta de seguridad de tipos lo hacían inadecuado para las aplicaciones grandes. TypeScript es ahora el lenguaje número tres en la encuesta mencionada anteriormente, y es una prueba de que JavaScript no es del todo querido. La llegada de WebAssembly, un formato binario al que pueden dirigirse lenguajes como C, C++, C# y Rust, es otra innovación que puede socavar el dominio de JavaScript.
"JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.
JavaScript está evolucionando con muchas nuevas características y el progreso puede seguirse aquí, aunque las demandas de compatibilidad significan que algunos defectos no pueden corregirse, y en el otro extremo la hinchazón de características es un riesgo constante.
El elegido por Crockford para sustituir a JavaScript, E, es un caso atípico. Creado por Mark Miller, Crockford y otros, E es un lenguaje orientado a objetos diseñado para la computación segura y, en palabras de Crockford, "elimina muchas de las partes malas de Java".
Sin embargo, Crockford también señala que JavaScript será difícil de cambiar, en particular porque es el lenguaje soportado por todos los navegadores para la manipulación del DOM (Document Object Model). Preguntado sobre qué puede sustituirlo ahí, Crockford dijo: "Hay dos dificultades. En primer lugar, aún no tenemos el siguiente lenguaje. Tiene que ser un lenguaje actor basado en capacidades mínimas y diseñado específicamente para la programación distribuida segura. No hay que pensar en nada menos.
"En segundo lugar, necesitamos que todos los fabricantes de navegadores lo adopten y que, al mismo tiempo, sustituyan el DOM por una interfaz bien diseñada. Buena suerte con eso".
#40:
#35 Sea de quien sea, no necesitamos un LENGUAJE para esto, necesitamos un standard de ejecucion, un runtime abierto y bien documentado que se soporte en todo navegador mediodecente. Que cada uno use el lenguaje que le salga de los hievos. WebAssembly es la idea. Marquen ustedes un hardware virtual y denme el codigo maquina y definicion de formato de los modulos ejecutables.
Un poco de orden, que la web es una gran casa de putas, y mucho es por que para 1 tio que hay con frialdad y ganas de hacer las cosas bien hay 100000 hippies con infulas e ideas de bombero.
Un poco de orden, que la web es una gran casa de putas, y mucho es por que para 1 tio que hay con frialdad y ganas de hacer las cosas bien hay 100000 hippies con infulas e ideas de bombero.
#12:
No han matado al COBOL van a matar al JavaScript ...
#66:
#49 JS no es basura hombre.
C es como los Stark, rectos, del Norte, fieles a su código. Pero a la hora de la verdad, sin un puto duro. Cuando curraba en C y assembler compartía piso y no llegaba a fin de mes.
Javascript es la familia Lannister: follan entre hermanos, beben, montan orgías... No son los más rectos, pero están podridos de pasta. Y son más divertidos.
Gano en un mes de javascript lo que ganaba en el 2006 en un año de C.
Así que un respeto, que JS siempre paga sus deudas.
Gracias Javascript!
C es como los Stark, rectos, del Norte, fieles a su código. Pero a la hora de la verdad, sin un puto duro. Cuando curraba en C y assembler compartía piso y no llegaba a fin de mes.
Javascript es la familia Lannister: follan entre hermanos, beben, montan orgías... No son los más rectos, pero están podridos de pasta. Y son más divertidos.
Gano en un mes de javascript lo que ganaba en el 2006 en un año de C.
Así que un respeto, que JS siempre paga sus deudas.
Gracias Javascript!
#61:
Cuando veo por aquí a alguno "sentando cátedra" y hablando en tono ranchera "y mi palabra es la ley" solo puedo recordarme a mí mismo hace algunos años. No sé si hará falta otro lenguaje u otro estándar o vete a saber qué pero lo que seguro hace falta es bastante humildad en el sector.
#6:
#4 Pues como desarrollador me vendría muy bien tener una indicación clara de que ja fallado algo en el JavaScript en lugar de sus silenciosamente deje de trabajar en un punto indeterminado.
Y no solo me pasa a mi. Hay montones de páginas que largan decenas de errores de JavaScript si uno se pone a mirar la consola.
Y no solo me pasa a mi. Hay montones de páginas que largan decenas de errores de JavaScript si uno se pone a mirar la consola.
#51:
#22 Entiendo que se refiere al ecosistema y no tanto al lenguaje. Lenguaje que, por mucho que digan aquí en menéame, es una maravilla. Los closures, o los async, lo thread safe del lenguaje, las funciones anónimas, son features maravillosas.
Ahora bien, el ecosistema es lo putísimo peor... que si libraries y frameworks que salen cada dos por tres, que esta libreria funciona solo en un tipo de paquetes, y esta otra es sólo un módulo, y esta es módulo pero ES6 y esta otra es sólo para CommonJS y esta otra es UMD y este otro grupo de desarrolladores dice que UMD caca y que mejor no hacer eso, etc etc etc. Ya sin entrar a la putísima mierda de frameworks frontend en donde todo está mal, nada tiene sentido. Complejidades, herramientas todavía más complicadas, etc. Convenciones y más convenciones por todos lados, sin ningún estandar efectivo. Typescript ayudando y poniendo orden y al mismo tiempo añadiendo una nueva layer y más y más caos. Después la barbaridades de añadir paquetes de terceros para cualquier gilipollez. Basura deprecated, anticuada, malas practicas por todos lados. MUY malos ingenieros por todos lados, aunque el ecosistema tampoco ayuda en absoluto.
Pero, en serio, Javascript como lenguaje está muy bien y ser el creador del mismo no significa que sepa de lo que está hablando.
Ahora bien, el ecosistema es lo putísimo peor... que si libraries y frameworks que salen cada dos por tres, que esta libreria funciona solo en un tipo de paquetes, y esta otra es sólo un módulo, y esta es módulo pero ES6 y esta otra es sólo para CommonJS y esta otra es UMD y este otro grupo de desarrolladores dice que UMD caca y que mejor no hacer eso, etc etc etc. Ya sin entrar a la putísima mierda de frameworks frontend en donde todo está mal, nada tiene sentido. Complejidades, herramientas todavía más complicadas, etc. Convenciones y más convenciones por todos lados, sin ningún estandar efectivo. Typescript ayudando y poniendo orden y al mismo tiempo añadiendo una nueva layer y más y más caos. Después la barbaridades de añadir paquetes de terceros para cualquier gilipollez. Basura deprecated, anticuada, malas practicas por todos lados. MUY malos ingenieros por todos lados, aunque el ecosistema tampoco ayuda en absoluto.
Pero, en serio, Javascript como lenguaje está muy bien y ser el creador del mismo no significa que sepa de lo que está hablando.
#52:
Potente, flexible, de sintáxis esotérica cuadno se usan cosas avanzadas y muy fácil romper cosas sin siquiera tener la menor idea de por qué. Con la ventaja de que funciona en muchos entornos diferentes una vez se ha estandarizado y se acabó la guerra de los navegadores. Mejor no matarlo, lo mejor es usar otro lenguaje como TypeScript o Elm y transpilar a JS.
Ahora, estoy de acuedo en que ES6 metió algnas cosas criminales (como las falsas clases) que lo hacen aún más lioso.
Ahora, estoy de acuedo en que ES6 metió algnas cosas criminales (como las falsas clases) que lo hacen aún más lioso.
#34:
#4 Se intentó con XHTML con la intención de que los motores HTML fuesen más ligeros y fue un fracaso. Ningún desarrollador lo usaba en modo estricto XML, entre muchas cosas, porque los usuarios algunas veces necesitan meter texto enriquecido y por muy bueno que fuera el editor para meter texto muchas veces sin saberlo generaban código html incorrecto, y los motores de validación tenían difícil decirle al usuario qué estaba mal y que lo entendieran sin acceder al código fuente del html generado.
Por no hablar de bugs que generaban html incorrecto y salían meses después de haber publicado una web y que sólo se daban con combinaciones concretas de datos metidos por los usuarios.
Así que para no quedar mal todo el mundo que lo usaba no validaba los errores y lo usaba como HTML normal. Luego se pasó a HTML 5 y la idea de validación por XML se abandonó.
Para que funcionara algo como lo que dices todos los navegadores y motores web en uso tendrían que ponerse de acuerdo y poner una fecha límite para que las empresas fueran cambiando de paradigma, y eso no va a pasar, ya que tal como está montada la web actualmente generaría muchísimos costes y ralentización de desarrollo a todas las empresas que se dedican a hacer webs, que van a poner todos los impedimentos que puedan, y porque basta que un solo navegador funcione como hasta ahora para que los usuarios migren a ese porque "ese funciona" y el resto es una mierda porque da errores. Suerte explicándoles que ese que funciona es el que realmente lo está haciendo mal.
Por no hablar de bugs que generaban html incorrecto y salían meses después de haber publicado una web y que sólo se daban con combinaciones concretas de datos metidos por los usuarios.
Así que para no quedar mal todo el mundo que lo usaba no validaba los errores y lo usaba como HTML normal. Luego se pasó a HTML 5 y la idea de validación por XML se abandonó.
Para que funcionara algo como lo que dices todos los navegadores y motores web en uso tendrían que ponerse de acuerdo y poner una fecha límite para que las empresas fueran cambiando de paradigma, y eso no va a pasar, ya que tal como está montada la web actualmente generaría muchísimos costes y ralentización de desarrollo a todas las empresas que se dedican a hacer webs, que van a poner todos los impedimentos que puedan, y porque basta que un solo navegador funcione como hasta ahora para que los usuarios migren a ese porque "ese funciona" y el resto es una mierda porque da errores. Suerte explicándoles que ese que funciona es el que realmente lo está haciendo mal.
#78:
Explicación: https://xkcd.com/927/
#25:
Yo lo que estoy hasta los webs es que cada día sale una nueva librería/framework de Javascript que reinventa la rueda.
Además que JavaScript surgió para cubrir unas necesidades de añadir comportamientos y dinamismo a las páginas pero están hiendo demasiado lejos, depurar y trabajar con ello es un tortura, por no mencionar las decenas de herramientas relacionadas con paquetes de módulos y managers y dependencias y configuraciones y bugs... estoy seriamente pensando en pasarme a back-end definitivamente. Estoy mucho más disfrutando con PHP ahora mismo, imaginaos como es mi vida de disfuncional ahora mismo
Además que JavaScript surgió para cubrir unas necesidades de añadir comportamientos y dinamismo a las páginas pero están hiendo demasiado lejos, depurar y trabajar con ello es un tortura, por no mencionar las decenas de herramientas relacionadas con paquetes de módulos y managers y dependencias y configuraciones y bugs... estoy seriamente pensando en pasarme a back-end definitivamente. Estoy mucho más disfrutando con PHP ahora mismo, imaginaos como es mi vida de disfuncional ahora mismo
#27:
Lo que hay que eliminar son las aplicaciones en Electron. Vienen del infierno.
#10:
JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.
Esta parte da miedito. Desde luego nunca entendí como la escalada sobre funciones web avanzadas partió de JavaScript sabiéndose cómo estaba montado, quizá fue por los mismos motivos de la eficacia de JavaScript: las prisas.
Esta parte da miedito. Desde luego nunca entendí como la escalada sobre funciones web avanzadas partió de JavaScript sabiéndose cómo estaba montado, quizá fue por los mismos motivos de la eficacia de JavaScript: las prisas.
Comentarios
No han matado al COBOL van a matar al JavaScript ...
#12 Lo de matar lenguajes es como matar idiomas... Como decían en Maquinavaja 2 "me pase 45 años sin poder hablar catala y vas a venir tu a tocarme los h***os con el castellano"
#12 Veo lo tuyo y subo a No han matado el Java
Traducción automática:
JavaScript, el lenguaje de programación más popular del mundo según la mayoría de las encuestas, se ha convertido en una barrera para el progreso, según Douglas Crockford, creador de la especificación JSON (JavaScript Object Notation) utilizada en todas partes para serializar datos en las aplicaciones web.
Crockford hizo esta afirmación en una entrevista el mes pasado:
"Lo mejor que podemos hacer hoy a JavaScript es retirarlo. Hace veinte años, yo era uno de los pocos defensores de JavaScript. Su combinación de funciones anidadas y objetos dinámicos era brillante. Pasé una década tratando de corregir sus defectos. Tuve un pequeño éxito con ES5. Pero desde entonces, ha habido un gran interés en inflar aún más el lenguaje en lugar de mejorarlo. Así que JavaScript, como los demás lenguajes dinosaurios, se ha convertido en una barrera para el progreso. Deberíamos centrarnos en el próximo lenguaje, que debería parecerse más a E que a JavaScript".
Según una encuesta de StackOverflow realizada a principios de este año, JavaScript es utilizado por más del 65% de los desarrolladores, muy por delante del segundo clasificado, Python, con un 48% (sin tener en cuenta HTML, CSS y SQL, que no son lenguajes de propósito general). Se trata de un logro improbable teniendo en cuenta sus orígenes.
Brendan Eich inventó el lenguaje para Netscape en 1995, aparentemente en sólo 10 días. "En mayo hice 10 días de trabajo duro, no dormí mucho", dijo Eich en la conferencia dot.JS en 2018. En 2012 Eich dijo a Charles Severance de Computer que: "Entré a hacer... un lenguaje de programación para HTML, para que los diseñadores y programadores web lo usaran, incrustado directamente en la página web... no como Java, que era un lenguaje de profesionales en el que se ejecutaba código real con declaraciones de tipo, y había que escribir de forma que se compilara". Añadió que "el nombre es una total mentira. No está tan relacionado con Java como con un ancestro común, C, en la sintaxis".
Eich calificó el trabajo de "trabajo apresurado", pero también dijo que "sabía que habría errores, que habría lagunas, así que lo hice muy maleable como lenguaje. Eso ha permitido a los desarrolladores web hacer que sea lo que quieran".
¿Por qué JavaScript ha tenido un éxito tan rotundo?
Hay múltiples razones, entre ellas la previsión de Eich, la facilidad de aprendizaje y la tolerancia al código que sería un error en muchos lenguajes, como comparar cadenas con números y obtener un resultado de sentido común -aunque Eich calificó más tarde esto como "un gran arrepentimiento, porque eso rompe una importante propiedad matemática".
Otro factor importante es que la determinación de Google de hacer que las aplicaciones basadas en el navegador sean competitivas con el escritorio dio al mundo el motor V8 (2008), que junto con el SpiderMonkey de Mozilla y el JavaScript Core de Apple dieron al lenguaje un rendimiento asombroso compilado en JIT. En 2009, Ryan Dahl ideó Node.js, que permitía a V8 ejecutarse fuera del navegador. Dahl tenía en mente las aplicaciones de servidor, pero hoy en día Node.js y NPM (Node Package Manager) son también esenciales para el proceso de desarrollo de la mayoría de las aplicaciones web.
¿Proceso de desarrollo? Parte del problema al que se refiere Crockford es que, junto con el aumento de la capacidad, JavaScript ha adquirido mucha complejidad, y una aplicación típica hoy en día incluye un proceso de construcción utilizando WebPack, Rollup o algún otro bundler, muy lejos del concepto original de Eich.
Además, muchos desarrolladores web no escriben JavaScript, sino que escriben TypeScript, que compila a JavaScript. TypeScript fue inventado por Anders Hejlsberg en Microsoft, con la justificación de que la maleabilidad de JavaScript y la falta de seguridad de tipos lo hacían inadecuado para las aplicaciones grandes. TypeScript es ahora el lenguaje número tres en la encuesta mencionada anteriormente, y es una prueba de que JavaScript no es del todo querido. La llegada de WebAssembly, un formato binario al que pueden dirigirse lenguajes como C, C++, C# y Rust, es otra innovación que puede socavar el dominio de JavaScript.
"JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.
JavaScript está evolucionando con muchas nuevas características y el progreso puede seguirse aquí, aunque las demandas de compatibilidad significan que algunos defectos no pueden corregirse, y en el otro extremo la hinchazón de características es un riesgo constante.
El elegido por Crockford para sustituir a JavaScript, E, es un caso atípico. Creado por Mark Miller, Crockford y otros, E es un lenguaje orientado a objetos diseñado para la computación segura y, en palabras de Crockford, "elimina muchas de las partes malas de Java".
Sin embargo, Crockford también señala que JavaScript será difícil de cambiar, en particular porque es el lenguaje soportado por todos los navegadores para la manipulación del DOM (Document Object Model). Preguntado sobre qué puede sustituirlo ahí, Crockford dijo: "Hay dos dificultades. En primer lugar, aún no tenemos el siguiente lenguaje. Tiene que ser un lenguaje actor basado en capacidades mínimas y diseñado específicamente para la programación distribuida segura. No hay que pensar en nada menos.
"En segundo lugar, necesitamos que todos los fabricantes de navegadores lo adopten y que, al mismo tiempo, sustituyan el DOM por una interfaz bien diseñada. Buena suerte con eso".
#35 Sea de quien sea, no necesitamos un LENGUAJE para esto, necesitamos un standard de ejecucion, un runtime abierto y bien documentado que se soporte en todo navegador mediodecente. Que cada uno use el lenguaje que le salga de los hievos. WebAssembly es la idea. Marquen ustedes un hardware virtual y denme el codigo maquina y definicion de formato de los modulos ejecutables.
Un poco de orden, que la web es una gran casa de putas, y mucho es por que para 1 tio que hay con frialdad y ganas de hacer las cosas bien hay 100000 hippies con infulas e ideas de bombero.
#40 Los hippies pasamos de todo. No nos cargues con los pecados de otros.
#65 Ya sabes a quienes me refiero.
#40 No por dios, otra máquina virtual más no, por favor.
#93 Hombre, maquina virtual vas a tener, pero en vez de tener putas mierdas inmantenibles de JS como ahora, tener un virtual hard. Que quieres, bajar codigo x86(-64), ARM(64),... a cliente y ejecutarlo ?
#99 No, pero no es necesario implementar un compilador, una VM con sus opcodes, su pila y su hardware virtual. Sólo el bucle de decodificación y ejecución de opcodes es terriblemente ineficiente, a menos que implementes un retraductor binario por ejemplo (mal llamados recompiladores), pero eso incrementa la complejidad una barbaridad.
Mi opinión personal es que, con una API bien diseñada, con un intérprete simple es más que suficiente.
Y a las malas, si no hay más remedio que tirar por una VM, al menos que sea una implementación en base a registros, no de pila (Java, te miro a tí ).
#40 un nuevo standard
Cuando veo por aquí a alguno "sentando cátedra" y hablando en tono ranchera "y mi palabra es la ley" solo puedo recordarme a mí mismo hace algunos años. No sé si hará falta otro lenguaje u otro estándar o vete a saber qué pero lo que seguro hace falta es bastante humildad en el sector.
#61 JAMAS!!!
#61 En mis ya muchos años dentro del sector he aprendido que cuanto más pontifica un programador, menos sabe.
Explicación: https://xkcd.com/927/
Lo que hay que eliminar son las aplicaciones en Electron. Vienen del infierno.
#27 por Dios, escuchen a este hombre.
#27 Exacto. Y se dice poco.
#22 Entiendo que se refiere al ecosistema y no tanto al lenguaje. Lenguaje que, por mucho que digan aquí en menéame, es una maravilla. Los closures, o los async, lo thread safe del lenguaje, las funciones anónimas, son features maravillosas.
Ahora bien, el ecosistema es lo putísimo peor... que si libraries y frameworks que salen cada dos por tres, que esta libreria funciona solo en un tipo de paquetes, y esta otra es sólo un módulo, y esta es módulo pero ES6 y esta otra es sólo para CommonJS y esta otra es UMD y este otro grupo de desarrolladores dice que UMD caca y que mejor no hacer eso, etc etc etc. Ya sin entrar a la putísima mierda de frameworks frontend en donde todo está mal, nada tiene sentido. Complejidades, herramientas todavía más complicadas, etc. Convenciones y más convenciones por todos lados, sin ningún estandar efectivo. Typescript ayudando y poniendo orden y al mismo tiempo añadiendo una nueva layer y más y más caos. Después la barbaridades de añadir paquetes de terceros para cualquier gilipollez. Basura deprecated, anticuada, malas practicas por todos lados. MUY malos ingenieros por todos lados, aunque el ecosistema tampoco ayuda en absoluto.
Pero, en serio, Javascript como lenguaje está muy bien y ser el creador del mismo no significa que sepa de lo que está hablando.
#51 Digamos que no hay otra alternativa a la altura para su nicho.
#51 llevo unos cuantos años sin desarrollar y la verdad es que con JS y las funcionalidades que comentas me lo pasaba pipa. Posiblemente es el que más he disfrutado de todos los que he tocado, que son unos pocos. Pero de repente... lo de siempre...
Postuware
Lo que yo haría es obligar que los navegadores por defecto no cargaran ninguna página con errores de HTML, Javascript, CSS, imágenes que no cargan o lo que sea. Que los creadores tengan presión para hacerlo medianamente bien.
#4 Pues como desarrollador me vendría muy bien tener una indicación clara de que ja fallado algo en el JavaScript en lugar de sus silenciosamente deje de trabajar en un punto indeterminado.
Y no solo me pasa a mi. Hay montones de páginas que largan decenas de errores de JavaScript si uno se pone a mirar la consola.
#6 Cómo Menéame
#6 Pero eso se puede saber, no?
#17 no siempre es sencillo de encontrar
#64 Incluso interceptando el error, puedes seleccionar una opción en el navegador para que pare en donde se produce cualquier error interceptado.
#55 A veces no, pero no porque no sepas dónde se produce, si no porque puede depender de pasos previos. Pero está ya sería otra cosa, no?
#6 JS no falla silenciosamente, otra cosa es que pongas try catch y ocultes el error, pero eso no es problema del lenguaje ( y aún así el Firefox y creo que el chrome se paran en los errores cuando se producen independientemente de que estén capturados)
Cc #17 por supuesto que se puede saber
#6 Porque los hay.
Empiezas a corregir el primero, hasta que se acabe el último.
El problema es ya de librerías de terceros.
#6 Por eso se usa TypeScript.
#6 porque javascript pertenece al pueblo, y casi cualquiera puede programar en JS (sin ser un puto friki informático :p) y pasa lo que pasa
#6 Una indicacion clara como el error en la consola? no se que mas quieres/necesitas
Si ademas conectas tu applicacion a Datadog , Sentry o LogRocket (por mencionar un par) ademas puedes ver los errores en produccion.
Si tienes un error tracking confuso es probable que apliques try/catch de forma turbia
#4 Concuerdo. Esa carrera para que los navegadores se lo coman todo es muy contraproducente
#4 Se intentó con XHTML con la intención de que los motores HTML fuesen más ligeros y fue un fracaso. Ningún desarrollador lo usaba en modo estricto XML, entre muchas cosas, porque los usuarios algunas veces necesitan meter texto enriquecido y por muy bueno que fuera el editor para meter texto muchas veces sin saberlo generaban código html incorrecto, y los motores de validación tenían difícil decirle al usuario qué estaba mal y que lo entendieran sin acceder al código fuente del html generado.
Por no hablar de bugs que generaban html incorrecto y salían meses después de haber publicado una web y que sólo se daban con combinaciones concretas de datos metidos por los usuarios.
Así que para no quedar mal todo el mundo que lo usaba no validaba los errores y lo usaba como HTML normal. Luego se pasó a HTML 5 y la idea de validación por XML se abandonó.
Para que funcionara algo como lo que dices todos los navegadores y motores web en uso tendrían que ponerse de acuerdo y poner una fecha límite para que las empresas fueran cambiando de paradigma, y eso no va a pasar, ya que tal como está montada la web actualmente generaría muchísimos costes y ralentización de desarrollo a todas las empresas que se dedican a hacer webs, que van a poner todos los impedimentos que puedan, y porque basta que un solo navegador funcione como hasta ahora para que los usuarios migren a ese porque "ese funciona" y el resto es una mierda porque da errores. Suerte explicándoles que ese que funciona es el que realmente lo está haciendo mal.
#34 Los formatos de texto son caca. Pero mas alla de texto o no texto, hace falta fijar un entorno de ejecucion, hardware virtual descubrible y con versionado pero sin ser una casa de putas. Y luego WebAssembly o algo en esa via, pero ese mismo esta bien.
#44 Por qué los formatos de texto son caca?
HTML es caca?
JSON es caca?
Yaml es caca?
#83 Por que son, por naturaleza, mas laxos, mas propensos a problemas de seguridad y menos optimos de procesar. Pero bueno, pa ciertas cosas pues se pueden usar. Pero una web basada en TLVs binarios con webassembly y tal, con un entorno de hardware virtual bien definido, y nos iria mucho mejor que con la casa de putas que tenemos montada ahora.
#85 No veo.por que tienen que ser más propensos a problemas de seguridad....
Para ciertas cosas no es que "se puedan usar" es que son la mejor solución. Por ejemplo para definir GUIs
#4 no cargarnia ni una, y si ademas añades los temas de accesibilidad entonces se cierra internet
#4 selección darwiniana: navegador que se haga de la vista gorda si hay errores de HTML y que renderice cómo pueda, tendrá una gran ventaja evolutiva comparado a navegador estricto que no presenta nada hasta que el HTML sea correcto.
#4 Si el problema de JS no son los errores. Eso es lo de menos!
#4 Yo estoy en desacuerdo. Me gustaba la internet de geocities, donde cualquier chaval de 12 años podía tener su sitio con un diseño horrible y mal hecho. Le daba mil vueltas a la internet con diseños cuquis actual.
JavaScript ha explotado en popularidad en pocos años y sí, el ecosistema es horriblemente complejo. Es un chiste constante, incluso entre los desarrolladores de JS a tiempo completo, lo loco que se ha vuelto. Ninguno de nosotros puede seguir el ritmo", confesó un desarrollador en un debate reciente en Hacker News.
Esta parte da miedito. Desde luego nunca entendí como la escalada sobre funciones web avanzadas partió de JavaScript sabiéndose cómo estaba montado, quizá fue por los mismos motivos de la eficacia de JavaScript: las prisas.
#10 ¿?
A qué te refieres exactamente?
#22 Pues que JavaScript fue programado aprisa y sin “pensar” mucho en los efectos colaterales que podría tener extender de él, y al final resulta en un código tedioso de mantener y depurar...
#10 Fue porque Google, a principios de siglo, decidió que a partir de entonces Javascript iba a ser la solución para crear cualquier tipo de aplicación en la web.
#10 ¿Por qué tienes que seguir el ritmo? El bleeding edge es precisamente así. Mejor deja pasar un poco de tiempo y quédate con los supervivientes. Yo llevo más de 5 años con React y ExpressJS, y desde que empecé he cambiado mi manera de hacer React como 3 veces en total. Por supuesto, no estoy al día de absolutamente todas las librerías que salen todos los días. Pero tampoco lo están ninguno de los programadores de todos los demás lenguajes de programación que sacan librerías a menudo.
El problema es que no hay ningún sustituto para Javascript en frontend. Todas las alternativas han sido deliberadamente peores: ActiveX, Flash, Java Applets, Silverlight. Todas ellas estaban basadas en el lock-in y el "sólo nuestro navegador o nuestras herramientas". Con WebAssembly quizás eso cambie, pero primero tenemos que ver algo que no caiga deliberadamente en los problemas anteriores (por ejemplo Blazor va de nuevo a "solo nuestro framework y nuestras herramientas").
Con respecto al backend, Javascript ofrece alternativas más sencillas que muchos sistemas actuales (excepto NestJS) y al mismo tiempo permite compartir código entre el frontend y el backend. Por ejemplo via NextJS. Esa es una combinación que muy pocos lenguajes de programación pueden ofrecer. De nuevo, WebAssembly puede cambiar eso, pero sólo si la gente deja de obsesionarse con sus herramientas propietarias y su navegador propietario.
Lo cual significa que tendremos Javascript para rato.
#76 Exactamente. React y Express son de 2013, no hace falta estar todo el dia cambiando de framework. Cambias una libreria aqui, otra por alla ... te preguntas porque hay que escribir todo ese codigo para usar redux saga, cambias a useEffect .. te das cuentas de que es una mierda y vuelves a Redux, luego cambias RecoilJS que luego no funciona por dios sabe que incompatibilidad con react asi que pruebas Jotai y asi hasta que te retiras ...
#2 y mandas al paro a tropecientas mil personas. genial idea.
Potente, flexible, de sintáxis esotérica cuadno se usan cosas avanzadas y muy fácil romper cosas sin siquiera tener la menor idea de por qué. Con la ventaja de que funciona en muchos entornos diferentes una vez se ha estandarizado y se acabó la guerra de los navegadores. Mejor no matarlo, lo mejor es usar otro lenguaje como TypeScript o Elm y transpilar a JS.
Ahora, estoy de acuedo en que ES6 metió algnas cosas criminales (como las falsas clases) que lo hacen aún más lioso.
Esto sin hablar de la cantidad de scripts maliciosos que hay, gracias a él.
Saludos
#5 los habria igual en cualquier otro lenguaje universal para todos los navegadores
Yo lo que estoy hasta los webs es que cada día sale una nueva librería/framework de Javascript que reinventa la rueda.
Además que JavaScript surgió para cubrir unas necesidades de añadir comportamientos y dinamismo a las páginas pero están hiendo demasiado lejos, depurar y trabajar con ello es un tortura, por no mencionar las decenas de herramientas relacionadas con paquetes de módulos y managers y dependencias y configuraciones y bugs... estoy seriamente pensando en pasarme a back-end definitivamente. Estoy mucho más disfrutando con PHP ahora mismo, imaginaos como es mi vida de disfuncional ahora mismo
#25 Muy guapo ese "hiendo".
#31 #32 ay, mil perdones, me acabo de dar cuenta, sirve la excusa del autocorrector?
#25 yendo* en lugar de hiendo.
PHP más JavaScript, huye, sal corriendo y no vuelvas a ese proyecto
#25 Pues yo llevo como 5 años con React y ExpressJS (y amigos, como NextJS) y no me da problemas. Eso sí, te doy la razón con Angular y NestJS. Que ganas tienen esos de reinventar la rueda y reinventarla cuadrada.
#25 Al menos a PHP le han sacado algo de brillo en sus últimas versiones
No sé si matar JavaScript, pero que dejen de sacar librerías por dios. Vue está bien, por ejemplo. Que dejen de reinventar la rueda.
#29 y como vamos a saber si un numero es par o impar???!!!!
#38 dividiendo por dos, si el resto es 0 es par, sino, impar
Y el cabron lo dice ahora.....
¿Qué tiene que ver lo bien o mal que estén hechas las páginas con el lenguaje en sí?. Y ¿Que soluciona ser estrictos con la creación web? Dentro de unos márgenes, Internet está hecho para comunicar, el virtuosismo o purismo informático es otra cosa, estará bien pero no es de lo que va Internet.
A estas alturas me conformo con que encuentren al autor de los conceptos transpilador y transpilación y lo azoten con el cable de la impresora ( el paralelo, no el USB)
#36 Vas a tener que azotar a muchos veteranos. Transpilación no es más que un nombre nuevo para compilación.
#69 No, transpilación es un nuevo termino precisamente para distinguirse de compilación. La compilación es convertir código fuente en código binario ejecutable directamente por la máquina destino. Transpilación no tiene binarios, es otro código fuente que debe ser compilado/interpretado por otro compilador para generar el verdadero binario.
Un ejemplo sorprendente de transpilación es Java, que no genera un binario, genera un código fuente en ensamblador que la JVM compila al binario verdadero.
#134 #69 Un transpilador es un caso particular de compilador en el que la compilación se realiza entre dos lenguajes con un nivel similar de abstracción.
Por tanto, la compilación de código fuente Java a bytecode no es una transpilación.
Ni de coña.
Ninguna de las alternativas tiene el ecosistema de node ahora mismo. Que vale que ese ecosistema está lleno de mierda, pero no es viable hacer lo que dice aún.
En cualquier caso, yo también espero que JavaScript, node y, sobretodo, el pufo de utilizar npm para proyectos front end que no corren en node y necesitan polyfills por todas partes, desaparezca pronto.
#50 Node es una puta perversión… Espero que el inventor arda en el infierno.
#89 #50 El inventor ya dijo que renunciaba a el y ahora esta creando Deno
https://deno.land/
#26 Para que?
Sí, como Flash, que lo "jubilaron" y ahora tenemos un montón de minijuegos que no funcionan.
Si "quitan" JavaScript lo que acabará ocurriendo es que la gente tendrá que usar dos navegadores de Internet, uno moderno y otro antiguo, para poder acceder a páginas web cuyos autores no piensan modificar porque las han hecho gratis y demasiado si pagan ellos el hospedaje de su bolsillo.
Lo que tienen que hacer en JS es permitir "programar bien", por ejemplo, permitir usar tipos de dato definidos (int, float, double... pero aún mejores), pero sin renunciar a la opción de usar tipos de dato como ahora, que van en función de lo que declaras. Eso permitiría programar aplicaciones web muy robustas si el programador quiere, y luego si no quiere, hacer las cosas un poco como ahora.
¿Opción más realista? Que los navegadores aceptasen TypeScript.
Esperemos que webassembly progrese y haga honor a lo de javascript killer
#11 JS no lo tumba ni cristo. Ojala
#11 #21 #15 JS va a durar mas que Cobol ... los dev de JS tienen el trabajo mas asegurado que los funcionarios
#11 Eso no va a suceder mientras sea necesario manipular HTML, ya que no tiene acceso directo a DOM (Los elementos de HTML) (se accede via JS y no hay planes para modificar esto)
#21 wasm no puede llamar a JS y JS modificar el DOM? con una pequeña lib valdria
#37 WASM está pensando para ejecutar rutinas con un tiempo de ejecución normalizado entre navegadores. No está pensado, y no va a estarlo, para hacer más allá de eso.
#37 Eso es un cancer.
#21 hace tiempo que se habla de dotar a WASM de un API para acceder al DOM y otros APIs del navegador, del mismo modo que existen proyecto para un layer IO para WASM que sea standard.
#21 El glue JS, cancer, decian que era temporal... que se cambiaria a algo nativo... En realidad, si tienes un canvas donde pintar... si, supongo que hay necesidad de generar HTML, pero... bueno, ya veremos.
#21 Lo se pero soñar es gratis
Lo siento pero queda JS para largo.
Por curiosidad, sabéis de algún otro lenguaje que tenga desestructuración, y spread?
#59 Mainstream? Lenguajes de masas? Python tiene.
Lenguajes menos conocidos? Hay a patadas con desestructuración y spread. Por ejemplo Haskell, OCaML, Erlang y Prolog.
#c-68" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3706314/order/68">#68 Gracias, no sabía lo de Python, y de los lenguajes funcionales menos.
Por cierto lo que cuentas en #125, tengo curiosidad por saber qué es lo que tanto te disgustó de C# , tuve que hacer un pequeño microservicio en C# sin tener ni idea y tenía la sensación que los problemas eran más culpa mía que del lenguaje, se veía algo feo pero robusto.
#68 #127 Python permite desestructurar iterables, pero no diccionarios al estilo de la desestructuración de objetos de JS.
Rust, por ejemplo, sí permite desestructurar tuplas y structs.
Para eso está Dart.
#3 Otro lenguaje hipster que acabara en el 0.3% en Tiobe... Apuestas?
Pd: espera que YA está en el 0.34%
#24 Dart es de Google, además es el lenguaje que va con Flutter. Ya me contarás en un par de años.
#35 en un par de años@raul_lapeira te dira que ya esta al 0.36%!
#35 Ni que el respaldo de Goolge fuera garantía de algo.
#3 vaya puta mierda pseudo javera
#71 Depende del mercado. C y ensamblador suena a sistemas empotrados. He trabajado en esos mercados. Pagan una mierda. Ahora han subido los salarios un poco, pero porque todos los programadores se iban a hacer webs en Javascript a ganar el doble. Yo soy uno de ellos.
JS es una casa de putas. Una casa de putas que paga bien.
El lenguaje para sistemas que no sea una casa de putas ya existe. Se llama Rust. Básicamente un C con sistema de tipos fuerte.
#80 Seguridad, AV, AntiRansomware,... y lo que viene fuerte, AntiCheat y demas, ensamblador x86 y x86-64, C y mucho internals de Windows y demas.
En cuanto a Rust, si, a ese me referia como algo nuevo sin ser casa de putas, aun asi no llega a lo que es C en algo Lean. Lo importante de Rust no son los tipos, no hay tanto problema, por mucho que se repita tanto, con los tipos, la verdad, no se lo que hace la gente para que eso sea tanto problema. Lo importante de Rust es el Borrowing, arma de doble filo, pero bueno...
#81 ¿Qué crees que es el borrow checker? https://en.wikipedia.org/wiki/Substructural_type_system Si mal no recuerdo, una variante de Affine Type Systems. Los sistemas de tipos pueden ser mucho más avanzados de lo que se muestra a la gente. Por ejemplo, Agda y Idris usan los sistemas de tipos para empezar a demostrar que los programas son correctos por construcción. Y cuando digo demostrar, digo demostrar matemáticamente con toda la rigurosidad.
#87 Hombre, si me quieres decir que el Borrowing es parte del tipado... vale, pero el borrowing en si puede hacerse incluso en sistemas detipado laxo, vamos, que es algo independiente de eso.
#75 Prefiero que me pisen los testiculos.
#c-82" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3706314/order/82">#82 hay que ser más abierto de mente. Los developers de un único lenguaje sois muy limitados. Lo importante es el algoritmo, el pensarlo, no el lenguaje con el que se expresa. A mí lo mismo me da Python, rust, C, java, C#, javascript, lo importante es lo que voy a implementar.
Abre tu mente hombre. Que además abre puertas.
#91 Juan Palomo...
Douglas Crockford: "2022, será el año de COBOL en el navegador"
#71 ganaba 24k anuales en 2006, ahora estoy en unos 300k anuales.
Si me consigues un salario similar en C yo me cambio
#73 300k no se, lo veo dificil. 80-120k si.
#74 pfff, pues deberías cambiar a javascript, paga mejor.
#74 si trabaja en usa si es posible
Es como el teclado qwerty , una basura porque incita a cometer errores de ortografía y allí sigue. Nadie se atreve a sacar una nueva disposición de teclas.
#79 Las disposiciones están ahí, pero nadie quiere aprender a usar el teclado otra vez.
#79
No sé quién te prohíbe poner el mapa de teclado que te salga del ojete.Es el año de PHP en el front-end
JavaScript es basura.
Pero también es verdad que aquí se criticaba a C, un lenguaje precioso, simple y sencillo que entra en cualquier autómata.
#16 C es dios. JS es basura, por favor, la comparacion...
#49 JS no es basura hombre.
C es como los Stark, rectos, del Norte, fieles a su código. Pero a la hora de la verdad, sin un puto duro. Cuando curraba en C y assembler compartía piso y no llegaba a fin de mes.
Javascript es la familia Lannister: follan entre hermanos, beben, montan orgías... No son los más rectos, pero están podridos de pasta. Y son más divertidos.
Gano en un mes de javascript lo que ganaba en el 2006 en un año de C.
Así que un respeto, que JS siempre paga sus deudas.
Gracias Javascript!
#66 No se cuanto ganabas o cuanto ganas, pero de hecho, es mas facil que ganes bien en trabajos donde solo se puede usar C, ensamblador y algo de C++, mas que en sitios de JS ( eso si, es probable que te paguen en USD ). Y luego esta lo de sufrir penitencias programando webs... bufff...
Y si, JS ES basura, lo es. Es una casa de putas.
Todabia no ha salido un lenguaje que no sea una casa de putas, no ha salido algo como C, aunque hay algun lenguaje viejo que se acerca y alguno nuevo que se acerca. Y digo C, no C++.
#66
JungSpinoza
A LannisterJavascript always pays his debts--
#66 La clave es "2006" y "ahora"
#16 Si y no. Siempre dicen que el C está muy cerca de la máquina y todo eso pero en cierto modo es mentira. Estaba cerca de la máquina cuando un long y un double eran una cosa distinta. Dependiendo de tu compilador y para que máquina compiles pueden ser cosas diferentes.
Pero vamos, que prefiero cualqueir lenguaje fuertemente tipado a JS.
mientras que no me toquen mi python que bastante me costó aprenderlo...
#8 Python no funciona como lenguaje de cliente. Son nichos distintos
#20 lo sé, pero molaría que los navegadores pudiesen interpretarlo!!
#26 Ojalá
#26 https://pyscript.net/
#56 eso solo transforma python a Javascript no? Yo me refiero a correr de forma nativa python en lugar de Javascript en un browser
#63 Web Assembly.
Con eso el cielo es el lìmite
#26 Dios no lo quiera, cambiar satanás por el diablo
#84 ¿Por qué Python sería el diablo? Peor sería que se pudiera ejecutar Java. Y lo peor es que webassembly lo permite.
Python no es un mal lenguaje. Tiene defectos. Pero no es un mal lenguaje.
#26 Sólo nos faltaba eso ya…
#26 No molaría nada. Cada lenguaje tiene su entorno. No existen balas de plata.
#26 https://brython.info/
#8 En Python llevais diez años actualizando de la version 2 a la 3 (en realidad 14 años para ser mas exactos). Antes de que la gente termine llegara la version 4 ...
#8 Si te ha costado Python, ni se te ocurra buscar qué es Rust
Y la alternativa que propone es E.
Esta es la web del lenguaje: http://erights.org/ No utiliza ni https y parece sacada de los 90 (falta un gif animado con un cartel de en construcción), con enlaces para probar el lenguaje online sin instalar nada como este: http://meme.b9.com/cdates.html?channel=erights (que no funciona). También podéis visitar la sección de la wiki Getting Started (http://wiki.erights.org/wiki/Getting_Started) que no se actualiza desde 2011.
#100 Y se visualiza perfectamente con el javascript bloqueado. Se visualiza también con navegadores desde la terminal que no admiten imágenes.
Aunque si, a día de hoy no usar https para una página estática exisitiendo Let's encrypt es algo delictivo. Pero vamos, que tampoco esgarantía de nada teniendo en cuenta que incluso antes de que exisitiera con un email podías comprar por 30€ un certificado en RapidSSL sin que hicieran ninguna pregunta y usarlo en sitios de phising.
#100 Sin duda argumentos de peso para evaluar la idoneidad de un lenguaje...
Lo mejor que podemos hacer hoy con Javascript es "jubilarlo".
Gracias.
Hoy? Y ya desde antaño.
Javascript es basura, ya en 2003 parecía que podríamos matarlo pero surgió AJAX y fue un balón de oxígeno para el lenguaje pero hoy deberíamos eliminarlo juntamente con PHP. Quizás quedarnos con Python o D o volver al BASIC de MSX.
#60 Es hora de desempolvar Perl.
#60 PHP ha mejorado mucho, mucho mas que JS.
#60 Nada mejor que el ASM para hacer las cosas como dios manda.