Smashing Podcast Episodio 21 con Chris Ferdinandi: ¿Las mejores prácticas modernas son malas para la web?

Hoy, nos preguntamos si las mejores prácticas modernas son malas para la web. ¿Los marcos modernos nos están llevando por el camino equivocado? Hablo con el experto en Lean Web Chris Ferdinandi para averiguarlo.

Mostrar notas

• Página de Chris con enlaces y notas para el podcast.
• El libro Lean Web
• Chris Ferdinandi en la web
• Chris en Twitter
• El podcast de JavaScript Vanilla

Actualización semanal

• “Traducción de Wireframes de diseño en HTML/CSS accesible”
  por Harris Schneidermann
• “Creación de aplicaciones de escritorio con Electron y Vue”
  por Timi Omoyeni
• “Técnicas modernas de CSS para mejorar la legibilidad”
  por Edoardo Cavazza
• “Cómo usar componentes con estilo en React”
  por Adebiyi Adedotun Lukman
• “Cómo Crear Un Porsche 911 Con Sketch”
  por Nikola Lazarevic

Transcripción

Drew McLellan: es el autor de la serie de guías de bolsillo Vanilla JS, creador del programa de capacitación de la Academia Vanilla JS y presentador del podcast Vanilla JS. Desarrolló un boletín de sugerencias, lo leen casi 10,000 desarrolladores cada día de la semana. Ha enseñado a desarrolladores en organizaciones como Chobani y The Boston Globe. Y sus complementos de JavaScript han sido utilizados por organizaciones como Apple y Harvard Business School. Sobre todo, le encanta ayudar a las personas a aprender JavaScript Vanilla. Entonces, sabemos que preferiría elegir Vanilla JavaScript en lugar de un marco, pero ¿sabías que una vez lo seleccionaron en una rueda de reconocimiento policial como la persona con menos probabilidades de haber cometido el crimen? Mis amigos de Smashing, denle la bienvenida a Chris Ferdinandi. Hola Chris. ¿Cómo estás?

Chris Ferdinandi: Oh, estoy genial. Gracias por invitarme.

Drew: Quería hablarte hoy sobre este concepto de Lean Web, que te apasiona, ¿no?

Chris: Sí, mucho.

Drew: ¿Por qué no preparas la escena para nosotros? Cuando hablamos de Lean Web, ¿cuál es el problema que estamos tratando de resolver?

Chris: Sí, gran pregunta. Solo como una advertencia para todos los oyentes, este episodio podría tener un viejecito gritando a la nube. Voy a tratar de evitar eso. Cuando observo la forma en que construimos para la web hoy en día, se siente un poco como un desastre inflado y con exceso de ingeniería. He llegado a creer que mucho de lo que consideramos mejores prácticas hoy en día podría estar empeorando la web.

Chris: The Lean Web es un enfoque para el desarrollo web que se centra en la simplicidad, el rendimiento y la experiencia del desarrollador sobre... lo siento, no la experiencia del desarrollador. Más bien, la experiencia del usuario, sobre la experiencia del desarrollador, y la facilidad de construir cosas desde una perspectiva de equipo, que es en lo que creo que nos enfocamos mucho hoy y en lo que probablemente entraremos en nuestra conversación.

Chris: De hecho, me he dado cuenta de que muchas de estas cosas que pensamos que mejoran la experiencia del desarrollador lo hacen para un subconjunto de desarrolladores, pero no necesariamente para todos los que están trabajando en lo que estás creando. Entonces, también hay un montón de problemas con eso, en los que podemos profundizar. Pero en realidad, Lean Web se trata de centrarse en la simplicidad y el rendimiento para el usuario y realmente priorizar o poner el foco en las personas que usan las cosas que hacemos en lugar de en nosotros, las personas que las fabrican.

Drew: A medida que la web madura como plataforma de desarrollo, parece haber un impulso cada vez mayor hacia la especialización.

Chris: Sí.

Drew: Personas que solían cubrir Full Stack, y luego nos dividimos en front-end y back-end. Y luego ese front-end se dividió en personas que hacen desarrollo de CSS o JavaScript. Y luego, cada vez más dentro de JavaScript, se vuelve más especializado. Alguien podría considerarse y comercializarse a sí mismo como un desarrollador de React o de Angular, y toda su identidad y perspectiva se basan en un marco particular en el que están altamente capacitados. ¿Es esta dependencia de los marcos el núcleo de nuestro trabajo en la web? ¿una cosa mala?

Chris: Tiene matices. Solía ​​​​ser muy fuerte en el sí, siempre acampar. Creo que, en términos generales, todavía siento que sí, nuestra obsesión como industria con los marcos y las herramientas en general, es potencialmente un poco perjudicial para nosotros. No creo que los marcos sean intrínsecamente malos. Creo que son útiles para un subconjunto muy reducido de casos de uso. Y terminamos usándolos para casi todo, incluidas muchas situaciones en las que no son necesariamente la mejor opción para usted o para el proyecto.

Chris: Cuando pienso en muchos de los problemas que tenemos en la web hoy en día, el núcleo de esos problemas realmente comienza con nuestra dependencia excesiva de los marcos. Todo lo demás que viene después de eso es de muchas maneras, porque lanzamos mucho no solo marcos, que es JavaScript en general, en la web. Lo digo como alguien que enseña profesionalmente a la gente cómo escribir y usar JavaScript. Así es como gano mi dinero. Y estoy aquí diciendo que creo que usamos demasiado JavaScript, lo que a veces es un poco extraño.

