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 ...
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".
#6 Cómo Menéame
#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.
#5 los habria igual en cualquier otro lenguaje universal para todos los navegadores
#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.
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.
#3 Otro lenguaje hipster que acabara en el 0.3% en Tiobe... Apuestas?
Pd: espera que YA está en el 0.34%
#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!
Explicación: https://xkcd.com/927/
Lo que hay que eliminar son las aplicaciones en Electron. Vienen del infierno.
#25 Muy guapo ese "hiendo".
#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.
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.
#29 y como vamos a saber si un numero es par o impar???!!!!
#8 Python no funciona como lenguaje de cliente. Son nichos distintos
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.
#6 Por eso se usa TypeScript.
#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.
Esto sin hablar de la cantidad de scripts maliciosos que hay, gracias a él.
Saludos
#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.
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.
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
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.
Y el cabron lo dice ahora.....
#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
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)
¿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.
#11 JS no lo tumba ni cristo. Ojala
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.
#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)
#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.
#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.
#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 ...
#11 #21 #15 JS va a durar mas que Cobol ... los dev de JS tienen el trabajo mas asegurado que los funcionarios
#31 #32 ay, mil perdones, me acabo de dar cuenta, sirve la excusa del autocorrector?
#4 no cargarnia ni una, y si ademas añades los temas de accesibilidad entonces se cierra internet
#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.
#12 Veo lo tuyo y subo a No han matado el Java
#20 lo sé, pero molaría que los navegadores pudiesen interpretarlo!!
#26 Para que?
#66
JungSpinoza
A LannisterJavascript always pays his debts--
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.
#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"
Esperemos que webassembly progrese y haga honor a lo de javascript killer
Lo siento pero queda JS para largo.
Por curiosidad, sabéis de algún otro lenguaje que tenga desestructuración, y spread?
#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.
#40 No por dios, otra máquina virtual más no, por favor.
#89 #50 El inventor ya dijo que renunciaba a el y ahora esta creando Deno
https://deno.land/
Para eso está Dart.
#40 Los hippies pasamos de todo. No nos cargues con los pecados de otros.
#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 ...
#111 Han mejorado los dos una barbaridad. De hecho, creo que hay cierta tendencia en los lenguajes a complicarse (ej. ceder a la presión y soportar orientación a objetos) converger. Miras un PHP y un Typescript y son sospechosamente parecidos.
#35 en un par de años@raul_lapeira te dira que ya esta al 0.36%!
#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í ).
#149 En una implementación con registros, cuando la cpu virtual tiene que realizar una operación, mete los operandos en unos 'registros' (variables en memoria) y ejecuta la operación dejando el resultado en otro registro. En una de pila, hay una pila en memoria donde va insertando los operandos y sus operaciones, luego los va sacando de la pila dejando en la misma el resultado.
La diferencia fundamental reside en que como la inmensa mayoría de procesadores físicos usan registros dentro de los mismos para realizar las operaciones, una VM en base a registros usará los físicos de dicho procesador, haciendo que sea mucho más eficiente.
La implementación en base a pila es más simple de implementar (uno de los motivos por los que la usa Java), pero siempre me pareció un poco absurdo porque luego tienes que hacer otras partes de la VM más complejas.
Espero haberme explicado mínimamente bien.
#163 Vale, entiendo la idea. Sí, recuerdo algo de los registros de lo poco que aprendí de ensamblador en mi suspendida asignatura Intro a Computadores.
Soy traductor no ingeniero informático
#6 Porque los hay.
Empiezas a corregir el primero, hasta que se acabe el último.
El problema es ya de librerías de terceros.
#16 C es dios. JS es basura, por favor, la comparacion...
#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.
#113 Viejuno!
Ahora pasa lo mismo, los chavales de 12 años de entonces siguen entregados a hacer diseños horribles, por ejemplo la web de Renfe.
#2 y mandas al paro a tropecientas mil personas. genial idea.
#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
#60 Es hora de desempolvar Perl.
#61 En mis ya muchos años dentro del sector he aprendido que cuanto más pontifica un programador, menos sabe.
#25 yendo* en lugar de hiendo.
PHP más JavaScript, huye, sal corriendo y no vuelvas a ese proyecto
#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.
#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.
#75 Prefiero que me pisen los testiculos.
#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.
#26 Dios no lo quiera, cambiar satanás por el diablo
#119 Y se visualiza perfectamente con el javascript bloqueado. Se visualiza también con navegadores desde la terminal que no admiten imágenes.
Normal, es HTML. También ocurriría con un poco más de CSS para mejorarlo estéticamente, por ejemplo con w3m puedes visitar meneame o google en modo texto sin grandes problemas. Pero vamos, que no has entendido lo que he querido decir: la web oficial del lenguaje que propone el tipo no se ha actualizado desde hace mucho, mucho tiempo. Te pongo otro ejemplo: la documentación contiene un enlace a un bugtracker. El bug notificado más actual que se ha arreglado fue notificado en 2007, hace 15 años. Antes de arreglar el mundo, debería empezar limpiando su habitación.
#61 JAMAS!!!
#26 Sólo nos faltaba eso ya…
#50 Node es una puta perversión… Espero que el inventor arda en el infierno.
#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
#24 Dart es de Google, además es el lenguaje que va con Flutter. Ya me contarás en un par de años.
#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 ?
#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
#c-127" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3706314/order/127">#127 Yo no hice ese comentario #125, pero mi experiencia con C# es que aparentemente el problema es culpa tuya, hasta que te paras a comparar con otros lenguajes de programación y frameworks, y te das cuenta de que los otros han pulido esos problemas y tratan de guiarte y sugerirte buenas soluciones. C#, ASP.net y bibliotecas afines no hacen nada de eso, en lugar te guían por malas prácticas, y después culpan al programador cuando se va en la dirección incorrecta. Por ejemplo, hasta hace no mucho, les fascinaba guiar al desarrollador hacia el patrón repositorio https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application sin explicar ninguna de las ramificaciones ni complejidad que eso incluye. Y luego tienes cosas como que la SQL Server Express dicen que funciona con 1GB de RAM, pero no te dicen que se cuelga varios días seguidos si le pones 1GB de RAM. https://docs.microsoft.com/en-us/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server-2019?view=sql-server-ver16.
Y por último, todo funciona con el generador de configuración de VSStudio para Azure, y falla para todas las demás situaciones, promoviendo aún más lock in "funciona para Azure y no para AWS, por lo tanto es AWS que es defectuoso, firma este contrato para comprar otros 6 meses de Azure".
Por supuesto, todos esos problemas y lock-in son excelentes para tener programadores que defenderán C# a capa y espada (porque es lo único que saben y pueden hacer), y esos programadores pedirán cursos y herramientas que sólo Microsoft vende. Lock-in puro y duro.
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
#17 no siempre es sencillo de encontrar
#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.
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.
#60 PHP ha mejorado mucho, mucho mas que JS.
#63 Web Assembly.
Con eso el cielo es el lìmite
#114 Tengo la misma sensación
#152 efectivamente, saber donde falla no implica saber de dónde viene el problema
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.
#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.
Es el año de PHP en el front-end
#27 por Dios, escuchen a este hombre.
#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...
Los sysadmin miramos y sonreímos desde nuestro bash.
#3 vaya puta mierda pseudo javera
#27 Exacto. Y se dice poco.
#66 La clave es "2006" y "ahora"