Debate Typescript y Javascript

B

Hace no demasiado en una entrevista encontré a alguien con quien podía entenderme y acabamos ambos despotricando sobre TS. Añade una capa falsa de robustez que sólo aporta verbosidad y trámites innecesarios. Lo que se necesita es a un programador competente y sólido, no barreras artificiales ni querer convertir a JS en algo que no es.

Wei-Yu

> tipado estático
> trámites innecesarios

gotta go fast

B

Y qué importa el tipado estático. Lo tienes tan fácil como una buena definición y un desarrollador despierto.

Wei-Yu

establecer contratos a base de objetos es lo normal; qué problema hay con garantizar que a nivel de primitivos estás garantizando que te viene "0" y no 0 sin ningún tipo de comprobación manual

encima que el typing es opcional, ni siquiera tienes por qué usarlo... que tampoco sé por qué no querrías usarlo en un sistema complejo porque se supone que trabajas sobre datos y no a la inversa

5
B

#240 ¿por qué ibas a hacer ninguna comprobación si en una arquitectura sólida sabes siempre qué va a llegar? La verbosidad que añade TS es la misma que añade una comprobación manual (ambas innecesarias).

Sea como sea, por qué no delegar esas comprobaciones a un buen proceso de testing en lugar de enguarrar el código con TS.

1 respuesta
Wei-Yu

verbosidad poner el tipo de los parametros y del retorno en la función xd no estás haciendo eso ya en los docstrings? o esa complejidad te la guardas tú en el coco porque sí?

es que en serio a poco que sea un sistema mínimamente grande no tienes forma de saber si el id de no sé qué proceso es este tipo o aquel, que la arquitectura es muy bonita si estás tú solo pero a poco que haya media docena de personas trabajando estás escribiendo contratos y funcionalidades que otros desarrolladores están usando y tienes que ser capaz de definir su comportamiento para que el que venga detrás sepa cómo se comporta

o metes docstrings o metes tipos y para qué usar un tipado ficticio en comentarios cuando puedes usar una herramienta que te lo verifica

es que encima del flujo normal quieres meterle una capa extra de verificaciones, edge y corner cases porque sí, cuando eso se lo puedes echar todo a la máquina para que lo haga ella

2
B

Existiendo documentación enguarrar el código es de: cutres, chapuzas, gitanos e incompetentes.

2 respuestas
eondev

#5

#5gido:

Sea como sea, por qué no delegar esas comprobaciones a un buen proceso de testing en lugar de enguarrar el código con TS.

:psyduck:
Ostia que lo dices enserio. Para qué delegar al compilador nada si te lo puedes pasar bien escribiendo tests xDDDDD

1 respuesta
Wei-Yu

#7 pero macho qué enguarrar el codigo xd

que toda esa complejidad que estás metiendo se la lleva la máquina de gratis a coste cero

ya no es sólo tener el dominio de tus datos claramente definido (que aún así te tocarán otras tantas validaciones a menos que el tipado que uses sea suficientemente expresivo), si no que te quitas las tareas paralelas al desarrollo... que si no garantizas SI o SI que esto tiene esta definición ni compila; sin tipos y con el type cohercion de js estás expuesto a errores de ejecución por todas partes

que si trabajas haciendo webs estáticas haz lo qur quieras pero en proyectos de una mínima complejidad estás añadiendo un sobrecoste cognitivo al desarrollo sólo porque no te gusta leer keywords o ves símbolos raros como : o -> aka "es demasiado verboso"

B

#8 testear no va sobre pasárselo bien sino sobre robustez y orden. Y sobre hacer las cosas bien, pero eso ya es otro asunto.

Leos

Si tan listo eres y todo lo haces tan bien para que haces tests? Es añadir mierda, si lo que haces no va a fallar

2
B

Por que es lo que hay que hacer. Como poner cemento entre los ladrillos.

1 respuesta
eondev

#12 No, porque con un buen sistema de tipos de ahorras tests innecesarios. Y siempre va a ser mucho mejor, es absurdo discutir esto xD

1 respuesta
B

#13 entiendo lo que dices pero creo que es una cuestión de orden que los checkeos se hagan en los tests y el código limpio y lo más canónico posible se haga en donde tiene que haber código.

De todos modos la expansión de TS parece seguir su curso así que me toca resignarme e ignorarlo hasta donde pueda.

1 1 respuesta
Ranthas