Drew: Antes de que surgieran los grandes frameworks, solíamos construir interfaces de usuario y cosas con jQuery o lo que sea. Y luego aparecieron los marcos y nos dieron más de este concepto de una interfaz de usuario basada en el estado.

Chris: Sí.

Drew: Ahora, eso es un poco de ingeniería bastante complejo que se requiere para poner en marcha. ¿Trabajar con menos JavaScript excluye el uso de algo así, o tiene que volver a implementarlo usted mismo? ¿Estás creando un modelo repetitivo cargado?

Chris: Mucho depende de lo que estés haciendo. Si tiene una interfaz que no cambia, puede crear una interfaz de usuario basada en el estado con… no sé, tal vez una docena de líneas de código. Si tiene una interfaz que no cambia, honestamente, probablemente diría una interfaz de usuario basada en el estado. No es necesariamente el enfoque correcto. Probablemente hay otras cosas que puedes hacer en su lugar. Piense en generadores de sitios estáticos, algunas marcas renderizadas previamente, incluso un sitio basado en WordPress o PHP de la vieja escuela.

Chris: Pero donde esto empieza a ponerse interesante es cuando entras en interfaces más dinámicas e interactivas. No solo aplicaciones. Sé que a la gente le encanta trazar esta línea entre los sitios web y las aplicaciones, y creo que existe una mezcla extraña entre los dos y la línea no siempre es tan clara. Cuando empiezas a profundizar más, el usuario hace cosas, algo cambia. La interfaz de usuario basada en el estado se vuelve un poco más importante. Pero aún no necesita toneladas de código para que eso suceda.

Chris: Miro algo como React o Vue, que son piezas de ingeniería absolutamente asombrosas. No quiero quitarle nada a la gente que trabaja en eso. Terminé como un ejercicio de aprendizaje, construyendo mi propio mini-marco solo para tener una mejor idea de cómo funcionan estas cosas debajo del capó. Es realmente difícil dar cuenta de todas las diferentes piezas en movimiento. Así que tengo un gran respeto por las personas que construyen y trabajan en estas herramientas. Pero React y Vue tienen unos 30 kilobytes después de minificar y comprimir. Entonces, una vez que los desempaqueta, son sustancialmente más grandes que eso.

Chris: No todo, pero una buena parte de ese peso se dedica a esta cosa llamada DOM virtual. Existen alternativas que utilizan API o enfoques similares. Para React, tiene Preact, que tiene 2,5 kilobytes o unos 3 kilobytes en lugar de 30. Es una décima parte del tamaño. Para Vue, tiene Alpine JS en su lugar, que tiene aproximadamente 7 kilobytes. Aún así, sustancialmente más pequeño. La gran diferencia entre estos y sus contrapartes de hermano mayor es que se han desprendido del DOM virtual. Pueden abandonar un método o dos. Pero, en general, es el mismo enfoque y el mismo tipo de API en la forma de trabajar con código, y son sustancialmente más pequeños.

Chris: Creo que muchas de las herramientas que usamos son potencialmente superadas por las cosas que estamos tratando de hacer. Si necesita una interfaz de usuario basada en el estado y necesita datos reactivos y estas interfaces dinámicas, eso es genial. Creo que una de las grandes cosas de las que trato de hablar hoy no es... nunca usar herramientas. Para mí, Vanilla JS no es que estés escribiendo a mano cada línea de código y cada proyecto que haces. Eso es locura. Yo no podría hacer eso, yo no hago eso. Pero es ser más selectivo con las herramientas que usamos. Siempre buscamos la multiherramienta, la navaja suiza que tiene todas estas cosas. Y a veces, todo lo que realmente necesitas es un par de tijeras. No necesitas todas las otras cosas, pero las tenemos de todos modos.

Chris: Lo cual es un largo camino para... lo siento, para responder a tu pregunta. Lo que a veces es más código del que podría o querría escribir usted mismo, pero no es tanto código como creo que requiere. Cuando digo que no necesitas un marco, recibo un gran rechazo en torno a esta idea de que "bueno, si no usas un marco, básicamente estás escribiendo el tuyo". Entonces eso viene con sus propios problemas. Creo que hay un lugar entre usar React o Vue y escribir tu propio marco, y tal vez sea elegir algo que sea un poco más pequeño. A veces, hay razones por las que escribir su propio marco puede ser la decisión correcta, dependiendo de lo que intente hacer. Todo es muy fluido y subjetivo.

Drew: Es bastante interesante que, como ejercicio de aprendizaje, implementaste tu propio marco basado en estados. Recuerdo que en el pasado, solía pensar que cada vez que buscaba una biblioteca o algo así, me gustaba pensar que podría implementarlo yo mismo.

cris: claro, claro.

Drew: Pero llegar a la biblioteca me ahorró la molestia de hacerlo. Sabía que si tenía que escribir este código yo mismo, sabía qué enfoque tomaría para hacerlo. Y eso fue cierto todo el camino hasta el uso de cosas como jQuery y cosas así. En estos días, creo que si tuviera que escribir mi propia versión de Vue o React, casi no tengo idea de lo que está sucediendo ahora en esa biblioteca, en todo ese código.

