Hace 1 mes | Por geralt_ a devclass.com
Publicado hace 1 mes por geralt_ a devclass.com

"Lo mejor que podemos hacer hoy a JS es retirarlo. Hace 20 años, yo era uno de los pocos defensores de JS. 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 JS, 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 JS".

Comentarios

r

#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"

sillycon

#12 Veo lo tuyo y subo a No han matado el Java

rogerius

#40 Los hippies pasamos de todo. No nos cargues con los pecados de otros.

apetor

#65 Ya sabes a quienes me refiero.

abnog

#40 No por dios, otra máquina virtual más no, por favor.

apetor

#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 ?

abnog
editado

#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í ).

C

#40 un nuevo standard

f

#61 JAMAS!!!

Cuñado

#61 En mis ya muchos años dentro del sector he aprendido que cuanto más pontifica un programador, menos sabe.

n

#27 por Dios, escuchen a este hombre.

Lisergico

#27 Exacto. Y se dice poco.

c

#51 Digamos que no hay otra alternativa a la altura para su nicho.

kurroman

#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

h

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.

MacMagic

#6 Cómo Menéame

par

#6 Pero eso se puede saber, no?

knzio

#17 no siempre es sencillo de encontrar

par
editado

#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?

c
editado

#6 Porque los hay.
Empiezas a corregir el primero, hasta que se acabe el último.

El problema es ya de librerías de terceros.

B

#6 Por eso se usa TypeScript.

m

#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

Pelafustan
editado

#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

c

#4 Concuerdo. Esa carrera para que los navegadores se lo coman todo es muy contraproducente

apetor

#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.

c

#44 Por qué los formatos de texto son caca?
HTML es caca?
JSON es caca?
Yaml es caca?

apetor

#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.

c

#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

Veelicus

#4 no cargarnia ni una, y si ademas añades los temas de accesibilidad entonces se cierra internet

C

#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.

F

#4 Si el problema de JS no son los errores. Eso es lo de menos!

j

#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.

c

#10 ¿?

A qué te refieres exactamente?

ErMijita

#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...

Supercinexin

#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.

S

#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.

JungSpinoza
editado

#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 ...

f
editado

m

#2 y mandas al paro a tropecientas mil personas. genial idea.

Nova6K0

Esto sin hablar de la cantidad de scripts maliciosos que hay, gracias a él.

Saludos

Supercinexin

#25 Muy guapo ese "hiendo".

PacoJones

#31 #32 ay, mil perdones, me acabo de dar cuenta, sirve la excusa del autocorrector?

f
editado

#25 yendo* en lugar de hiendo.
PHP más JavaScript, huye, sal corriendo y no vuelvas a ese proyecto

S
editado

#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.

SaulBadman

#25 Al menos a PHP le han sacado algo de brillo en sus últimas versiones

sauron34_1

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.

p

#29 y como vamos a saber si un numero es par o impar???!!!!

tommyx

#38 dividiendo por dos, si el resto es 0 es par, sino, impar

e
editado

Y el cabron lo dice ahora.....

D
editado

¿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. 

ur_quan_master

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)

S

#36 Vas a tener que azotar a muchos veteranos. Transpilación no es más que un nombre nuevo para compilación.

pedrobz

#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.

Cuñado
editado

#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.

Tarkedo

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.

n
editado

#50 Node es una puta perversión… Espero que el inventor arda en el infierno.

JungSpinoza

#89 #50 El inventor ya dijo que renunciaba a el y ahora esta creando Deno

deno.land

c

#26 Para que?

m
editado

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.

honbu

Esperemos que webassembly progrese y haga honor a lo de javascript killer

r

#11 JS no lo tumba ni cristo. Ojala

JungSpinoza
editado

#11 #21 #15 JS va a durar mas que Cobol ... los dev de JS tienen el trabajo mas asegurado que los funcionarios

armadilloamarillo
editado

#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

B

#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.

apetor

#37 Eso es un cancer.

tamat

#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.

apetor

#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.

honbu

#21 Lo se pero soñar es gratis

Dark_Wise

Lo siento pero queda JS para largo.
Por curiosidad, sabéis de algún otro lenguaje que tenga desestructuración, y spread?

S

#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.

Dark_Wise
editado

#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 #c-125" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3706314/order/125">#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.

Cuñado
editado

#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.

x

Para eso está Dart.

x

#24 Dart es de Google, además es el lenguaje que va con Flutter. Ya me contarás en un par de años.

JungSpinoza

#35 en un par de años@raul_lapeira te dira que ya esta al 0.36%!

F

#35 Ni que el respaldo de Goolge fuera garantía de algo.

c

#3 vaya puta mierda pseudo javera

S

#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.

apetor
editado

#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...

S

#81 ¿Qué crees que es el borrow checker? en.wikipedia.org 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.

apetor
editado

#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.

apetor

#75 Prefiero que me pisen los testiculos.

f

#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.

apetor

#91 Juan Palomo...

M

Douglas Crockford: "2022, será el año de COBOL en el navegador"

f

#71 ganaba 24k anuales en 2006, ahora estoy en unos 300k anuales.
Si me consigues un salario similar en C yo me cambio

apetor

#73 300k no se, lo veo dificil. 80-120k si.

f

#74 pfff, pues deberías cambiar a javascript, paga mejor.

#74 si trabaja en usa si es posible

C

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.

h
editado

#79 No sé quién te prohíbe poner el mapa de teclado que te salga del ojete.

editado:
nah, tiene que ser un troleo...

Arlequin

Es el año de PHP en el front-end

r

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.

apetor

#16 C es dios. JS es basura, por favor, la comparacion...

apetor
editado

#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++.

JungSpinoza