Reinventar la rueda usando FP y JS, puede que estemos ante un prodigio de la naturaleza

MisKo

hay que usar typos, hacer tests, guardar logs y hacer tests comprobando los logs

MTX_Anubis

#14 Eso será en proyectos pequeños. A medida que crecen los proyectos cualquier lenguaje dinámico es un mojón que solo da problemas y te lo digo siendo Ruby mi lenguaje favorito. Y si piensas que los tests lo cubren todo ya te puedes morir a escribir test o al final acabas haciendo un analizador statico de tipos que tardas menos. Cosa que es lo que hacen todas las empresas que llegan a este punto, como hizo twitter con ruby, el empujón a Mypy o vaya, como nació Typescript.

Y sinceramente, para llegar a ese punto (escribir x10 veces más de tests o un type checker) me voy a un lenguaje estático y me centro en testear el negocio que es lo que da valor realmente.

Aunque estoy de acuerdo contigo en que Typescript no aporta nada porque para eso me voy a un lenguaje stático directamente y santaspascuas.

4 1 respuesta
Wei-Yu

#17 Aunque estoy de acuerdo contigo en que Typescript no aporta nada porque para eso me voy a un lenguaje stático directamente y santaspascuas.

excepto si el código ya está escrito o se ve necesario js por algo

Zerokkk

Pasar de decir que una de las debilidades de JS es que no tiene tipado, a decir que TS no aporta una mierda, me parece el mayor ejercicio de gimnasia mental nunca visto.

JS tiene como ventaja que vale en todos lados, tiene mucha sugar syntax, y básicamente puedes hacer de todo con él siempre y cuando no hablemos de tareas computacionalmente muy costosas. Que no tenga tipos es sin duda un problemón en proyectos mínimamente grandes, o mantenidos por más de un par de personas. Typescript soluciona esto de una manera elegante sin sacrificar performance, y sin sacrificar estas características que hacen a JS un lenguaje interesante.

Es, precisamente, la mayor debilidad de todo el ecosistema de JS, parcheada de puta madre. De verdad, a algunos el hate os come xd.

1 1 respuesta
Zerokkk

#284 No soy un <1.4k al que puedas ir mandando callar como te viene en gana. Si alguien va a decir tonterías, voy a contestar te guste o no. Y no estoy diciendo ninguna fanboyada; aquí nadie dice que el software dev se reduzca a JS. Yo también programo en otros lenguajes. Lo que me parece absurdo es el hate que algunos le tenéis al pobre lenguaje sólo porque su popularidad, usabilidad y calidad de código se han disparado, y ahora es un lenguaje medio serio cuando antes era una caca. Punto.

Que si quieres te programo cualquier mierda en otros 3 lenguajes, pero para el 90% de lo que vayas a querer hacer, no hace falta más. Se le llama ser un poco pragmático y no dárselas de listillo hipster de los cojones.

1 respuesta
MTX_Anubis

#19 Me parece que a lo mejor deberías hacer algo más de gimnasia con tu cerebro.

Decir que TS no aporta una mierda es porque precisamente TS no aporta una mierda más que solucionar un problema de un lenguaje que, vaya, si utilizas otros lenguajes tipados ya está solucionado. Vamos que aporte 0 al mundo de los lenguajes de programación. Como swift que nadie sabe aún qué uso puede tener.

Pero vamos que me hace gracia que hables de fanboyadas. Tú, que hace años venía diciendo que Java era lo mejor de lo mejor porque... solo conocía java.
Luego que si le iba teniendo tirria a java y JS es lo mejor de lo mejor porque... cambió de java a js y se dió cuenta de que java es un cáncer.
Luego que TS es lo mejor porque... vaya tocó TS y se dió cuenta de que JS a nada que crezca el proyecto es un ñordo de dimensiones épicas.
Y ahora se ha dado cuenta de que hay más mundo más allá de esos 3 lenguajes y quiere aprender más cosas (y eso está bien).

Lo mejor es que después de cada uno de esos puntos, al final acabaste dando la razón a todo lo que te decían y tu estabas en contra mientras dabas la chapa defendiendo tu postura.

1 1 respuesta
Zerokkk

#21 Y tú quizá deberías aprender a entender lo que se dice, en lugar de dejar que tus preconcepciones sobre alguien contaminen tu interpretación (e incluso tus memorias). Yo cuando defendía JS en el pasado, añadía que era siempre y cuando usases estándares novedosos (ES6 en adelante) y no el asqueroso vanilla JS con el que hacíamos webs hace más de un lustro, además de acompañado por TS.