Drew: Para aquellos de nosotros que no estamos familiarizados, cuando dices algo como Preact elimina el DOM virtual y hace que todo sea mucho más pequeño, ¿qué nos da ese DOM virtual?

Chris: Para responder a esa pregunta, quiero dar un pequeño paso atrás. Una de las mejores cosas que le brindan los marcos y otras bibliotecas basadas en el estado es la diferenciación de DOM. Si realmente no está actualizando tanto la interfaz de usuario, podría arreglárselas diciendo: “Aquí hay una cadena de cómo se supone que debe verse el marcado. En HTML, solo pondré todo este marcado en este elemento”. Cuando necesitas cambiar algo, lo vuelves a hacer. Eso es un poco caro para los navegadores, porque provoca un repintado.

Chris: Pero creo que potencialmente más importante que eso, uno de los problemas al hacer eso es que tienes algún tipo de elemento interactivo allí, un campo de formulario, un enlace en el que alguien se ha centrado. Ese enfoque se pierde porque el elemento... aunque tienes algo nuevo que se ve similar, no es el mismo elemento literal. Entonces, si se pierde el enfoque, puede crear confusión para las personas que usan lectores de pantalla. Hay un montón de problemas con eso.

Chris: Cualquier cosa de IU basada en el estado que valga la pena implementará algunas diferencias de DOM, donde dicen: “Así es como debería verse la IU. Así es como se ve ahora en el DOM. ¿Qué es diferente?" Y va a ir y cambiar esas cosas. Está haciendo de manera efectiva las cosas que haría simplemente actualizando manualmente la interfaz de usuario, pero lo está haciendo por usted debajo del capó. Así que puedes decir: "Así es como quiero que se vea". Y luego la biblioteca o el marco lo resuelven.

Chris: Las cosas más pequeñas como Preact o Alpine, en realidad lo están haciendo directamente. Están convirtiendo la cadena que les proporcionas de cómo debería verse la interfaz de usuario en elementos HTML. Y luego comparan cada elemento con su pieza correspondiente en el DOM literal. A medida que terminas con interfaces de usuario que se hacen más y más grandes, eso puede tener una implicación en el rendimiento porque consultar el DOM una y otra vez se vuelve costoso. Si desea tener una idea del tipo de interfaz en la que esto se convierte en un problema, haga clic con el botón derecho e inspeccione el elemento en el botón "Favorito" en Twitter o en el botón "Me gusta" en Facebook. Y eche un vistazo a la anidación de divs que lo lleva a ese elemento. Es muy, muy profundo. Es como una docena de divs, anidados uno dentro del otro solo para ese único tweet.

Chris: Cuando comienzas a bajar tantas capas, comienza a afectar realmente el rendimiento. Lo que hace el DOM virtual es que, en lugar de verificar el DOM real cada vez, crea un mapa basado en objetos de cómo se ve la interfaz de usuario en JavaScript. Y luego hace lo mismo para la interfaz de usuario con la que desea reemplazar la existente, y compara esas dos. Eso es mucho más rendimiento en teoría, que hacer eso en el DOM real. Una vez que obtiene una lista de las cosas que necesita cambiar, simplemente sale corriendo y realiza esos cambios. Pero solo tiene que atacar el DOM una vez. No es verificar cada elemento, cada vez. Si tiene interfaces como Twitter, Facebook, QuickBooks o algo así, el DOM virtual probablemente tenga mucho sentido.

Chris: El desafío con esto es... la diferencia entre Preact y React es de 27 kilobytes antes de desempaquetar todo en su onda de código real. La descarga sin procesar y el tiempo de desempaquetado y compilación solo en eso pueden agregar un poco de latencia a la carga inicial en una interfaz de usuario. Eso se vuelve aún más pronunciado si sus usuarios no están en los últimos dispositivos de Apple. Incluso un dispositivo Android de hace un par de años o un teléfono con funciones, o si tiene personas en países en desarrollo, es realmente... el tiempo para ponerse en marcha es más lento. Y además de eso, el tiempo interactivo real es más lento debido a la abstracción adicional.

Chris: Así que no es solo que lo cargas y son comparables en velocidad. Cada micro interacción que alguien hace y los cambios que deben ocurrir también pueden ser un poco más lentos solo por todo ese código adicional allí. Si tiene una interfaz de usuario muy, muy compleja con muchos elementos anidados y muchos datos, entonces las ganancias de rendimiento del DOM virtual superan el peso adicional del código. Pero cualquier interfaz de usuario típica para una aplicación típica para la que veo que la mayoría de los desarrolladores usan React o Vue, el beneficio que obtienes del DOM virtual simplemente no está ahí y estarían mejor. Incluso si desea mantener la misma comodidad de React, use Preact. Es una fracción del tamaño, funcionará exactamente de la misma manera y tendrá un mayor rendimiento. Este es el tipo de cosas que tiendo a defender.

Chris: Tenemos que mejorar en la elección de la herramienta adecuada para el trabajo. Si opta por un enfoque como ese, si llega a un punto en el que un DOM virtual realmente tiene sentido, es mucho más fácil portar Preact a React que si hiciera el suyo propio. Esa es la situación. Si está realmente preocupado por eso, también obtiene algunas pruebas de futuro incorporadas.

Drew: Algunos podrían decir, podrían argumentar que estos marcos, cosas como Vue, React, están tan altamente optimizados para el rendimiento que obtienes tantos beneficios allí que seguramente solo empareja eso con un administrador de paquetes en un paquete para asegurarse de que solo está enviando el código que desea. Seguramente, ¿ya estás muy adelantado con solo hacer eso?

