Chrome 115. Douglas Crockford está últimamente en boca de todo.
Si también odia CSS, este hombre odia a todo el mundo.
Google les está trackeando y es anunciando la muerte de las cookies.
Espero que tremendamente bello o bella, que estés fantástico, que han pasado la semana con buen pie,
que estemos llenos de energía, contentos, felices.
Hoy vamos a estar con las noticias de JavaScript.
Tenemos salseo, novedades de una nueva versión de Chrome que viene, novedades importantes, peligrosas, que tenéis que conocer.
Vamos a ver una lista de empresas en España que ofrecen trabajo en remoto, por si os sirve.
Vamos a ver un poquito del curso de Node.js con certificado opcional.
Nuevas unidades para el viewport con CSS, avance de features muy interesantes que van a llegar a JavaScript y que tienes que conocer, muy chulas.
Vamos con el curso. Este jueves 20 de julio vamos a arrancar un curso de Node.js desde cero.
Y la idea es que todos los jueves tengamos una clase nueva.
No sé exactamente cuánto va a durar, ¿por qué? Porque la vamos a hacer en directo.
Según el directo, según lo que preguntéis o dejéis de preguntar, pues tardaremos más, tardaremos menos y todo esto.
¿Qué vamos a hacer? Pues aquí tenéis un poquito los proyectos que vamos a crear.
Una API Res, una línea de comandos, servidor web, aplicación web en tiempo real con WebSockets,
conexión a base de datos MySQL y MongoDB, vamos a ver ORMs también, aplicación de Scrapping Web.
Estos van a ser los proyectos que vamos a hacer.
Para ver el contenido, le dais aquí a contenido y aquí he puesto todo el contenido.
A ver, igual hay cosas que hacemos un poquito más de algo, o sea, menos no creo, pero igual añadimos algo si veo que hay interés o cositas así, ¿vale?
Seguramente, ya os digo que este jueves, vamos a ver la introducción a Node.js y el sistema de módulos de Node.
Luego, la línea de comandos, lo veremos más adelante, crear un servidor web con Node.js, crear tu primera API, base de datos con Node.js,
pruebas unitarias con Node, WebSockets para crear una aplicación de tiempo real, sesión y autenticación, ¿vale?
Y seguridad en Node.js y Node.js con TypeScript y React con Node.js.
La de React con Node.js será el final porque es bastante interesante poder utilizar React para crear aplicaciones de Node, lo cual está bastante chulo.
El curso es 100% gratis, lo vamos a hacer aquí todos los jueves a las 6 de la tarde, hora peninsular española, hay un certificado opcional.
Nadie está obligado, igual no te interesa y no pasa nada.
149 euros. ¿Por qué 149 euros?
He estado pensando, he estado mirando, he estado calculando tiempo, he estado mirando lo que me gustaría a mí hacer.
¿Y qué es lo que quiero hacer? Lo que quiero es revisarme los ejercicios y los proyectos de la gente que va a hacer el certificado y poderles dar feedback.
Eso es tiempo manual y haciendo cálculos y por eso es un número limitado, había 20 plazas limitadas.
¿Qué es lo que quiero hacer? Pues quiero mirármelo con calma, ¿vale?
Voy a mirármelo con calma, voy a probarlo y vamos a ver si sale bien, si vale la pena y tal.
La gente que se apunte, pues que lo sepa, es la primera vez que lo hago, pero lo quiero hacer con el máximo cariño.
Para hacerlo con el máximo cariño le tengo que dedicar tiempo.
Si le tengo que dedicar tiempo, tengo que hacer que me salga cuenta a mí, pero sobre todo que entregue el valor que la gente espera.
Y la calidad que quiero es mandarle a la gente que haga ejercicios y proyectos y poder revisarlos.
Para cómo lo quiero hacer, no lo puedo regalar.
Es la primera vez que lo hacemos, vamos a ver cómo sale y a partir de ahí, pues le daremos cañita.
Y seguramente lo que haremos más adelante es volver a abrirlos.
Pero ahora, para este curso, vamos a abrir 20 plazas y entonces cada dos semanas revisaremos,
vamos a tener llamada grupal, vamos a tener feedback sobre los proyectos.
Hay que entregar los proyectos y ejercicios para conseguir el certificado, ¿vale?
El certificado se podrá poner en LinkedIn.
Vais a tener un QR para validar el certificado.
El QR aparecerá aquí para que, obviamente, no sea un certificado que cualquier persona lo pone y ya está.
Va a estar validado con un QR que eso irá a una URL de aprendenow.dev donde aparecerá directamente esto, ¿vale?
Vamos a empezar fácil.
Driver.js es una biblioteca que te permite crear tours de productos, que esto muchas veces es bastante complicado.
El hecho de que tú entras a una página web y no sabes ni por dónde se tiene que empezar, que hay que hacerle clic y todo esto.
Por ejemplo, un tour animado, le das y fíjate que hace esto, está súper chula.
Te dice, mira, aquí puedes darle no sé qué, next.
Entonces se mueve, next, next, done, ¿vale?
O no animado, esto sería sin animar.
O un tour asíncrono, donde puedes traer cosas, mira, un nuevo elemento, no sé qué.
Me encanta porque esto muchas veces es bastante complicado de hacer y lo hace súper bien.
Así que si necesitáis hacer uno de estos tours, pues ya sabes, con driver.js lo puedes hacer.
No tiene dependencias.
Está escrito con TypeScript, por lo que tiene autocompletado.
Está hecho todo con vanilla JavaScript, por lo tanto funciona cualquier stack.
O sea, no está hecho con React, que normalmente es un poco rollo que todo está hecho con React.
Pues esto funciona con cualquiera, con React, con Svelte, con Vue, con lo que quieras.
Es soporte para casi todos los navegadores, bueno, casi todos los navegadores, no.
Para todos los navegadores Major, funciona en móvil y además lo puedes personalizar bastante.
Es uno de esos recursos, bibliotecas de JavaScript que dices, chapo, tiene mis 10s.
Tiene sello de calidad Midu, de verdad.
Los Major son, mira, justamente yo tengo una configuración.
Mira, voy a enseñar un truco, ya que está.
Me encanta cuando hago cosas que no tengo planeadas y te enseño un truco.
Os podría enseñar dos trucos, lo que pasa es que hace tiempo que no utilizo Google Analytics.
Pero mira, hay un truco aquí, por ejemplo, si ponemos aquí Local Storage.
Mucha gente utiliza Can I Use directamente.
Si nos vamos aquí al modo no ventana incógnito y nos vamos al Can I Use.
Mucha gente lo utiliza así, que no está mal, pero es un poco rollo porque tenéis aquí un montón de navegadores.
Demasiada información.
Lo podéis filtrar un poco y al menos os aparece así que ya está bastante mejor.
Esto es totalmente configurable, que le podéis dar aquí a esta ruedecita.
Y esto lo podéis configurar, por ejemplo, para decirle, mira, Browser Show.
Le podéis dar aquí, Add New Set, y os hacéis el vuestro propio.
Y decís, mira, el Chrome for Android lo elimina.
Safari en iOS, bueno, Safari en iOS debería estar.
Este fuera, este fuera, este fuera.
Sabes, lo que no os interese, lo podéis quitar.
Y además, luego veis que salen demasiadas versiones.
Esto podéis decir, quiero que me muestres las últimas versiones mayo.
Y le dices que te muestre las dos últimas mayo.
Aquí tendrías al menos las últimas versiones mayo.
No sé por qué, porque solo sale...
Ah, porque se pueden quitar también las del futuro, si no me equivoco.
A ver, Save.
Ves que pone, Algo Show Current and Upcoming.
También le puedes quitar para que no aparezcan las del futuro y solo aparezcan las actuales.
Y entonces con esto, me siguen apareciendo aquí todos.
Ahora.
Y entonces solo os aparecerán los que vosotros habráis puesto.
Queda mucho mejor.
Y así podéis poner lo que queráis que vosotros soportéis.
Hay un truco todavía mejor, que es este de Usage Data.
Esto es un trucazo que muy poca gente conoce.
Si utilizáis Google Analytics, esto es brutal.
Y es que podéis darle aquí a Open Importer.
Podéis importar o Google Analytics o Simple Analytics.
Le dais aquí y aquí iniciar sesión con vuestra cuenta de Google Analytics.
Importará vuestras analíticas y solo aparecerán aquí los navegadores de los que recibís tráfico.
Y además lo podéis poner aquí con Usage Relative y os hará esta gráfica con vuestros usuarios.
O sea, y eso es espectacular.
Así que esa sería la forma correcta de utilizar CanEuse.
Porque con Usage Relative, por ejemplo, pues a lo mejor desaparecerán estos navegadores porque tenéis cero.
Pero Safari o Nios os aparecerá tan grande como tengáis usuarios de ese navegador.
Eso está increíble.
Trucazo.
Las novedades de Chrome 115.
Trae dos novedades que vienen a revolucionar para bien y para mal, ya verás.
Cómo nos comunicamos con la web.
Primero, una cosa súper positiva sobre el scroll, que va a ser tremenda.
Y otra, sobre las cookies, que ojo, cuidado.
Hay dos novedades súper importantes.
La primera, yo creo que la más importante en cuanto a qué impacto va a tener el desarrollo web.
Scroll Driven Animations.
Las animaciones del scroll con CSS.
¿Por qué?
Porque esto trata de que solo con unas líneas de CSS, mira, fíjate, con estas líneas de CSS, vas a poder animar el scroll y elementos del scroll.
Por ejemplo, cómo van apareciendo imágenes conforme vas scrolleando.
Mira, de hecho, aquí tienes este ejemplo.
¿Ves?
Tú haces scroll y van apareciendo las imágenes.
Esto va a ser increíble.
O sea, nos vamos a hartar de jugar con esto.
Esto va a ser una espectacularidad.
Aquí hay un artículo de MDN que está muy chulo, que habla de estas animaciones con el scroll y que también tiene unas demos y esto.
Y aquí tienes una de las más sencillas de utilizar un keyframes, una animación normal para escalar y lo que puedes hacer es decir Animation Timeline con el scroll.
Entonces, conforme se va acercando el scroll, lo que vas haciendo es que cada vez se va haciendo más grande.
Claro, aquí no me aparece.
Esto debería ser una barra de progreso, pero como estoy con Chrome 114 todavía no aparece.
Lo interesante de esto es que está hecho todo con CSS, cero JavaScript.
Por lo tanto, el rendimiento que tiene esto es brutal.
Canary, mira, para que veáis que esto sí que funciona.
Para que veáis que esto sí que funciona, en el Canary sí que debería tener esto.
Esto está hecho con CSS.
De hecho, tenéis el CSS arriba.
¿Veis?
Eso, todo CSS.
Es espectacular.
Mira, aquí otra.
¿Ves?
Esto se está moviendo conforme va haciendo scroll.
Mira aquí.
Esto está cambiando.
Se está moviendo horizontalmente con el scroll.
Es que se van a poder hacer una de cosas muy locas.
Mira, esto también con el scroll.
Mira, moviendo esto con el scroll.
¿Qué es lo bueno que tiene esto?
Pues que tiene un rendimiento que es brutal.
De hecho, hay este artículo de Yuriko Hirota que está muy, muy bien.
Que lo recomiendo un montón.
Habla de la diferencia del rendimiento entre hacerlo con CSS o hacerlo con JavaScript.
Había, durante mucho tiempo, ha habido un montón de bibliotecas que se podía hacer esto.
Lo vamos a ver para que os deis cuenta de la diferencia.
A ver si no me peta nada.
Este sería el clásico con JavaScript, ¿no?
Si añades, ves, tú haces scroll y ves, se actualiza aquí.
Pero tú puedes añadir que, claro, mientras se está ejecutando JavaScript, ¿ves que va a trompicones?
¿Veis que va a trompicones?
No tiene tiempo porque el thread principal está ocupado.
En cambio, fijaos en este con CSS.
Añades JavaScript que se está evaluando y fíjate lo bien que va.
O sea, ¿por qué?
Porque está en otro thread totalmente separado.
Y esto es totalmente nativo.
Por más JavaScript que se está ejecutando, ves que pone heavy JavaScript in progress.
Funciona como un tiempo real.
Yo creo que la web está pegando un paso adelante entre el tema este de las animaciones que os enseñé hace poco.
Entre las View Transitions API.
Esto, esto.
¿Veis esa transición?
Eso está hecho con CSS solo.
Bueno, y con un poquito de JavaScript.
Pero que CSS.
Y esto es que va a ser increíble la de cosas que vamos a poder hacer en la web.
De verdad.
Mira, aquí podéis ver otro ejemplo más de diseños que se pueden hacer.
¿Ves que van apareciendo cosas conforme vas haciendo scroll?
Bueno, pues la próxima versión, la 115, por fin vamos a tener esto.
Viene con otra novedad bastante importante que viene a cambiar el status quo de cómo hemos trabajado en la web durante muchísimo tiempo.
Estaría como dividido en dos.
Y te lo voy a explicar porque esto te puede volar un poco la cabeza.
Se llama Fence Frames.
¿Vale?
Esta es uno.
Viene a ser como un iframe, pero más privado.
Y el Topics API.
Esto es lo que va a estar es anunciando la muerte de las cookies.
Vamos a hablar primero de los Fence Frames.
Desde hace tiempo, Google está trabajando en una iniciativa que se llama Privacy Sandbox.
Que es un conjunto de tecnologías como para asegurarse que las páginas web no dejan al descubierto tanta información del usuario.
Y uno de los grandes problemas que hemos tenido históricamente han sido los iframes.
Por si no lo sabíais, durante mucho tiempo lo que hacen un montón de empresas es que tú cuando cargas una página como por ejemplo esta.
Lo que hacen muchas empresas es que en esta página te carga un iframe de YouTube, por ejemplo.
Y lo que hace Google es decir, vale, esta persona que está viendo esta página que es mía, voy a abrir un iframe de YouTube y así voy a traspasar las cookies que tengo en Chrome.com y se las paso a YouTube.
Que tú dirás, pero ¿por qué haría esto?
Obviamente lo hace por un tema de tener más información tuya en el máximo número de dominios posible.
Y esto también es una cosa que ha hecho Facebook, con Instagram y viceversa.
Tú entras a Instagram y no sabes por qué, porque hay peticiones de Facebook.com.
Pues muchas veces se hace por esto, por un intercambio de cookies para saber más de ti y poder perseguirte hasta final de los días.
¿Qué pasa? Pues se va a crear un nuevo tipo de iframe que se llama Fence Frame.
Es como un iframe con vallas, donde la idea es que no pueda tener acceso a cierta información como por ejemplo el DOM,
o poder observar atributos, no poder leer la URL desde la que se ha abierto el iframe, que puede ser dependiendo del caso de uso,
o que sea totalmente opaco, sabes, que sea totalmente opaco.
O que sí que le puedas pasar información, o sea, es que depende, ¿no?
Así que ese tipo de cosas lo van a hacer con este Fence Frame.
Y veis aquí un poquito la diferencia.
Por ejemplo, si tú abres el news.example, esto sería como funcionaba el iframe anteriormente,
que como puedes ver, pues tenías este acceso ahí, pues bilateral casi.
Y en cambio, aquí tenemos el after, que sería con el iframe, con el Fence Frame este nuevo.
Y ahora, que se supone que podríamos ponerle como vallas para evitar esto.
Pero hay otra que, ojo, cuidado con esta.
No sé si lo sabéis, pero las cookies, tal y como las conocemos, no sé si van a desaparecer,
pero sí que van a mutar bastante.
Uno de los grandes problemas históricos de internet ha sido las cookies.
Las cookies son como, yo qué sé, como si básicamente tuvieses una caja fuerte sin puerta.
Eso básicamente serían las cookies.
Donde tú vas guardando de todo, donde te crees que es una caja fuerte y no tiene puerta.
Y ahí tienes como todos los documentos, todas tus cosas y tal.
Y durante mucho tiempo eso se ha aceptado y se ha abusado.
Eso es lo peor, que se ha abusado de una forma asquerosa.
Las páginas web se han aprovechado de esto.
Y ha sido tremendo.
No solo por problemas de seguridad, porque un tema es la seguridad, que obviamente es bastante importante.
Pero en otro tenemos la privacidad, lo cual es bastante bestia.
Tened en cuenta que por culpa de esto se ha podido rastrear al usuario a través de diferentes páginas web.
Seguro que os ha pasado que habéis entrado a un sitio, a Amazon.
Habéis hecho tres compras o habéis hecho una búsqueda de vibradores o de lo que sea.
Porque era un regalo para vuestra pareja, lo que sea.
Y resulta que un día estáis mirando las noticias deportivas y de repente os aparece ahí un vibrador.
Y dices, ¿pero por qué?
Pero si esto era privado, que nadie debería haberse dado cuenta de esto.
Pues este tipo de cosas se hacía a través de las cookies.
Amigos, amigos, ¿qué tenemos?
Ocho años, que hay gente, los vibradores existen, es una realidad.
Y la gente compra esas cosas.
O sea, los sex shops viven de algo.
O sea, viven de algo.
¿Qué es un vibrador?
Es lo que tiene el DualShock.
Solo que no se pone en las manos.
Bueno, total.
Tenemos aquí el Topics API.
Durante mucho tiempo, las third-party cookies y otros mecanismos se han utilizado para trackear a cómo los usuarios utilizaban las diferentes páginas web en un montón de sitios.
Pues eso es lo que os digo.
Ibas a Amazon y te trackeaban y entonces luego así te pueden enseñar publicidad en todos los lados.
Que a ver, también es verdad que a día de hoy, pues utilizando Brave y un montón de navegadores, ya no te tenías que preocupar tanto de esto.
Justamente, mis sensaciones.
¿Qué es lo que ha pasado?
Safari, Firefox, Brave y un montón de navegadores, no Chrome, obviamente, han puesto el foco en evitar las cookies y también evitar los trackings.
Las dos cositas que ha hecho que se perdiese muchísimo dinero.
De hecho, Facebook, ¿cuánto dinero pierde dinero por culpa de Apple?
Una investigación desde Financial Times ha descubierto que Snapchat, Facebook, Twitter y YouTube perdieron alrededor de 10.000 millones de dólares en ingresos tras los cambios de Apple en sus prácticas de privacidad.
¿Qué es lo que ha pasado con esto? Pues Apple justamente lo que ha hecho es evitar este tipo de prácticas, que no es exactamente la de las cookies, pero están relacionadas.
Esto tiene un impacto directo en la publicidad, porque no es lo mismo que detecte tus preferencias a que no sea capaz y te tenga que mostrar publicidad genérica.
Entonces, al final, pues tiene peor rendimiento esa publicidad.
¿Quién es el que gana más dinero con la publicidad?
A ver, que os lea. Santa Google. No, Facebook no. Más quisiera Facebook. Más quisiera Facebook.
Google gana una salvajada, una salvajada de dinero.
Y es que ya no solo hay que pensar en el buscador, ¿no? En el propio Google.
En todas las páginas web con AdWords, en YouTube, en un montón de sitios. Es que hasta en Gmail te mete publicidad en todos los sitios.
Entonces, Google le ha visto las orejas al lobo y han sacado una iniciativa que se llama Topics API.
Topics API lo que viene a hacer es que va a ser el propio navegador, a nivel de navegador, ojo, no a nivel de cookies, a nivel de navegador, que sin leer y sin necesitar cookies,
lo que va a hacer es tener la posibilidad de indicarle a aquellos que quieran qué intereses tiene el usuario.
La Topics API te permite tener Interest Based Advertising, que sin utilizar el tracking de los sitios, te va a trackear el navegador.
¿Esto lo sabíais? O sea, es que de verdad, porque esto es increíblemente el impacto que va a tener el mundo del desarrollo web en el debate y la guerra,
porque esto va a ser una guerra, lo vais a ver. La idea se supone que es como para mejorar tu privacidad, porque ya no tendrán acceso a las cookies.
Pero el tema es que esto va a ser a nivel de navegador, que obviamente esto lo van a tener que desactivar seguro.
Lo van a tener que desactivar o lo van a tener que poder desactivar seguro. O sea, a nivel de navegador lo podremos desactivar, estoy seguro que va a ocurrir.
Porque es que si no, lo que van a tener, por ejemplo, esta API, lo que van a poder hacer cualquier página es, llamando a una API, le dirá,
oye, este usuario que me está entrando, ¿qué intereses tiene? Y le pasará un array con todos los intereses, para poder mostrarle todos los anuncios que tienen sentido.
¿Cuál se supone que es la gracia de esto? Dice, los topics son señales que ayudan a las plataformas técnicas a mostrar anuncios relevantes.
A diferencia de las third parties cookies, esta información está compartida sin revelar más información sobre quién es el usuario o la actividad en el navegador del usuario.
Hasta aquí bien, ¿no? Pero hay cierta preocupación de a ver hasta dónde llega esto, si se puede desactivar o no, que está por ver exactamente si se va a poder desactivar.
Pero bueno, esto es un mecanismo que para bien y para mal va a cambiar cómo funciona mucho de las páginas web.
Todo lo que sabéis de cookies, seguramente esto va a cambiar mucho, tanto si sois una empresa que utilizaba las cookies para guardar información por los intereses del usuario,
como si sois una página que utilizaba servicios de terceros para enseñar publicidad, o sea, que lo tengáis en cuenta.
Sobre todo esto, hay una cosa positiva, y es que mucho de esto, a día de hoy, se hace con JavaScript.
Y tiene un impacto muy negativo normalmente en el rendimiento del usuario, ¿no?
Porque tienes que cargar un pedazo de scripts muy tochos, muy bestias, muy asquerosos, ¿no?
Creo que esa puede ser cosa positiva, porque ahora va a ser a nivel del navegador.
Ya veis que lo único que tienes que hacer es llamar a esto, que ahora no funciona, obviamente, ¿eh?
Pero la API será llamar a este método, hacéis aquí, y esto os devolverá un array con todos los tópicos de interés del usuario del navegador.
Lista de empresas españolas con contratos en español que ofrecen trabajo en remoto.
Es una lista bastante, bastante bestia.
Entonces, condiciones, que tengan remoto, ofertas y tal, ¿vale?
Aquí tenéis todas las empresas españolas con posiciones abiertas que podéis trabajar en remoto.
Por ejemplo, pues seguro que tenemos aquí Typhoon, ¿vale?
Que, bueno, últimamente Typhoon tampoco está de aquella forma, ¿eh?
Tampoco está muy bien, Typhoon las cosas como son.
Porque ha habido bastantes recortes, pero bueno, todavía ahí siguen buscando gente.
Obviamente no todos tendrán junior, por ejemplo, aquí no veis...
Bueno, este back engineer, no parece que...
Y ves, remoto.
Pues aquí hay un montón de empresas que le podéis echar un vistazo.
Aquí tenéis Seat Code, que también está aquí en Barcelona y que también tiene trabajo en remoto.
Que hablan muy, muy bien de esta empresa, ¿eh?
Trabaja muy bien con el código y tal.
Así que nada, aquí tenéis para aburriros.
Y aquí este buen hombre, Isha, ha hecho un artículo buenísimo donde lo que ha hecho es comentar todos los detalles de CSS que tiene.
Por ejemplo, es esto.
Esto que veis aquí es sorprendentemente un display grid.
O sea, todo lo que veis aquí está hecho con grid.
Y tiene detalles minúsculos que alucinas.
Claro, yo ni siquiera me lo había planteado que esto podía ser un grid.
Y yo cuando lo he visto me he dicho, hostia, pero mira, aquí se puede ver.
¿Ves? Display grid, grid template columns, Barcelona thread.
Pero lo más sorprendente, y que él lo comenta, el avatar, por ejemplo, tiene un pequeño padding top como para alinearlo mejor con la letra.
Estos detalles son los que hacen que visualmente funcione tan bien a la vista.
Bueno, lo de los espacios, cuánto espacio ha puesto y aquí, pues, cómo está haciendo el cálculo de 36, que aquí deja 48, que no sé qué.
Y una cosa que está bastante bien también es el tema de cómo ha usado el SVG.
¿Ves? Cuando tenéis una contestación, fijaos que esto tiene una raya y aquí hay como un lacito.
Pues claro, yo también, la verdad que cuando lo vi, me pregunté, ostras, ¿cómo habrán hecho esto?
Porque queda súper chulo.
¿Veis? Esta rayita y aquí como un lacito.
Mi pregunta del millón era, ¿cómo sabe la distancia a la que tiene que poner el lacito?
Porque eso es lo complicado realmente.
Y está chulo porque aquí te lo explica.
Te dice, mira, esto es un SVG path.
Y lo que hace es que la longitud de la primera parte, que supongo que es la parte fluida, lo hace con JavaScript.
Lo mejor, y así es como vamos a poder ir a lo siguiente que te quiero hablar, es el uso del Dynamic Viewport Units.
Que cuando se carga la página, esta de aquí, que bueno, se ve muy poquito.
Vamos a desactivar JavaScript, a ver si...
¿Vale?
Fijaos, se queda aquí, ¿no?
Esta es la página de carga.
Si miráis aquí...
Bueno, aquí...
Ah, mira.
¿Alguien conocía esto?
¿Alguien conocía este 100DVH?
¿Alguien sabe lo que es eso?
Fijaos porque hay dos técnicas aquí que están muy chulas.
Y que además os puede servir.
Fijaos que lo que ha hecho el agente de Threads, de Meta, fíjate que tiene el height, lo tiene repetido dos veces, ¿no?
Uno, que está tachado, y pone 100VH.
Y el segundo, que es 100DVH.
El DVH, que lo tiene en otro artículo este chico, habla de las nuevas unidades de valor que podéis utilizar más allá del Viewport.
El problema es que durante mucho tiempo hemos utilizado 100 unidades del Viewport, y en muchos navegadores no queda muy claro cuál es el 100 unidades del Viewport.
¿Por qué?
Porque hay que contar esto o no hay que contar esto.
Cuando sale el teclado, ¿qué pasa con el teclado?
Y es complejo, porque entonces cuando tú utilizas esto del Viewport e intentas centrar algo, fíjate que cuando tú lo centras, si te fijas, esto no está centrado.
¿Por qué no está centrado?
Porque está contando esta parte como si fuese parte del Viewport, y no lo es.
Queda mal centrado porque hay una separación visual de 247 por arriba y 178 por abajo.
Lo que está comparando es, lo que tú esperas es que el 100VH sea esta parte de aquí.
Y en realidad te está dando esta parte de aquí, ¿vale?
Tú esperas esto y te está contando esto de aquí.
¿Pero cuál es el problema?
El problema justamente es que encima cuando haces scroll entonces se ve bien, porque ya desaparece la barra de direcciones.
Para eso han sacado nuevas unidades del Viewport, ¿vale?
Tenemos ahora una nueva que es la SVH.
La SVH es el Viewport más pequeño posible, contando toda la barra de tareas.
Luego tendríamos el LVH, que es el más grande, que sería contándolo sin toda la barra de tareas.
Y luego tendríamos el dinámico.
Pues el dinámico es que la parte que va a desaparecer, pues irá cambiando, e irá cambiando, y dependiendo de si está o no está, pues se calculará automáticamente.
Y aquí tenemos un ejemplo.
Mira, aquí tenemos un ejemplo.
Por ejemplo, ves que cuando va cambiando, pues aquí puedes ver, aquí ves aquí a la izquierda, el Dynamic Viewport, cómo se va calculando.
Primero es así, pero cuando haces scroll se va haciendo cada vez más grande.
Y esto es súper útil y súper importante, pues como por ejemplo, nada más entrar aquí, imagínate, para poder centrar esto, tienes que saber exactamente el Viewport.
Fíjate que utiliza los dos.
Y es el tema de poner algo que, si no soporta el navegador, lo pones como segunda opción.
Esta semana ha habido nueva reunión del comité del TC39 y tenemos novedades importantes e interesantes para JavaScript.
Y hay dos, especialmente dos, que marcan la diferencia, que llaman mucho la atención y que no te puedes perder.
El primero pasa a la fase 3, Array Grouping, por fin, que es este de aquí.
Y os lo voy a explicar porque este es uno que vais a utilizar cuando esté ya estable, que yo creo que el año que viene ya sale.
Os he hablado de esta propuesta, pero se ha modificado, se ha cambiado respecto a la última vez.
¿De qué se trata esta propuesta?
Esta es una propuesta que te va a permitir agrupar los elementos de un Array en un objeto o un Map.
Y esto, antiguamente, iba a ser Array.GroupBy, pero lo han cambiado.
Ahora lo han puesto como método de Object.
Aquí lo podéis ver, Object.GroupBy.
Igual que tenéis Object.Keys, pues vamos a añadir ahora Object.GroupBy.
Al que le tienes que pasar un Array como primer parámetro y en el segundo un Callback.
Y en el Callback lo que vas a poder es agrupar, pues tú le puedes pasar y decir aquí la condición
y lo que devuelves es la llave donde se va a agrupar ese elemento en el objeto.
Aquí al hacer el GroupBy y decirle, vale, pues si el número es divisible entre dos, entonces devuelvo Even, o sea, que es par.
Y si no, pues impar.
Y esto lo que va a hacer es que nos va a separar en un objeto, en la propiedad odd, porque eso hemos dicho nosotros,
los números que son impares.
Y en el Even, que son pares, los números que son pares.
O sea, estamos agrupando elementos de un Array, vale, elementos de un Array en un objeto.
Es como transformar un Array en un objeto a través de la condición que nosotros queramos.
Imagínate que tenemos aquí Names y tenemos aquí, pues, Midout, Meblock, joder, me he pillado el más rápido.
Imagínate que quieres apilar aquí cada nombre.
Pues podrías poner Name, imagínate que podrías devolver directamente el primero Name, perdón, la primera letra.
Y así, aquí, debería devolverte.
Con la M, pues tendrías a Midu.
Con la P, pues tendrías aquí a Feral.
Dependiendo de lo que tú devuelves directamente, aquí estamos recuperando el primer carácter del string.
Lo que estamos haciendo es agrupar con lo que nosotros nos dé la gana.
Fíjate la condición que he hecho aquí, que es devolver directamente el string el primer carácter.
Y entonces aquí lo que estamos haciendo es recuperar el primer carácter, que es Midu, y aquí se están agrupando todos.
Mr. Caratortilla, entonces aparecería aquí, Mr. Caratortilla, ¿vale?
Porque lo estamos agrupando, y aquí pues seguiría...
Pero entendéis un poco la idea de cómo se agrupan?
O sea, tú aquí lo que le pasarías es en qué propiedad hay que agrupar ese elemento.
Y te agrupa la parte del Array, ahí.
En Array no sería Names, a ver, Array...
Ay, perdón, igual, es que claro, como no...
Sí, esto sería Names, ¿vale?
Perdón, ¿eh?
Y también lo podrías hacer exactamente lo mismo con los Maps.
Y fíjate que aquí te explican por qué han utilizado un método estático como el Object Keys, Object Values y todo esto.
La idea es que fuese parte del Prototype de Array, encontramos un problema de compatibilidad con el nombre de Group By.
Una biblioteca...
Randomísima.
Más random que saberte el segundo apellido de tu tía abuela.
Fíjate.
De Sugar Library hasta la versión 1.4.0...
Esta no lo conocía ni el Tato.
Esta biblioteca, hasta la versión 1.4.0, o sea, no todas las versiones, hasta la versión 1.4.0, dice condicionalmente, hacía un monkey patch, o sea, cambiaba, modificaba el Array.prototype, con un método incompatible.
Y le daba un método que se llama Group By.
Entonces, claro, si añadían el Group By, hacía que estas páginas petasen y que todas las páginas que dependiesen de esto petaran.
Hemos encontrado 660 orígenes que utilizan esa versión de la biblioteca.
Por culpa del vasto internet, que hay miles de millones de páginas, han encontrado 660 orígenes.
Orígenes significa dominios, ¿vale?
Dominios.
O sea, que a lo mejor la página pepito.com, ¿vale?
Pepito.com, se ha quedado por ahí tirada y sigue utilizando esto.
Solo por esos 660 dominios no lo han hecho por eso.
Os voy a enseñar otra propuesta que está muy chula y que ha avanzado a la fase 1, pero que esta va a llegar seguro, lo sabe bien, lo sabe Dios, lo sabe Dios.
Se llama Proposal Optional Chaining Assignment.
Ya conocéis todos y todas el Optional Chaining.
Tenemos aquí un objeto, el nombre Midu, ponemos aquí social y ponemos aquí Twitter.
Entonces, si tú haces persona.info.age, esto peta, ¿vale?
Porque no puedes leer el age de undefined, porque info es undefined.
Entonces, el Optional Chaining es este operador, ¿vale?
Son dos, o sea, son dos símbolos que mucha gente se cree que es este.
Este no es, es este, ¿vale?
Este es el operador.
El operador es el interrogante y el punto, los dos juntos.
¿Cómo se utiliza el Optional Chaining Operator?
Pues tú cuando no estás seguro si por lo que sea existe el info, lo que puedes decir, bueno, no sé si esto existe.
Entonces, si persona.info, si existe, voy a acceder al age, si no existe, devuelve null.
De hecho, esto, console.log, esto lo que nos va a devolver es undefined, ¿vale?
O sea, vamos a poder intentar acceder a propiedades profundas del objeto, aunque no sepamos si realmente info existe o no existe.
Si no lo utilizamos, peta, y si lo utilizamos, es como que va a estar preguntando constantemente, ¿no?
Info existe, si existe, accedo a age, y si no, devuelvo undefined, ¿no?
Y así, pues vamos así otra vez, no, sí, ¿vale?
Y vamos así otra, ¿vale?
Incluso lo podéis utilizar también con funciones, ¿vale?
Lo podéis hacer, ¿ves?
Estoy intentando ejecutar la función otra, que no sé si existe, y como puedes ver aquí, pues me da undefined.
O sea, que no está petando, por suerte, ¿no?
Va a salir una cosita nueva, muy interesante para JavaScript, ¿ok?
Que se llama Proposal Optional Chaining, que es como el que hemos explicado, Assignment.
Muchas veces lo que queremos es asignar una propiedad a un objeto, pero solo si el objeto existe.
En este ejemplo que teníamos, imagínate, claro, esto porque ya sabemos que aquí persona existe y tal,
pero imagínate que yo quiero hacer, si persona existe, entonces vamos a hacer persona.info.age y ponemos 18.
Claro, esto no funciona, no funciona, esta sintaxis errores, porque ahora no existe,
pero imagínate que dices, vale, si persona existe, entonces, si persona existe y también existe persona.info,
entonces vamos a asignar persona.info.age igual 18, ¿vale?
Vamos a hacer esto.
¿Por qué?
Porque muchas veces lo que quieres es solo cambiar un valor si realmente existe toda la estructura.
Pero, ¿qué pasa?
Que esto es un rollo.
Imagínate que puedas hacer esto.
Si persona existe, infox existe, entonces vamos a hacer esto.
Pues esta, esta es la nueva propuesta.
Un Optional Chaining que vas a poder hacer una asignación directamente.
Y lo que estás haciendo aquí es exactamente, bueno, bastante parecido, no exactamente,
pero bastante parecido a lo que hemos hecho en la línea 9.
No es exactamente porque aquí estamos revisando si esto, si persona sería, exactamente sería algo así.
Sería algo así.
O más parecido, no exactamente tampoco, pero sería más parecido.
Si persona es diferente a nul y es diferente a nul, sería algo así.
Y sería además así.
Si persona es diferente a nul y persona.info es diferente a nul, entonces hacemos esto.
Haríamos esta asignación.
Súper chulo, súper, súper, súper chulo.
¿Es básicamente un if?
Hombre, muchas veces es básicamente un if, pero lo que está haciendo es que podamos programar mucho más rápido.
Y aquí tenéis algunos casos de uso, ¿no?
Ojo con esto, porque es que además podéis utilizar también otro tipo de asignaciones.
Por ejemplo, imaginad que en este, aquí en el age, tenéis un count, ¿vale?
Como para contar, ¿no?
Bueno, aquí podríais hacer esto, ¿no?
Más uno.
Como para incrementar en uno.
Pues es que aquí también lo podríais hacer.
Podríais hacer esto.
Podríais incrementar en uno el valor.
¿Sabes?
Esto está súper chulo, pues también lo podríais hacer así.
Me queda la duda si se podría hacer esto.
Viéndolo aquí, no parece que se pudiera.
El salseo, amigos, es de nuestro amigo Douglas.
Douglas Crockford escribió este maravilloso artículo en este blog sensacional que tiene.
El 27 de mayo lo escribió, pero el salseo se ha ido originando estas últimas semanas en Internet.
Y es que aquí el bueno de Douglas, que si no sabes quién es Douglas Crockford, está últimamente en boca de todos.
Porque es el creador de JSON y es el que últimamente se está cagando encima de JavaScript.
Por encima, por debajo, por detrás, por los lados, por todos los lados.
También el escritor del libro de The Good Pass.
Un libro de JavaScript ya antiguo, pero que tuvo muy buenas críticas en su día, ¿vale?
Sí, también odia CSS.
Este hombre odia a todo el mundo.
Espero que no odie a sus nietos también.
Dice, JavaScript se inventó para añadir interactividad a los navegadores.
Hace 20 años recomendaba que no se utilizase de forma directa y que se utilizase una librería.
Mis razones eran que el DOM estaba mal diseñado, mal implementado y lleno de inconsistencias.
El DOM, o sea, el Document Object Model, para el que no sepa lo que es,
ha sido una gran raíz de dolores, sufrimientos, miseria, que podían ser mitigadas por una buena librería.
Pero desde entonces, los estándares web, la comunidad, en gran parte,
ha corregido mucho de esos fallos del consorcio de la World Wide Web.
Y ahora es mucho menos deficiente y es más portable y confiable.
Y es por lo que ahora recomiendo abandonar las bibliotecas.
Es que también, este tío, este tío no tiene término medio, o sea, él va a lo tóxico.
¿Sabes? Ahora que dejo tranquilo al DOM, pues ahora voy, ahora voy a poner las bibliotecas.
Que han hecho que las plataformas estén hinchadas.
Y en su lugar, utilizar DOM y JavaScript plano.
Dice, mira, un ejemplo modesto, y tan modesto, amigo.
Dice, el DOM, la verbosidad, es verboso y raro.
Y podemos hacer una función DOM así de fácil, ¿no?
Y te dice, toma, cambia, cambia esto.
Toma, quita, quita tu React y pon esta función.
Está bien, me gusta el intento.
Bien, Q2, Q2 por el intento, por este pseudo JSX.
Pero, a ver, y el estado, y añadir un evento, y el click para pintar algo con JavaScript.
A lo mejor no está mal, pero es que ni siquiera, es que esto no tiene ni la interactividad básica mínima.
De eso, habla, liberó.
Que liberó, pues tiene sus cosas.
También a veces se pone en modo hardcore.
Dice, tengo un gran respeto por Douglas.
Me encanta, me encanta el cuando empiezas a, le vas a hacer un sándwich a alguien.
Dice, lo has hecho muy bien, pero.
Tengo un gran respeto por Douglas y lo que ha hecho por la web.
Viene el pero con la mano abierta.
Esto es un poco sordo a las necesidades de los desarrolladores.
No, probablemente no debería crear una aplicación web mediana o más grande hoy simplemente usando el DOM.
O terminarás con una base de código muy acoplada.
O estarás reinventando muchos de los conceptos que las bibliotecas y los frameworks han perfeccionado durante años.
Cosa que estoy bastante de acuerdo.
Y entonces aquí explica, ¿no?
Ingenuamente sobreescribes todo el subárbol que abarca los nodos, ¿no?
Cuando haces lo del estado y tal.
El objetivo de React, Lit y muchas otras bibliotecas es combinar la Developer Experience con el rendimiento.
Otros frameworks como Vue usan la reactividad para mejorar la Developer Experience de ambos.
El DOM sin procesar está bien para sitios con mucho contenido que solo necesitan muy poco código de actualización.
Claro, cuando tú tienes una página que no se actualiza, que no es interactiva, es que ni siquiera necesitas el código de Douglas.
Es que necesitas Astro.
O haces Astro, le sirves el HTML estático y ya está.
Ni siquiera necesitas JavaScript.
Pero claro, cuando necesitas interactividad, cuando es una SPA que tiene que cambiar, claro, necesitas cosas.
Dice, quiero un futuro en el que frameworks y bibliotecas no sean tan necesarias para crear aplicaciones web no triviales.
Pero para llegar allí necesitamos una mayor abstracción sobre el DOM, no para engañar a los desarrolladores de que lo están haciendo mal.
Dios, la verdad.
A mí me parece que la opinión de Douglas está como que no tiene...
O sea, que está muy desubicada de la realidad.
Muy desubicada la realidad.
Porque a lo mejor Douglas podría haber dicho, para hacer mi página web, para hacer mi blog, no necesito librerías.
Y ahí estaría de acuerdo.
Para hacer esta página web no necesitas React, obviamente.
Está bien, tienes razón.
Pero cualquier página a día de hoy mínimamente interactiva no es React.
Pero a lo mejor necesitas Svel.
Necesitas lead como mínimo.
Necesitas alguna abstracción seguro.
Los salseos que tengo de todo.
Que tengo de todo.
Oye, por cierto, muchas veces me...
Oye, por cierto, muchas veces me...