logo

midulive


Transcribed podcasts: 605
Time transcribed: 13d 3h 7m 36s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

El otro día Sodin, que es un famoso streamer en Twitch, estuvo probando de hacer un Hello World en React y se encontró con esta sorpresa.
Dice, oye, escuchen, he intentado hacer un Hola Mundo simple en React porque esto del Cruel React App instala 1459 paquetes.
Los desarrolladores de React, ¿estáis bien? ¿Estáis bien? La verdad es que necesitamos un abrazo. Yo necesito un abrazo. Yo siempre quiero abrazos.
Y aquí ha puesto el vídeo, ¿no? Y ha instalado 1459 paquetes en dos minutos. La verdad es que son un montón de paquetes, las cosas como son, ¿eh? Son muchos paquetes.
Pero bueno, también es verdad que Cruel React App ya no se utiliza, está bastante deprecado. Aquí viene el tema polémico y que quiero saber vuestra opinión, ¿vale?
¿Creéis que 1459 dependencias son muchas o pocas? Muchas, muchas, demasiadas. ¿Cuánto pesan? Depende de las que van a producción. A producción no van ni la mitad, ni el 10%.
Al final, pensad, porque son muchas, claro. También hay que tomar un poquito estas cositas un poquito con referencia. ¿Qué es lo que pasa?
Cuando vosotros instaláis Cruel React App, aparte de todo el tema de empaquetador, de bundle, de webpack y todo esto, obviamente, tenéis todo el tema del linter.
Bueno, aquí nos salen. No sé, a ver si las podemos ver. Si no, lo podemos instalar. Podemos intentar instalarlo para ver.
Instalar 114. Pero veis, aquí instalaba menos. Antes instalaba menos que ahora, ¿eh? Ahora instala más. Vamos a ver cuántas me instala a mí.
A ver. Vamos a ver cuántas me instala a mí. CD, DEP. Vamos a ver cuántas me instala. Sí, hombre, sí. Tú instala todo lo que sea.
Yo desayuno 1400 paquetes por compilación. Bueno. Que ni siquiera me deja, porque ya existe. A ver cuántas instala, ¿eh?
Instala hasta para hacer test, claro. Hay que tener en cuenta. El problema es que es verdad que parece que solo sea...
Y no lo digo por React. Lo digo para cualquier cosa de... Como si quieres ser Vue, con Vite, con Naxx, con lo que sea, ¿no?
Con un montón, ¿no? Hay que tener en cuenta que muchas veces no es que estés instalando las dependencias para hacer el holamundo,
sino que te está haciendo es como un entorno de desarrollo con el testing, con el inter, con Prettier.
Es verdad que son muchas. O sea, yo sí que creo y siento que son muchas, pero también es que no me parecen tantas
teniendo en cuenta todo lo que te estaba dando. O sea, es un entorno de desarrollo completo.
Por ejemplo, pensemos en Android Studio, por decir una, ¿no?
Si nosotros pensásemos cuántas dependencias tiene Android Studio internamente, lo que pasa es que no las tienes que instalar
o no las ves que las instalas. Pero cuando hacéis una instalación, ¿cuántas dependencias debe tener eso?
Internas. Aunque no las veáis, no pongas... Has instalado 1400. Tienen que ser miles. Pero miles.
Es que estoy convencido que son miles. Y al final es que cualquier framework que se precie le va a ocurrir esto.
Mira, aquí nos pone, ¿cuántas? 1463. Que son un montón, ¿eh? O sea, yo sinceramente me parece que son un montón.
Pero también es verdad porque, bueno, tenemos aquí testing library, testing library, React, React DOM, React scripts y tal.
Y además tendríamos todas las dependencias de desarrollo que no aparecen. Lo cual me sorprende.
Me sorprende que no salen las de desarrollo. Porque deben estar en React scripts a lo mejor.
Porque no las ves aquí, pero al final te ves... Por ejemplo, webpack, todo el tema de testing, todo este tipo de cosas, ¿no?
Android Studio ocupa como 10 gigas. Y no lo digo... Ojo, ¿eh? Porque alguien luego me dirá...
Ay, ¿me vas a comparar a Android Studio? No lo comparo. Y es que no lo digo con acritud.
Es que al final lo entiendo. Entiendo perfectamente que Android Studio tenga todas esas dependencias.
No tiene ningún tipo de acritud ni nada. Así es que me parece normal.
Cualquier SDK, cualquier framework, cualquier tipo de este tipo de cosas, al final es normal que tenga tantas dependencias.
Cuanto más herramientas te está dando. Si te da testing, si te está dando linter, si te está dando formatear,
hacer el empaquetado de la aplicación y todo esto, yo puedo entender que se te pueden ir a cientos de dependencias.
Pero el tema es que ha habido una polémica todavía que está relacionada con esta.
Y es el tema de Next Yes.
Os voy a hacer la segunda pregunta, ¿vale?
Mirad, Guillermo el otro día puso, cuando tú instalas Next, solo instalas 22 paquetes.
Y lo vamos a ir haciendo cada vez más delegado.
Especialmente cuando hagamos más trabajo en Rust.
Tú cuando haces una instalación de Next, solo instala 22 paquetes.
Que claro, ahora la gente me dirá, pues son pocas.
¿No? Ahora alguien dirá, joder, 22 paquetes son súper pocas.
Pero tiene trampa. Pero es una trampa que hace todo el mundo.
Y claro, tiene sentido, ¿no?
¿Por qué? Porque ya sabéis que lo que está haciendo Next...
A ver, es trampa, pero yo lo veo normal, ¿eh? Tiene sentido.
Lo que hace Next Yes, en realidad, es empaquetar las dependencias.
Compiled. Aquí lo tenemos. Compiled.
Claro, es un poco trampa.
Porque ¿qué es lo que hace Next?
Lo que hace Next es precompilar todas las dependencias.
Lo que hace es precompilarlas, ¿no?
Y meterlas directamente en el package.
Están precompiladas.
Y os voy a decir por qué tiene mucho sentido y por qué es una muy buena idea.
Es una muy buena idea porque así, básicamente...
Uno, te evitas inyección de código.
No puedes hacer un ataque de seguridad de que en una dependencia de una dependencia
te inyecten código malicioso porque ya vienen empaquetadas.
Y eso puede ser un beneficio.
Lo segundo, por un tema de rendimiento.
Al tenerlas empaquetadas ya directamente cuando instalas el paquete de Next,
no tienes que estar preguntando por cada paquete, sus dependencias y todo esto, ¿no?
O sea que para eso tiene sentido.
Pero es verdad que alguien puede decir, hombre, es trampa porque entonces esto lo podrían hacer todo el mundo.
Y lo cierto es que lo hacen mucho más frameworks de los que pensáis.
Cuando hablamos de SDKs y otros frameworks y tal, ¿cómo creéis que funcionan?
Muchas dependencias open source las tienen, pero ya las tienen empaquetadas.
Entonces, por eso no las vemos.
Entonces, creo que a veces hay una queja.
Creo que justificada para JavaScript de que cuando haces un paquete, por ejemplo, el React App,
que ya está desactualizado y que hay mejores versiones, ¿no?
Que ves que utiliza muchas dependencias y yo soy de los primeros que aboga
de que hay que intentar utilizar cuanta menos dependencia, mejor.
Pero también es verdad que es porque en otros sistemas en los que trabajamos,
como puede ser Python, como puede ser un montón de sitios,
hay muchas dependencias que al final lo que quedan son empaquetadas o oscurecidas
que no nos damos cuenta que pasan.
Pero claro, los 10 GB del Android SDK, ¿qué creéis que tienen ahí?
¿Que todo es código que alguien ha aplicado desde cero y que no tiene ningún tipo de dependencia?
Pues no, no funciona así.
Tienen un montón de dependencias totalmente de código abierto.
De hecho, es que hay millones de ejemplos.
Si vais a Nintendo Switch, por ejemplo, la Nintendo Switch.
Si no sabéis, Nintendo Switch está hecha de código abierto.
Tiene un montón de desarrollo de código abierto.
De hecho, utiliza React, Redux, utiliza un montón de bibliotecas.
No sabéis cuántas dependencias instalan ni nada.
Pero si veis a los créditos y a las licencias, vais a alucinar la de licencias que están mostrando
para todo lo que hacen.
Porque están utilizando, pero, miles y miles de dependencias de un montón de proyectos
de código abierto.
Entonces, es que es normal.
¿El sistema operativo de Switch está hecho con React?
No.
Hay partes de Switch que están hechas con React.
Por ejemplo, el Marketplace está hecho con React, de Nintendo Switch.
Las tres consolas tienen cosas hechas con React Native o con React.
Oye, ¿por qué ahora nos sale?
Nintendo Switch, React Redux.
Ah, mira.
Menos mal.
Menos mal que sale el Midudep este.
Menos mal que el Midudep este se guardó este enlace.
Aquí cuando lo anunciaron, en 2017, React is running inside Nintendo Switch.
Este es el secreto detrás del Nintendo eShop.
Pues eso.
Aquí explican cómo han hecho toda la UI.
Y podéis ver, y hay incluso juegos que también lo tienen.
Hay un montón de juegos que también utilizan React.
¿Veis?
Por ejemplo, esto, que es del Splatoon.
Está hecho con HTML, CSS y JavaScript.
Hay un montón de juegos de la Nintendo Switch que, si veis la UI, eso en realidad es todo web.
No es nativo.
Es web, 100%.
Lo cual está bastante chulo.
Con razón va mal de FPS.
Ya os digo yo que no.
No creo que ese sea el problema.
Ojalá.
Ojalá que sí.
Pero ya os digo yo que no.
Todo el Marketplace, todo, está hecho con React y con Redux.
Lo cual está brutal.
Pero también la PlayStation utiliza React Native.
La interfaz de la PlayStation 5 utiliza React Native.
Dice, partnership, React Native, Microsoft.
Es porque el sistema de PlayStation 5 se siente tan fluido.
¿Veis?
Dice, ¿el qué?
¿La interfaz de PlayStation 5 utiliza React Native?
Dice, sí.
Utiliza código C-Shark que ha contribuido con React Native Windows.
¿Ves?
O sea que ahí lo tenéis.
Ahí lo tenéis.
Y obviamente el de Microsoft, no os voy a contar ninguna historia, pero obviamente el de Microsoft tiene React Native también.
Que me hace gracia que luego dicen, no, que React no se utiliza.
Pues en las tres consolas de videojuegos tenéis React o React Native.
Alto Frankenstein.
No es Frankenstein.
Es que tiene todo el sentido del mundo.
La verdad es que, es que claro, está mal porque mucha gente como es hate.
Pero el tema es que tiene sentido.
Pensad que el desarrollar interfaces de usuario es muy complicado.
Por ejemplo, en un sistema de videojuegos.
Pero la mejor forma a día de hoy demostrada para crear interfaces de usuario está en el desarrollo web.
Porque HTML es súper declarativo, súper sencillo.
Los componentes de React, al final, la componentización y el hecho de que se parezca realmente a HTML, que no lo es, es súper sencillo.
Y yo lo entiendo porque el tema es que crear interfaces nativas es bastante complicado hacerlo con C y C++.
Pero no es eficiente.
Eso es un poco polémico.
Hay un montón de interfaces que no tenéis ni idea.
No tenéis ni idea que están hechas con React Native.
Como, por ejemplo, las interfaces de Call of Duty, Modern Warfare.
Hay un montón de interfaces que están hechas justamente con React Native.
Y no os habéis dado ni cuenta.
No os habéis dado ni cuenta.
No tenéis ni idea.
Entonces, no es eficiente.
Lo dices al capitán posteriori.
Porque ahora que lo sabes, vas a decir eso.
Y la eficiencia, muchas veces tú puedes pensar que es que tenga un rendimiento increíble.
Pero es que también estamos hablando del desarrollo, la mantenibilidad, la escalabilidad del sistema.
Y el tema es que si han elegido esto es justamente porque les permite eso.
Les permite también ser eficientes en cuanto al tiempo del desarrollo.
Y eso, pues, obviamente, muchas veces no lo entendemos.
Pero es que también es importante.
¿De qué te sirve?
Que la aplicación...
Es que para eso lo harían todo en ensamblador.
¿Entiendes?
Si fuese por un tema de voy a hacer que es increíblemente rápido y tal.
Pues es que lo harían ensamblador y entonces dejaríamos todas las discusiones.
Y todo tiene un coste de oportunidad.
Y la eficiencia también se tiene que ver en otro tipo de costes.
Costes de desarrollo, el tiempo, la complejidad, la mantenibilidad, escalabilidad y un montón de cosas.
Entonces no es tan fácil decir muchas veces que es lo más eficiente, ¿sabes?
Porque entonces haríamos todo con el ensamblador y ya está.
Lo perfecto es enemigo de lo bueno.
Efectivamente.
Entonces, ¿vosotros creéis que vale la pena perder el tiempo en crear la UI de Modern Warfare?
¿O creéis que lo importante es que se pongan con el juego?
Pues ahí lo tenéis.
Que se pongan con el juego y la UI que lo hagan con la forma más sencilla.
Porque si al final baja un frame, que a lo mejor no baja ninguno, no se va a dar cuenta ni el tazo, ¿sabes?
Ese es el tema.
Ese es el tema y esa es la importancia.