cris: si no estoy de acuerdo Realmente no tengo mucho más para elaborar sobre eso aparte de... Supongo que tal vez, pero no realmente. Incluso con un paquete, aún necesita ese núcleo React. Incluso con la agrupación, seguirá siendo más grande que usar algo como Preact.

Chris: Drew, realmente aprecio que hayas liderado la pregunta sobre esto. Porque una de las otras cosas de las que sí hablo en mi libro, The Lean Web, y mi charla del mismo nombre, es cómo estas herramientas... Mencionaste la agrupación, por ejemplo. Una de las cosas que hacemos para sortear el impacto en el rendimiento que recibimos al usar todo este JavaScript es agregar aún más JavaScript en el front-end para tenerlo en cuenta. Una de las formas en que lo hacemos son los administradores de paquetes y los agrupadores de módulos.

Chris: Como mencionaste... para aquellos de ustedes que no saben, estas son herramientas que... compilarán todos sus pequeños fragmentos individuales de JavaScript en un archivo grande. Los más nuevos y los más... No quiero llamarlos pensativos. Pero los más nuevos usarán una función llamada sacudir el árbol, donde se deshacen de cualquier código que en realidad no se necesita. Si ese código tiene algunas dependencias que no se usan para lo que realmente has hecho, eliminarán algunas de esas cosas para que tus paquetes sean lo más pequeños posible. En realidad, no es una idea terrible, pero da como resultado esto que normalmente llamo salud de dependencia, donde tienes este castillo de naipes realmente delicado de dependencias sobre dependencias sobre dependencias.

Chris: Configurar su proceso lleva tiempo. Y cualquiera que alguna vez haya ejecutado una instalación de NPM y luego haya descubierto que un montón de dependencias estaban desactualizadas y tuvo que pasar una hora tratando de averiguar cuáles necesitaban ser arregladas y oh, en realidad es una dependencia en una dependencia y no No tienes la capacidad de ir a arreglarlo tú mismo. Es una cosa completa. Tal vez funcione para usted, pero prefiero pasar mi tiempo sin perder el tiempo tratando de unir mis dependencias.

Chris: Empecé a recopilar tweets de personas que se quejan del tiempo perdido en su flujo de trabajo. Uno de mis favoritos, Brad Frost hace un par de años, estaba hablando sobre la deprimente comprensión de que lo que has estado haciendo en JS moderno podría haberte llevado 10 minutos en jQuery. Realmente no soy un fanático de jQuery, pero siento ese dolor cuando se trata de trabajar con marcos.

Chris: El otro problema con muchas de estas herramientas es que comienzan a convertirse en guardianes. No sé cuánto quieres sumergirte en esto o no, Drew. Pero uno de mis grandes rechazos contra JS, todas las cosas en un flujo de trabajo. Especialmente cuando comienzas a decir: "Bueno, si ya estamos usando JS para HTML, ¿por qué no usarlo también para CSS?" Empiezas a excluir a mucha gente realmente talentosa del proceso de desarrollo. Es una gran pérdida para el proyecto para la comunidad en su conjunto.

Drew: Bueno, ciertamente lo soy... Empecé a elegir React a principios de 2020, y lo agregué a mi conjunto de habilidades. Lo he estado haciendo ahora durante casi siete meses. Debo decir que una parte en la que tengo menos confianza es en configurar las herramientas para comenzar un proyecto.

Drew: Parece que hay mucho trabajo para llevar algo a Hello World, y aún hay más que debes saber para que esté listo para la producción. Eso tiene que hacer que el desarrollo sea más difícil para comenzar si esto se presenta como lo que debería estar haciendo en 2020 para aprender a ser un desarrollador web. Alguien que llegue por primera vez va a tener un problema real. Va a ser una verdadera barrera de entrada, ¿no?

Chris: Absolutamente. La otra pieza aquí es que los desarrolladores de JavaScript no siempre son las únicas personas que trabajan en una base de código o que contribuyen de manera significativa a esa base de código. Cuanto más hagamos que conocer JavaScript sea un requisito para trabajar con una base de código, menos probable es que esas personas puedan participar realmente en el proyecto.

Chris: Un ejemplo de eso, del que me gusta hablar, es WordPress, que ha sido recientemente… no debería decir recientemente en este punto. Han pasado un par de años. Pero han estado cambiando su back-end stack cada vez más a JavaScript, alejándose de PHP, lo cual no es inherentemente algo malo. Su nuevo editor, Gutenburg, se basa en React.

Chris: En 2018, la consultora principal de accesibilidad de WordPress, Rian Rietveld, cuyo nombre casi con seguridad destrocé... renunció públicamente a su posición y documentó por qué en un artículo muy detallado. El núcleo del problema era que ella y su equipo tenían la tarea de auditar este editor para asegurarse de que fuera accesible. WordPress comprende ahora el 30% de la web. Su objetivo es democratizar la publicación, por lo que la accesibilidad es una parte muy importante de eso. Debe ser una parte importante de cualquier proyecto web. Pero para ellos en particular, es sumamente importante. Todo el trabajo de su equipo es asegurarse... todo el trabajo de su equipo era asegurarse de que este editor fuera accesible. Pero debido a que ni ella ni nadie en su equipo tenía experiencia en React y debido a que no pudieron encontrar voluntarios en la comunidad de accesibilidad con esa experiencia, se hizo realmente difícil para ella y su equipo hacer su trabajo.