La ventaja que el ecosistema JS siempre tendrá sobre los demás, es que es lo que se usa en web, que nos guste o no, también afecta al final al entorno mobile y hasta a nivel de servidor. Hasta hay gente haciendo data science con JS, lo que oyes (yo no lo usaría para este propósito). Esto hace que el lenguaje, si lo parcheas de modo que coja fuerza, sea una herramienta tan legítima de usar como cualquier otra. No hay más.

Y a eso me dedico yo con respuestas como estas: a hacer ver que ir por ahí quejándose de otros lenguajes legítimos es tarea de hipters que se aburren mucho. No vas a leer en mis posts que JS sea el epítome en servidor, en mobile apps ni data science. Ni que sea lo más performant que ha habido, ni tampoco que tenga la mejor sintaxis. Lo que me verás es decir que, hecho correctamente y con herramientas como TS, se transforma en un lenguaje maduro, razonablemente potente, y que está genial para la mayoría de cosas.

¿Niega esto que lenguajes como C#, Java o Go sean mejores para backends algo serios y grandes? ¿O que Python, R, Matlab y Octave sean mejores para cualquier tarea relacionada con data science? ¿O que haya que cargarse todo el panorama SQL y usar sólo no-sql y JSON a dar por culo? ¿O que C, Rust y C++ sigan siendo lo mejor para software de alto rendimiento y sistemas embedidos? No, y si entiendes eso, es que entonces tienes un problema de comprensión lectora.

2 respuestas
Lecherito

Y sin meme, Javascript sigue siendo un cáncer en fase 4,ahora que si le metes algo de quimioterapia pues se queda en typescript que sería un cancer en fase 2.

Fyn4r

#22 A ver, que hasta he visto a gente programar Arduinos en JS, eso no quita que sean unos monos xD

1 respuesta
HeXaN

En España el éxito de JS se debe a algo muy sencillo: por el precio de un "programador" te llevas un tío que te hace back, front y mobile. Lo explotas, le pagas 1200€ y a facturar.

6 3 respuestas
Zerokkk

#24 Pues yo eso sí que lo veo un poco absurdo xDD. En sistemas embedidos, a menos que vayan muy bien de recursos, no se me ocurriría usar JS. Para eso ya está Rust, que lo poco que he visto de él pinta bastante cojonudo para ese tipo de problemas y no es tan coñazo como C de aprender.

#25 Y fuera de España hay más éxito en el lenguaje aún. Yo cuando trabajaba con una empresa de Amsterdam hacía full-stack (sin mobile dev) y por 5-6h al día dependiendo del día me sacaba 3k limpios al mes, así que eso de que explotan... xDD. En España quizá, pero es que aquí la cultura de trabajo que hay es una mierda.

Tengo un colega que curra en el stack también, en USA, y por nada de curro (y en remoto, como yo) el tío se está sacando una pasta que nos hunde al 95% de este foro en billetes.

MTX_Anubis

#22 Yo lo que he dicho es que TS aporta 0, el resto es paja tuya. Cuando digo que TS aporta 0 no me refiero que no aporta nada a la gente que lo usa, me refiero que no aporta nada al mundo IT. Pero como con TS ocurre con los 200 lenguajes que crean nuevos al año y pasan sin pena ni gloria.

De todas formas creo que piensas que solo odio a JS y no es así, a mi me parecen una mierda todos los lenguajes de programación en los que he programado, que no son pocos. Sólo que unos lenguajes son más mierdas que otros y desde luego algunos tienen cosas interesantes y otros pues, eso, nada que no estuviera inventado.

1 respuesta
eXtreM3

#25 lo que más le gusta a los clientes es que le metas unas animaciones de lottie en mitad del flujo, eso les flipa, eso mola mucho, esa puta mierda infla el precio de los proyectos por sí sola.

Aunque tengas un proceso que en el back dure 0,001 segundos, le metes un pause de 2 segundos para clavar una animación y ESO PARTE LA PANA.

Animaciones, animaciones everywhere.

B

Pago por ver el código que vomitan los que critican JS.

MP si queréis unos euros.

1
B

https://github.com/microsoft/vscode/issues

xDDDDDDD

1 1 respuesta

Usuarios habituales