Chris: Históricamente, podían identificar errores y luego entrar y corregirlos. Pero con el nuevo flujo de trabajo basado en React, se vieron reducidos a identificar errores y luego archivar tickets. Se agregaron a un trabajo pendiente junto con todas las demás solicitudes de desarrollo de funciones en las que estaban trabajando los desarrolladores de JavaScript. Un montón de cosas que podrían haberse solucionado fácilmente no llegaron a la primera versión.

Chris: En mayo de 2019, aproximadamente un año después de la renuncia de Rian, se realizó una auditoría de accesibilidad detallada en Gutenburg. El informe completo tenía 329 páginas. Solo el resumen ejecutivo tenía 34 páginas. Documentó 91 errores relacionados con la accesibilidad con bastante detalle. Muchos de estos fueron realmente... No quiero llamarlos simples frutos al alcance de la mano, pero muchos de ellos eran cosas básicas que el equipo de Rian podría haber solucionado y habría liberado a los desarrolladores para que se concentraran en el desarrollo de características. En última instancia, eso es lo que parece que terminaron haciendo: dedicar mucho tiempo al desarrollo de funciones y dejar estas cosas para más tarde. Pero ese equipo es muy importante para el proyecto, y de repente quedaron fuera del proceso debido a una elección técnica.

Chris: Alex Russell es un desarrollador del equipo de Chrome. Escribió este artículo hace un par de años llamado The Developer Bait and Switch, donde habló sobre el argumento del hombre de paja de los marcos. Esta idea de que estas herramientas te permiten moverte más rápido y, por eso, puedes iterar más rápido y ofrecer mejores experiencias. Es esta idea de que una mejor experiencia de desarrollador significa una mejor experiencia de usuario. Creo que este es un ejemplo muy claro de cómo ese argumento no siempre se desarrolla de la forma en que la gente cree que lo hace. Es una mejor experiencia para algunas personas, no para todos.

Chris: Los desarrolladores de CSS, las personas que trabajan en sistemas de diseño, su capacidad para crear herramientas que otros pueden usar a veces también se ve limitada por estas opciones de herramientas. En mi experiencia, solía ser mejor en CSS. Ha cambiado mucho en los últimos años y no soy tan bueno como solía ser. En mi experiencia, las personas que son desarrolladores de CSS realmente avanzados... y lo digo en el sentido más verdadero. Las personas que trabajan en CSS son desarrolladores web adecuados que trabajan en un lenguaje de programación. Es algo muy especial, o puede ser algo muy especializado. Las personas que son excepcionalmente buenas en eso, en mi experiencia, no siempre son muy buenas en JavaScript porque terminas sumergiéndote muy profundo en una cosa y te deslizas un poco en otras cosas. Su capacidad para trabajar con estas tecnologías también se ve obstaculizada, lo cual es una lástima porque no solía ser el caso.

Chris: Cuando la pila era más simple, era más fácil para personas de múltiples disciplinas participar en el proceso de desarrollo. Creo que eso va en detrimento tanto de las cosas que construimos como de la comunidad en general, cuando ese ya no es el caso.

Drew: Encontré recientemente en un proyecto que investigaba formas de lidiar con algunos de los problemas de CSS, problemas de flujo de trabajo, tenemos varios trabajos en el proyecto y el tamaño del paquete aumenta y el antiguo CSS nunca se elimina. Era un proyecto de React, por lo que estábamos analizando algunos de estos enfoques de CSS en JavaScript para ver cuál sería mejor para nosotros para resolver los problemas que teníamos. Lo que se hizo evidente rápidamente es que no hay una sola solución para hacer esto. Hay docenas de formas diferentes en las que puedes hacer esto.

Drew: CSS en JS es un enfoque general, pero puede pasar de un proyecto a otro y está completamente influenciado de una manera completamente diferente. Incluso si eres una persona de CSS y aprendes un enfoque particular en un proyecto, esas habilidades pueden no ser transferibles de todos modos. Es muy difícil ver cómo alguien debería invertir demasiado tiempo en aprender eso si no se siente particularmente cómodo con JavaScript.

cris: si La otra cosa interesante que creo que acabas de sacar un poco es cuando hablo de esto, una de las mayores críticas que recibo es que los marcos hacen cumplir las convenciones. Vas con Vanilla JavaScript, tienes este campo verde-cielo azul, puedes hacer cualquier tipo de proyecto que quieras. Con React, hay una forma React de hacer las cosas.

Chris: Pero una de las cosas que he encontrado es que hay enfoques de Reacty, pero no hay una forma estricta y correcta de hacer las cosas con React. Es una de las cosas que a la gente le encanta. Es un poco más flexible, puedes hacer las cosas de diferentes maneras si quieres. Lo mismo con Vue. Puede usar esa cosa basada en HTML donde tiene sus propiedades directamente en el HTML y Vue las reemplaza, pero también puede usar un tipo de sintaxis de plantilla más similar a JSX si lo prefiere.

Chris: Escuché a varias personas quejarse cuando están aprendiendo React, uno de los grandes problemas es que buscas en Google cómo hacer X en React y obtienes una docena de artículos que te dicen una docena de formas diferentes en las que puedes hacer eso. Eso no quiere decir que no pongan algunas barreras en un proyecto. No creo que sea tan claro como, “He elegido un marco. Ahora, esta es la forma en que construyo con él”. Para ser honesto, tampoco sé si eso es necesariamente algo que yo quiera. No creo que quieras que estén muy confinados... algunas personas, tal vez. Pero si está promocionando eso como un beneficio, no creo que sea tan pronunciado como la gente a veces lo cree.

Chris: Te metiste en algo interesante justo ahí, cuando mencionabas el CSS que ya no es necesario. Creo que esa es una de las cosas legítimamente interesantes que algo como CSS y JS... o vincular su CSS a los componentes de JavaScript de alguna manera puede obtener si ese componente se cae, el CSS también, en teoría, desaparece con él. Mucho de esto para mí se siente como arrojar ingeniería a los problemas de las personas. Invariablemente, sigues dependiendo de las personas en algún punto de la línea. Eso no quiere decir que nunca use esos enfoques, pero ciertamente no son la única forma de resolver este problema.

Chris: Hay herramientas que puede usar para auditar su HTML y extraer los estilos que no se usan incluso sin usar CSS y JavaScript. Puede escribir CSS "a la antigua" y aún así eliminar los estilos no utilizados. Existen enfoques de creación de CSS que le brindan un CSS en una salida similar a JS y mantienen su hoja de estilo pequeña sin escupir estos nombres de clase ilegibles humanos incomprensibles que a veces se obtienen con CSS y JS. Como X2354ABC, o simplemente estas palabras sin sentido que se escupen.

Chris: Aquí es donde empiezo a meterme realmente en el tipo de cosas que el viejo le grita a la nube. Realmente estoy mostrando mi edad de desarrollador aquí. Pero sí, no es necesariamente que estas cosas sean malas, y están diseñadas para resolver problemas legítimos. A veces siento que hay un poco de... si es lo suficientemente bueno para Facebook, es lo suficientemente bueno para nosotros, algo que sucede con estos. Bueno, Facebook usa esta herramienta. Si somos un programa de ingeniería real… equipo, departamento, organización, también deberíamos hacerlo. No creo necesariamente que esa sea la forma correcta de pensar en ello. Es porque Facebook se ocupa de problemas que tú no, y viceversa. El tamaño y la escala de lo que trabajan es simplemente diferente, y eso está bien.

Drew: Exacto. Veo que algunas de estas cosas como CSS y JavaScript son casi como un polyfill. Tenemos problemas legítimos, necesitamos una forma de resolverlos. La tecnología aún no nos proporciona una forma de resolverlo. Tal vez mientras esperamos que la plataforma web evolucione y solucionemos ese problema, esto que hacemos ahora con JavaScript nos ayudará y estaremos bien. Sabemos que es malo. Sabemos que no es una gran solución, pero nos ayuda en este momento. Y con suerte, mientras tanto, podemos sacarlo y usar la solución nativa.

Chris: Es muy gracioso que menciones esto. Porque, literalmente, anoche, estaba viendo una charla de Jeremy Keith del año pasado sobre aplicaciones web progresivas. Pero estaba hablando de cómo hace un par de décadas, estaba tratando de convencer a la gente para que usara JavaScript. Lo que parece ridículo en ese momento, pero JavaScript era algo nuevo. Le mostró a la gente cómo se pueden hacer cosas geniales como cambiar el color de un enlace al pasar el mouse con este nuevo... Parece absurdo que necesites JavaScript para eso ahora, porque eso es lo que CSS hace por ti. Pero cosas como el atributo de enfoque o la propiedad simplemente no existían en ese momento.

Chris: Una de las cosas que dijo en la charla que creo que realmente resonó conmigo es que JavaScript, en muchos sentidos, allana el camino de las vacas. Es este lenguaje muy flexible y abierto que podemos usar para crear o agregar funciones que aún no existen. Y luego, eventualmente, los navegadores se ponen al día e implementan estas funciones de una manera más nativa. Pero lleva tiempo. Entiendo completamente lo que dices sobre esto. No es la solución perfecta, pero es lo que tenemos ahora.

Chris: Creo que, para mí, la mayor diferencia entre los polyfills y algunas de estas soluciones es que los polyfills están diseñados para ser arrancados. Si tengo una característica que quiero implementar y que el navegador aún no admite, pero hay algún tipo de especificación y escribo un polyfill... una vez que los navegadores se ponen al día, puedo eliminar ese polyfill y no tengo que hacerlo. Cambia cualquier cosa. Pero cuando sigue el camino de usar algunas de estas herramientas, extraerlas significa volver a escribir toda su base de código. Eso es realmente costoso y problemático. Eso no quiere decir que nunca los use, pero creo firmemente que deberíamos pensar en elegir herramientas que se puedan sacar fácilmente más tarde. Si ya no los necesitamos o la plataforma se pone al día, no se requiere una gran reescritura para sacarlos.

Chris: Para llegar a eso, tenemos un montón de estilos que ya no usamos, es por eso que personalmente preferiría una tecnología de herramientas de compilación que audite su CSS contra el marcado renderizado y extraiga las cosas que no necesita. Porque en el futuro, si una plataforma se pone al día, puede sacar esa pieza de la herramienta de construcción sin tener que cambiar todo. Simplemente aumenta lo que ya tiene, mientras que CSS y JS no le brindan el mismo tipo de beneficio. Solo me estoy refiriendo a eso, pero pienso en muchas de estas tecnologías de manera más amplia.

Chris: Siento que cosas como React o Vue probablemente estén allanando algunos caminos de vaca que los navegadores eventualmente alcanzarán y probablemente usarán enfoques similares, si no los mismos, por lo que puede haber menos reescritura involucrada allí. Muchas de las cosas del ecosistema que se conectan pueden ser menos.

Drew: Creo que es correcto, ¿no es así? Que la plataforma web se mueva lenta y cuidadosamente. Piensas si hace cinco años, todos estábamos poniendo carruseles de JavaScript en nuestras páginas. Estaban por todas partes. Todo el mundo estaba implementando carruseles de JavaScript. Si la plataforma web hubiera saltado e implementado una solución de carrusel para satisfacer esa necesidad, no estaría allí sin que nadie la usara porque la gente ya no hace eso con los carruseles. Porque era solo una moda, una tendencia de diseño. Para contrarrestar eso y evitar que la plataforma se hinche y se convierta en un problema que necesita solución, tiene que moverse a un ritmo mucho más constante. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. ¿Estarías de acuerdo con eso?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Absolutamente. Absolutamente. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: Una de las otras cosas en las que no nos metimos tanto como me hubiera gustado, pero creo que es realmente importante, es que la plataforma se ha puesto al día de una manera muy grande en los últimos años. Adoptar eso tanto como sea posible dará como resultado una experiencia web para las personas que es más rápida, menos frágil, más fácil de construir y mantener porque requiere menos dependencias, como usar lo que el navegador le brinda fuera de -la caja. Solíamos necesitar jQuery para seleccionar cosas como clases. Ahora los navegadores tienen formas nativas de hacerlo. A la gente le gusta JSX porque le permite escribir HTML en JavaScript de una manera más fluida. Pero también tenemos literales de plantilla en Vanilla JavaScript que le brindan el mismo nivel de facilidad sin la dependencia adicional. HTML en sí mismo ahora puede reemplazar muchas cosas que solían requerir JavaScript, lo cual es absolutamente increíble.

Chris: Hablamos un poco sobre... esto es una cosa de CSS, pero se desplaza sobre los enlaces y cómo eso solía requerir JavaScript. Pero al usar cosas como los detalles y los elementos de resumen, puede crear revelaciones, como expandir y contraer o elementos de acordeón de forma nativa sin necesidad de secuencias de comandos. Puede hacer entradas de autocompletar usando solo un... No debería decir solo, odio esa palabra. Pero usando un elemento de entrada humilde y luego un elemento de lista de datos que se asocia con él, con algunas opciones. Si tiene curiosidad acerca de cómo funciona cualquiera de estas cosas en vanillajstoolkit.com, tengo un montón de cosas de JavaScript que la plataforma le brinda. Pero también tengo algunos que solían requerir JavaScript y ahora no hay cosas que también podrían ser interesantes si desea que algunos ejemplos de código lo acompañen.

Chris: En el lado de CSS, mi complemento Vanilla JS más popular es esta biblioteca que te permite animar el desplazamiento hacia abajo para anclar enlaces. Es muy grande. Es la pieza de código más difícil que he tenido que escribir. Y ahora se reemplaza por completo con una sola línea de CSS, el comportamiento de desplazamiento es fluido. Es más eficaz. Es más fácil escribir. Es más fácil modificar su comportamiento. Es solo una mejor solución general.

Chris: Una de las otras cosas que desearía que hiciéramos más es apoyarnos en aplicaciones de varias páginas. Me siento un poco reivindicado aquí, porque recientemente vi un artículo de alguien en Google que también impulsa este enfoque ahora. Pensé que era bastante interesante, dado este gran marco angular y luego... todas las cosas, boom, que Google comenzó hace unos años. Es genial verlos volver a esto. Usando cosas como generadores de sitios estáticos y servicios increíbles como Netlify y el almacenamiento en caché de CDN, puede crear experiencias web increíblemente rápidas para las personas que usan archivos HTML individuales para todas sus diferentes vistas. Así que tipo de apoyarse en algunas de estas cosas listas para usar.

Chris: En situaciones en las que eso no es realista para usted, donde necesita más JavaScript, necesita algún tipo de biblioteca, quizás echando un vistazo a los enfoques más pequeños y modulares primero en lugar de simplemente buscar los gigantes de la industria. En lugar de React, ¿funcionaría Preact? En lugar de angular... quiero decir, en lugar de Vue, ¿funcionaría Alpine JS? También existe este precompilador realmente interesante ahora llamado Svelt, que le brinda una experiencia similar a un marco y luego compila todo su código en Vanilla JavaScript. Entonces obtienes estos paquetes realmente pequeños que tienen justo lo que necesitas y nada más. En lugar de CSS y JavaScript, ¿podría agregar algún filtro de CSS de terceros que compare su HTML con su CSS y extraiga las cosas que quedaron allí por accidente? ¿Funcionaría en su lugar una forma diferente de crear su CSS, como el CSS orientado a objetos de Nicole Sullivan? Realmente no llegamos a hablar de eso, pero es algo realmente genial que la gente debería ver.

Chris: Y luego creo que quizás la tercera y más importante pieza aquí, aunque es menos un enfoque específico y más solo una cosa que deseo que más personas tengan en cuenta, es que la web es para todos. Muchas de las herramientas que usamos hoy funcionan para personas que tienen buenas conexiones a Internet y dispositivos potentes. Pero no funcionan para las personas que usan dispositivos más antiguos, tienen conexiones de Internet irregulares. No se trata solo de personas en áreas en desarrollo. Esto también es gente en el Reino Unido, en ciertas partes de los EE. UU. donde tenemos conexiones a Internet absolutamente pésimas. El medio de nuestro país tiene internet muy lento. Sé que hay lugares en parte de Londres donde no pueden conectar una nueva banda ancha por razones históricas, así que te quedas con estas viejas conexiones a Internet que son realmente malas. Hay lugares así en todo el mundo. La última vez que estuve en Italia, lo mismo. El internet allí era horrible. No sé si ha cambiado desde entonces.

Chris: Las cosas que construimos hoy no siempre funcionan para todos, y eso es una lástima. Porque la visión de la web, lo que me encanta de ella, es que es una plataforma para absolutamente todos.

Drew: Si los oyentes quieren saber más sobre este enfoque, usted lo ha detallado en su libro, The Lean Web. Y eso está disponible en línea. ¿Es un libro físico o un libro digital?

Chris: Es un poco de ambos. Bueno no. Definitivamente no es un libro físico. Vaya a leanweb.dev. Puedes leer todo gratis en línea. También puede, si lo desea, hay versiones EPUB y PDF disponibles por una cantidad muy pequeña de dinero, no recuerdo cuánto ahora. Hace tiempo que no lo miro. Todo es gratis en línea si lo desea. También puede ver una charla sobre este tema donde entro en más detalles si lo desea.

Chris: Pero también he creado una página especial solo para los oyentes de Smashing Podcast en gomakethings.com/smashingpodcast, porque soy muy creativo al nombrar las cosas. Eso incluye un montón de recursos además del libro, sobre cosas de las que hablamos hoy. Se vincula a muchas de las diferentes técnicas que cubrimos, otros artículos que he escrito que profundizan en algunos de estos temas y amplían un poco mi pensamiento. Si la gente quiere aprender más, ese sería probablemente el mejor lugar para comenzar.

Drew: Eso es fantástico. Gracias. He estado aprendiendo todo sobre Lean Web. ¿Qué has estado aprendiendo últimamente, Chris?

Chris: Sí, un par de cosas. Mencioné esto un poco antes al ver el video de Jeremy sobre aplicaciones web progresivas. He pospuesto aprender a escribir mi propia aplicación web progresiva durante un par de años porque no tenía una necesidad específica en nada con lo que estaba trabajando. Recientemente me enteré por uno de mis estudiantes que está en Sudáfrica, que han estado lidiando con apagones continuos debido a algunas cosas que están sucediendo allí. Como resultado, no puede trabajar en algunos de los proyectos que hemos estado haciendo juntos con regularidad, porque se va la luz y no puede acceder al portal de aprendizaje y seguir adelante.

Chris: Para mí, ahora crear una experiencia en la que funcione incluso si alguien no tiene Internet se ha convertido en una prioridad más alta que... las próximas semanas. Ya veremos. Sin embargo, los recursos de Jeremy Keith en esto han sido un salvavidas absoluto. Me alegro de que existan.

Chris: Lo sé, Drew, mencionaste que una de las razones por las que te gusta hacer esta pregunta es para mostrar que las personas, sin importar cuán experimentadas sean, siempre están aprendiendo. Una pequeña anécdota relacionada. Creo que he sido desarrollador web durante unos ocho años. Todavía tengo que buscar en Google la propiedad CSS para poner las cosas en cursiva, literalmente, cada vez que la uso. Por alguna razón, mi cerebro utiliza por defecto la decoración de texto aunque no sea la correcta. Probaré un par de combinaciones de cosas diferentes, y siempre me equivoco en una palabra cada vez. A veces también escribo cursiva en lugar de cursiva. Si. Si alguien alguna vez se siente como, oh, nunca voy a aprender estas cosas... solo debes saber que no importa cuán experimentado seas, siempre hay algo realmente básico que buscas en Google una y otra vez.

Drew: He sido desarrollador web durante 22, 23 años, y todavía tengo que buscar en Google las diferentes propiedades de Flexbox, cada vez. Aunque lo he estado usando durante 23 años. Pero sí, algunas cosas simplemente... probablemente habrá más de esas a medida que envejezca.

cris: si Honestamente, terminé construyendo un sitio web completo de cosas que busqué en Google una y otra vez, solo para tener una referencia más fácil de copiar y pegar porque era más fácil que buscar en Google.

Drew: Esa no es una mala idea.

Chris: Ese es el tipo de perezoso que soy. Construiré un sitio web completo para ahorrarme tres segundos de búsqueda en Google.

Drew: Si a usted, el oyente, le gustaría saber más de Chris, puede encontrar su libro en la web en leanweb.dev, y su boletín de consejos para desarrolladores y más en gomakethings.com. Chris está en Twitter en Chris Ferdinandi. Y puede ver su podcast en vanillajspodcast.com o donde sea que obtenga sus podcasts. Gracias por acompañarnos hoy, Chris. ¿Tienes alguna palabra de despedida?

Chris: No. Muchas gracias por recibirme, Drew. Me lo pasé absolutamente genial. Esto fue muy divertido. Realmente aprecio la oportunidad de venir a charlar.