Smashing Podcast Episodio 32: Revisión del año 2020

En este episodio, echamos un vistazo al 2020. ¿Con quién hablamos en nuestros episodios de este año y qué aprendimos? Escuchemos algunos clips para averiguarlo.

Mostrar notas

Puede encontrar todos nuestros episodios anteriores, incluida una transcripción completa de cada entrevista en podcast.smashingmagazine.com.

¡Nos vemos en 2021, todos!

Transcripción

Drew McLellan: En enero, hablé con Amy Hupe sobre su trabajo en el sistema de diseño del gobierno del Reino Unido y, en particular, cómo el equipo aumentó la adopción del sistema por parte de la organización en general al alentar las contribuciones. Aquí está Amy.

Amy Hupe: Empezamos muy temprano. Entonces, mucho antes de que tuviéramos una especie de sistema de diseño público, comenzamos a involucrarnos con personas que pensamos que estarían interesadas en contribuir. Debo mencionar aquí que teníamos un brillante diseñador de servicios en el equipo. Se unió a nosotros en... No voy a corregir las fechas de ninguna manera en este momento, pero creo que trabajó con nosotros durante todo el 2018, y su nombre es Ignacia. Ella simplemente hizo un trabajo fantástico dando vueltas e involucrando a la gente. Así que una de las cosas que hizo fue ir e identificar todos los diferentes patrones de gobierno y todos los diferentes tipos de variaciones de esos patrones. Así que salir y decir: “Está bien. Hay 10 formas diferentes de solicitar una dirección en el gobierno. Veámoslos todos juntos y decidamos cuál creemos que es el enfoque más apropiado. ¿Cómo podemos consolidarlos en uno solo?”.

Amy Hupe: Dirigió un gran taller para tratar de que la gente los mirara y hiciera ese tipo de consolidación como equipo. Creo que definitivamente su enfoque para construir una colaboración mucho antes de que lanzáramos algo al público realmente ayudó con eso porque significaba que las personas ya tenían ese tipo de conciencia al respecto, y muchas personas ya habían contribuido de alguna manera. otro antes de que lo hiciéramos público. Así que estábamos un poco pasados ​​unos pasos por delante. Así que creo que fue realmente importante y solo persistencia, mucha persistencia de todo el equipo para ayudar a las personas a contribuir.

Amy Hupe: Creo que existe la idea de que si haces que la gente contribuya a un sistema de diseño, es un trabajo muy bueno, porque puedes hacer que la gente haga todo el trabajo por ti, y simplemente te sientas ahí, y haga sus pequeñas correcciones de código, y todo el mundo le dará todas las cosas buenas. Pero en realidad, como sabrá cualquiera que haya trabajado en un sistema de diseño, es increíblemente complejo. Es muy difícil hacer una solución centralizada que funcione para múltiples equipos diferentes.

Amy Hupe: En realidad, a menos que haya trabajado en un sistema de diseño, no es razonable esperar que nadie entienda realmente lo que se requiere. Así que hay mucho tipo de agarre de manos. Hay mucho trabajo involucrado en apoyar a los contribuyentes para que contribuyan. Creo que he dicho esto antes, pero creo que probablemente lleve más tiempo ayudar a alguien a contribuir a un sistema de diseño que simplemente hacerlo uno mismo y el equipo centralizado. Pero creo que reconocer el valor que aporta y ser persistente en sus esfuerzos para que las personas tomen conciencia de la contribución, ayudarlos a hacerlo, ayudarlos a sentirse motivados para hacerlo, creo que sí, esa persistencia fue realmente tan clave para nuestro éxito en esa área.

Drew: Nos acompañaron Stephanie Stimac y Aaron Gustafson de Microsoft para hablar sobre la adopción de Edge de Chromium como su motor de renderizado. Le pregunté a Aaron sobre el panorama competitivo entre los navegadores y dónde los múltiples navegadores que se fusionan en el mismo motor de renderizado acabarían con esa sana competencia y, por lo tanto, serían malos para la web abierta.

Aaron Gustafson: Esto es algo con lo que definitivamente he sido un experto en estándares web durante mucho tiempo. Entiendo totalmente la justificación comercial para ello. Desde el punto de vista de Microsoft, tenía mucho sentido. Desde la perspectiva de un desarrollador front-end, es bueno no tener que atender a un montón de motores diferentes. Quiero decir, en general, aquellos de nosotros que hemos estado trabajando en la web durante mucho tiempo sin duda hemos visto mucha convergencia en términos de representación. No tenemos tantos problemas como los que tuvimos, digamos en Netscape durante siete días, donde tuvimos como... Conocía compañías que estaban creando hojas de estilo únicas para cada navegador diferente, lo cual era simplemente insostenible.

Aaron Gustafson: Pero creo que lo que es un poco diferente ahora es que en la guerra de los navegadores originales, tenías todos estos motores patentados, y todos estaban como en un juego de superioridad en términos de tratar de enviar nuevas funciones de plataforma y nuevas funciones de JavaScript o, en el caso de JavaScript de ingeniería inversa de Microsoft, para crear JScript y tratar de descubrir cómo encajar todo junto.

Aaron Gustafson: Pero ahora tenemos la capacidad de trabajar juntos en proyectos de código abierto y aún tenemos el diálogo y aún... no sé. Luchar no es la palabra correcta, pero tener discusiones serias sobre el impacto de diferentes enfoques y estar en desacuerdo entre sí y trabajar realmente para hacer que las especificaciones sean realmente buenas y también tener enfoques competitivos para el código subyacente dentro del contexto de, digamos, un Chromium proyecto o WebKit o algo de esa naturaleza o Missoula en el espacio de Firefox.

Aaron Gustafson: Así que sí. Por un lado, perdimos otro motor de renderizado y sentí el mismo dolor cuando Opera decidió ir a Chromium. Pero me siento un poco alentado por estar dentro de Microsoft y ver lo comprometidos que estamos para participar en el proyecto Chromium de una manera significativa y no solo sentarnos y aceptar todo lo que viene de Chromium, sino realmente investigar lo que está pasando. la plataforma y participar en eso... Sí.

Aaron Gustafson: Eso me alienta un poco y siento que no solo estamos ahí para tomar de ese proyecto y aceptar lo que sea que transmitan todas las diferentes personas que tienen interés en ese proyecto, sino para estar colaborando allí también.

Drew: En febrero, hablé con Stephanie Walter sobre trabajar con marcos de interfaz de usuario como Bootstrap y sus amigos y equilibrarlo con las necesidades personalizadas de una interfaz utilizable. Le pregunté a Stephanie si era posible crear una interfaz de usuario altamente usable mientras usaba un marco listo para usar o si siempre iba a ser un compromiso un poco incómodo.

Estefanía Walter: Sí. Creo que es. Pero también depende del nivel de compromiso que esté dispuesto a hacer, y esto compromete a ambos lados. Por el momento, estoy comprometiendo muchos botones, por ejemplo, porque tienes algunos botones muy específicos en una interfaz de usuario material. Realmente no me gusta el efecto dominó en el botón. Creo que funciona muy bien en los dispositivos móviles porque en los dispositivos móviles se necesita una gran retroalimentación cuando el usuario hace clic o toca el botón. Pero luego pasan este tipo de efecto dominó que llega hasta el botón. Es un poco exagerado, especialmente cuando hay muchos botones. Pero aún vamos a mantener este efecto dominó porque sería súper complejo eliminarlo porque estaba integrado en el marco de React y para tener otro efecto de desplazamiento sobre este botón, algo más sutil que no sería tan tupido. aquí. Sería súper complejo. Así que este es el tipo de compromisos que haces.

Drew: El diseño ético fue el tema de mi conversación con Trina Felber y Martin Michael Fredrickson. Pregunté si adoptar un enfoque ético para el diseño y evitar patrones oscuros era pensar a largo plazo sobre la salud y el crecimiento de un negocio en lugar de solo los objetivos de ventas a corto plazo. Aquí está Martín.

Martin Michael Fredrickson: Eso es perfectamente cierto. Creo que tienes que mirar el negocio que haces en línea como si tuvieras una tienda en la calle principal de una ciudad mediana, donde tienes que mantener intacta tu reputación. Si no trata bien a sus clientes, entonces si no trata bien a sus clientes, a largo plazo, se quedará sin negocio porque la gente irá a otra tienda o comprará en línea. Entonces, hagas lo que hagas en línea, realmente tienes que pensar que hay un efecto a largo plazo, y también, hay un costo oculto al hacer cosas que son complejas o cosas que manipulan. Si ordena, como dice Trina, habrá un ahorro a largo plazo, y eso nunca se calcula cuando se habla de modelo de negocio. Siempre hablas de cuánto dinero puedes ganar. Nunca hablas del costo de ganar esa cantidad de dinero.

Drew: En marzo, hablé con Eduardo Boucas sobre una herramienta de código abierto llamada Sourcebit que recopila contenido de fuentes dispares y lo pone a disposición de su generador de sitios estáticos. Le pregunté a Eduardo si esto podría mejorar la experiencia del usuario de autorizar un SSG al permitir la integración con herramientas como los CMS sin cabeza.

Eduardo Boucas: Exactamente. Si. La forma en que podría... Veo dos formas diferentes de usar la herramienta que puede ayudar a los desarrolladores. Uno es hacer que Sourcebit forme parte de su rutina de implementación. Entonces, si está utilizando una plataforma de alojamiento, como Netlify, por ejemplo, y configura sus comandos de implementación para que sean, no sé, compilación de Hugo, el comando de compilación para Hugo o algo así, el tipo de comando que genera los archivos estáticos para Hugo. También tendría otro comando como parte de esa rutina. Eso sería algo así como Sourcebit fetch. Entonces, en el momento de la compilación, Sourcebit extraerá todos los demás datos, generará todos los archivos que necesita Hugo y luego toda la implementación ya usará esos archivos e implementará todo el contenido que proviene del CMS.

Eduardo Boucas: Ese es un posible caso de uso para Sourcebit. El otro es usar Sourcebit como un desarrollo local en el flujo de trabajo de desarrollo local. Entonces puede ejecutar Sourcebit con algo que llamamos el modo de reloj. Entonces Sourcebit sigue buscando cambios en la fuente de datos remota, en este caso, el CMS sin cabeza. Entonces, cada vez que publique un artículo o cambie una entrada en CMS, Sourcebit lo reconocerá y regenerará todos los archivos localmente.

Eduardo Boucas: Entonces, lo que eso significa para el desarrollador que trabaja localmente es que puede tener su ventana CMS junto a su sitio de Hugo ejecutándose localmente, y luego puede ver los cambios que ocurren en tiempo real. Cambias algo en el CMS y luego puedes ver ese cambio reflejado en el sitio local, lo que me parece muy útil. Entonces, esas son las dos formas en que podría usar Sourcebit.

Drew: La optimización de conversiones fue el tema del día. Cuando hablé con el veterano podcaster y consultor, Paul Boag. Hablamos sobre algunas de las técnicas que utilizan los sitios para convertir a los visitantes en clientes. Pero quería preguntarle a Paul cómo mide el impacto de los cambios que realiza. Pablo explicó.

Pablo Boag: Sí. Absolutamente. Creo, de nuevo, que esto es algo en lo que muchas organizaciones son bastante deficientes: tener claro cómo van a medir el éxito. Ahora, sí, su tasa de conversión es una métrica. Absolutamente deberías estar siguiendo. Pero incluso con la conversión, debe ser un poco más sofisticado que la cantidad de personas que compran. También debe prestar atención al valor promedio del pedido. Debe prestar especial atención al valor de por vida, ¿verdad? Entonces, cuánto vale un cliente durante toda su vida, porque es posible que descubra que está obteniendo una rotación bastante alta de clientes, si usa patrones oscuros y cosas por el estilo. Pero en realidad, la conversión debería ser solo una de las métricas que está midiendo.

Paul Boag: También hay cosas como que debes prestar atención al compromiso, qué tan comprometidas están las personas con tu contenido, porque eso hace una gran diferencia en si finalmente se convierten. Entonces, está viendo cosas como, ¿cuánto cuestan sus videos, lo ven, cuánto tiempo pasan en su sitio y qué miran mientras lo hacen? ¿Están participando en las redes sociales y ese tipo de cosas? Luego, el aspecto final es, obviamente, la usabilidad. Debe medir qué tan rápido alguien puede completar una tarea en particular en su sitio web y qué tan fácil encuentran que el sistema lo use y varios otros criterios diferentes.

Paul Boag: Hay un montón de mecanismos que puedes usar para medir esas cosas diferentes. Existen excelentes herramientas y también algunas buenas métricas que puede adoptar. Entonces, por ejemplo, con la usabilidad, hay algo llamado la escala de usabilidad del sistema que puede ser una métrica muy útil para medir. Pero igualmente, hay herramientas como maze.design es una que uso a menudo, que medirá cuánto tiempo le toma a alguien hacer una compra, por ejemplo, pasar por caja. Así que sí. Con ese tipo de amplia gama de métricas, no solo se está enfocando en cuántas ventas hicimos este trimestre. Tienes que mirar el panorama general.

Drew: En abril, conversé con Laura Kalbag de Better Blocker sobre la privacidad en línea. Hablamos sobre las fronteras cada vez más estrechas entre lo que se considera público y lo que es privado y cómo las empresas a las que confiamos nuestros datos podrían no ver las cosas que consideramos privadas de esa manera. Aquí está Laura.

Laura Kalbag: Tengo un ejemplo clásico de esto que me pasó hace unos años. Así que estaba en Facebook, mi madre acababa de morir y estaba recibiendo anuncios de directores de funerarias. Pensé que era realmente extraño porque ninguno de mi familia había dicho nada en una plataforma de redes sociales en ese momento. Ninguno de mi familia había dicho nada en Facebook porque habíamos acordado que nadie quiere saber ese tipo de cosas sobre un amigo o familiar a través de Facebook. Así que no habíamos dicho nada al respecto.

Laura Kalbag: Así que les pregunté a mis hermanos: "Oh, ¿alguno de ellos ha dicho algo en Facebook que pueda causar esto extraño?" Porque por lo general solo recibo anuncios de maquillaje, vestidos, pruebas de embarazo y todas esas cosas divertidas de las que les gusta hablar. Son mujeres de cierta edad. En cambio, mi hermana me respondió. Ella dijo: “Bueno, sí. Mi amigo vive en Australia”. Así que le envié un mensaje por Facebook Messenger y le dije que nuestra mamá había muerto. Por supuesto, Facebook sabía que somos hermanas. Tiene esa conexión de relación que puede elegir agregar allí. Quiero decir, probablemente podría adivinar que éramos hermanas de todos modos, por los lugares en los que hemos estado juntas, el hecho de que compartimos un apellido y decidimos: "Oh, ese es un anuncio apropiado para poner en sus pies".

Drew: Es aleccionador, ¿no es así, pensar que la tecnología está tomando estas decisiones por nosotros, que en realidad afecta potencialmente a las personas en este ejemplo en un momento bastante sensible o vulnerable?

Laura Kalbag: Sí. Decimos que es espeluznante. Muchas veces la gente dice: "Oh, es casi como si el micrófono de mi teléfono o mi computadora portátil me estuviera escuchando porque estaba teniendo esta conversación sobre este producto en particular, y de repente aparece en mi feed en todas partes". Creo que lo que realmente da miedo es el hecho de que la mayoría de ellos no tienen acceso a tu micrófono. Pero es el hecho de que sus otros comportamientos, su búsqueda, el hecho de que sabe con quién está hablando debido a su proximidad entre sí y su ubicación en sus dispositivos. Puede conectar todas esas cosas que quizás no conectemos nosotros mismos para decir: "Oh, tal vez estén interesados ​​​​en este producto porque probablemente ya estaban pensando, hablando de eso".

Drew: A medida que golpeó la pandemia de coronavirus y muchas naciones entraron en algún tipo de bloqueo, hablé con Rachel Andrew sobre cómo Smashing estaba adaptando su conferencia en persona programada para realizarse en línea. Habiendo tenido que posponer la conferencia Smashing, San Francisco, le pregunté a Rachel cuál era el plan para trasladar las próximas conferencias y talleres al dominio virtual.

Rachel An Drew: Muy, muy rápidamente, una vez que nos dimos cuenta de que íbamos a tener que posponer San Francisco, obviamente, tenemos talleres, tanto yo como Vitaly realizamos talleres en smash and comp, y se agotaron en San Francisco, ambos nuestros talleres. Obviamente, tenemos muchas otras personas que vienen y organizan talleres para nosotros, personas con las que hemos trabajado durante mucho tiempo, y descubrieron que todos sus talleres, y para aquellos de nosotros que hacemos talleres, en realidad tienen una parte clave de nuestros ingresos.

Rachel An Drew: Hablar en público, normalmente no ganas mucho dinero yendo y hablando en público. A la mayoría de las personas no se les paga mucho, no cuando consideras la cantidad de tiempo que lleva escribir charlas y demás. Los talleres tienden a ser una forma bastante agradable para que las personas que son buenas enseñando estas cosas ganen algo de dinero. Así que representan los ingresos de las personas. Así que no solo me necesitaba a mí y a Vitaly habíamos perdido nuestros talleres a principios de este año. También nos dimos cuenta de que muchos de nuestros oradores de Smashing también dependían de esos talleres.

Rachel An Drew: Así que pensamos: "Bueno, ¿por qué no ponerlos en línea?" Muy, muy rápido, realmente a los pocos días de que eso sucediera, decidimos que Vitaly y yo seríamos los primeros en asomar la cabeza por el poder, pero dado que somos nosotros, y podríamos descubrir cómo hacerlo. También tenemos talleres muy diferentes. Vitaly es mucho más colaborativo. Tiene actividades de grupo y cosas. Enseño estilo de salón de clases. Entonces, entre nosotros, pensamos: "Bueno, estamos cubriendo todas las bases". Así que pensamos: “Hagámoslo. Veamos si funciona”. Así que los publicitamos. Averiguamos cuánto tiempo tomó cada uno, y luego nos sentamos y dijimos: “Bueno, ¿cómo es realmente un taller en línea? ¿Qué es esto?"

Drew: Creo que desde una perspectiva técnica como desarrolladores web que inmediatamente piensan, ¿cómo diablos vamos a ofrecer algo así? Quiero decir, debe haber muchas plataformas diferentes que viste. ¿Cuáles fueron las diferentes cosas que miraste y lo que eventualmente trajo Smashing?

Rachel An Drew: Así que hemos echado un vistazo a todo tipo de cosas, y todavía estamos en el proceso de hacerlo. Estamos usando Zoom en este momento. La razón por la que usamos Zoom es la accesibilidad. Era la más accesible de las plataformas. Obviamente, no queremos eliminar a la gente por la plataforma que hemos elegido. Creo que las otras plataformas están mejorando y la gente está… Creo que muchas plataformas han tenido gente que se acerca a ellas y les dice: “Sí, te ves genial. Pero necesitamos que seas accesible”. Por lo tanto, Zoom es lo más fácil de usar para las personas en este momento”. Así que es por eso que hemos terminado usándolos. No sé si lo haremos para siempre. Pero eso es lo que estamos usando en este momento, y ha funcionado bastante bien como una forma de hacer estas cosas.

Drew: A medida que comenzó la fatiga de Zoom y el mundo comenzó a adaptarse a lo que rápidamente se llamó la nueva normalidad, hablé con Phil Smith sobre cómo la tecnología puede ayudarnos a responder a situaciones como COVID-19. Creación de la aplicación React Native, CardMedic en solo 10 días. Le pregunté a Phil cómo equilibra la elección de la mejor tecnología para el trabajo frente a las tecnologías con las que está familiarizado y en las que puede trabajar rápidamente.

Phil Smith: Esa es una buena pregunta. Creo que tan pronto como me mencionaron el proyecto, pensé que sabía exactamente cómo iba a construir todo esto. Si no hubiera tenido hijos y me hubiera sentado en una habitación oscura, creo que probablemente podría haber cambiado todo en unos cinco días si hubiera estado trabajando en ello de manera sólida, sólida, sólida porque los requisitos eran muy estrictos. en línea con mi experiencia en la creación de aplicaciones. He creado un tipo de cosas similares, donde llama a una API, almacena los resultados en estado y los presenta. Ahora estoy en una posición en la que hay algunos fragmentos en los que digo: "Está bien, necesito volver atrás y refactorizar eso".

Phil Smith: He hablado sobre escribir tin, pero en realidad los tipos pueden estar bastante sueltos en la aplicación, y eso debe ajustarse. En el back-end, no hay muchas pruebas y ahora estamos comenzando a implementarlo porque muchas personas se han presentado y han dicho: “En realidad, este es un gran recurso. Me gustaría ofrecer mis servicios como voluntario para traducir esto a mi idioma nativo”. La parte trasera está siendo utilizada por más personas, así que solo estoy pensando: "Espera, necesito algunas pruebas más aquí para asegurarme de que nada pueda romperse porque ahora hay personas que usan esto en producción". Creo que respondí tu pregunta. Esencialmente, no hubo toma de decisiones. Solo tenía que sacarlo lo más rápido posible.

Drew: A medida que los lugares de trabajo cerraron y muchos de nosotros nos adaptamos a trabajar en casa, hablé con Ben Frain acerca de optimizar el espacio de trabajo de su hogar para que sea un lugar cómodo y productivo que no generará problemas de salud física a largo plazo. Con presupuestos limitados disponibles para la instalación en casa, le pregunté a Ben si una buena silla era el mejor lugar para comenzar.

Ben Frain: Ese sería mi consejo. Si. Quiero decir, no puedo pretender ser una autoridad en estas cosas, pero parece que es probablemente lo más importante que podrías hacer para sentirte cómodo durante el día. Puedes empezar con algo bastante caro. Cometí el mismo error, y terminé comprando una silla de oficina de 45 libras de Amazon, y no me di cuenta de que no tenía una inclinación hacia adelante, cualquiera que sea la palabra correcta para eso, en el eje. Entonces, lo que encontré es que se estaba clavando en la parte inferior de mis muslos, más o menos detrás de mis rodillas, y estaba pensando: "¿Por qué mis piernas se están muriendo después de 45 minutos de estar sentado en esa cosa?"

Ben Frain: Creo que si trabajas para una empresa que ofrece sillas de oficina decentes, simplemente las das por sentadas, y no es hasta que miras esa marca y marca en particular que dices: "Oh, Dios mío, esto es una silla de $ 700 ". Cuando te das cuenta de ese crikey, la gente ha pensado en esto y ha hecho mucho por ti, y luego, obviamente, llegas a tu hogar y piensas: "¿Por qué no gastar X cien dólares en una silla?" Pero tal vez valga la pena. Particularmente si estás aquí por mucho tiempo.

Drew: Y el largo plazo es lo que tenemos. Otra cosa que está disponible a largo plazo es Drupal. En junio, hablé con Angie Byron sobre los cambios en Drupal 9. 20 años desde su primer lanzamiento, Drupal ha recorrido un largo camino. Le pregunté a Angie cómo era el proceso de actualizar un sitio de Drupal existente cuando se cambiaba a Drupal 9 y si era probable que fuera una gran carga para aquellos con sitios de larga duración.

Angie Byron: Creo que básicamente hay tres escenarios. Entonces, una es si estuviera ejecutando Drupal 8, y cada vez que saliera una nueva versión menor de Drupal 8, la actualizaría de inmediato y comenzaría a utilizar las cosas nuevas. Tu camino va a ser básicamente nada. Ya has estado haciendo todo el trabajo y estás bien. Si se mudó a Drupal 8 hace un tiempo y no se ha mantenido al día con los cambios de BC, hay un poco de trabajo para usted.

Angie Byron: Definitivamente es la actualización más fácil en más de una década de nuestro software de todos modos, y tenemos un montón de herramientas diferentes para ayudarlo. Hay un tablero que muestra todos los módulos contribuidos y cuál es su situación en Drupal 9. Hay herramientas automatizadas para revisar y verificar su código y marcar cualquier función obsoleta que tenga, y hay herramientas para subir automáticamente y encontrar, "Oh, esta es la última versión de su módulo, ¿y está listo para Drupal 9? Deberías ir a descargarlo”, ese tipo de cosas.

Angie Byron: De Drupal 8 a 9, diría que esa parte está bastante bien cubierta. Si viene de una versión anterior de Drupal, digamos Drupal 7 o anterior a Drupal 9, eso comienza a parecer un poco más complicado. Entre los cambios que hicimos en Drupal 8, donde, por ejemplo, pasamos completamente a PHP orientado a objetos, y comenzamos a utilizar patrones de diseño que se encontraron en otros proyectos de software, lo cual es algo muy inteligente para hacer arquitectónicamente, pero lo hace. significa que si tenía un montón de código personalizado en su vida anterior, que en Drupal 9, necesitará encontrar alternativas para eso.

Angie Byron: Entonces, Acquia es un producto y desarrollo llamado Acquia Migration Accelerator que tiene como objetivo resolver ese problema, donde estamos creando una buena aplicación definida por React, que lee sus datos antiguos de Drupal 7, crea datos equivalentes de Drupal 8 para usted. junto con todos los módulos que va a necesitar que se asignen a sus antiguos módulos de Drupal 7 donde sea posible para tratar de acelerar ese proceso un poco porque queremos asegurarnos de que todos los que tienen versiones anteriores puedan volver a la nuevo orden mundial, donde todos están en la misma versión, y todos estamos trabajando juntos.

Angie Byron: Además, también hemos ampliado Drupal 7... La comunidad de código abierto de Drupal, su fin de vida en Drupal 7 a partir de noviembre del próximo año. Actualmente, de todos modos, debemos discutir si COVID afecta eso o no. Pero hay varias compañías diferentes, y Acquia es una de ellas que ofrece soporte extendido para Drupal 7 más allá de eso, al menos hasta 2024. Eso hace que las personas que tienen una actualización fácil tengan un año y medio para hacerlo, las personas tienen una actualización menos fácil, tienen potencialmente tres años y medio para hacerlo o más si es necesario, y nos estamos esforzando mucho para que todos puedan mudarse y luego crear herramientas como Acquia Migrate Accelerator para ayudar a acelerar el proceso.

Drew: Learning React fue el tema de una conversación con Mina Markham. Mina y yo habíamos estado en posición de aprender React por primera vez. Reflexionando sobre la carga que los frameworks como React suponen para el navegador, le pregunté a Mina si poner tanto control en manos del cliente era un error.

Mina Markham: Quiero decir que sí con la advertencia de que, una vez más, mi experiencia se limita en gran medida a sitios web en su mayoría estáticos. No hago mucho desarrollo de productos. Así que tal vez en ese ámbito, esto tiene más sentido. Pero desde mi perspectiva, siento que muchas veces estamos usando un hacha cuando solo necesitamos un cuchillo de mantequilla. No sé por qué necesitamos poner todo esto en el navegador, poner tanto trabajo y tanta presión sobre el cliente cuando podemos hacer muchas cosas... Siento que podríamos hacer esto mucho más simple. Una de las cosas que siempre me hizo dudar un poco en usar React, o digo vacilante, pero a lo que me refiero cuando me hizo enojar visceralmente y me opuse activamente fue cuando iba a un sitio web, y literalmente nada se procesaba porque hubo un error o algo como realmente toda la página está rota porque una función se rompió.

Mina Markham: Simplemente me molestó que muchas veces fuera un enfoque de todo o nada. Una de las charlas que di en AEA en el pasado y en otros lugares en el pasado fue sobre cómo incluir mejoras progresivas y no solo tu desarrollo, sino también una dirección de arte más grande y diseño de sitios. Señalaría específicamente ejemplos de sitios web que no realizaron mejoras progresivas ni ningún tipo de degradación elegante. O tenías el JavaScript ejecutándose en el navegador, o no obtenías absolutamente nada. Sería solo un sitio simple que representaría información sobre la historia del diseño web, que fue uno de los sitios de los que realmente se habló, la historia del diseño web desde 1990 hasta ahora. Era un sitio web hermoso con muchas líneas de tiempo, animación de cosas. Pero también podría haberse renderizado estáticamente con solo una lista. Hubo pasos intermedios entre no mostrar nada y mostrar esa experiencia bellamente mejorada que creo que se perdió debido a la forma en que nos hemos acercado al desarrollo web moderno ahora.

Drew: Hablé con Andy Bell sobre CUBE CSS, una metodología de estilo a la manera de BEM, SMACSS y OOCSS. Muchos enfoques de CSS intentan trabajar en contra de las propiedades naturales de CSS como la cascada. CUBE acepta mucho ese comportamiento. Aquí está Andy.

Andy Bell: Un buen tipo de analogía es que SCSS, como Sass, es una extensión del lenguaje CSS natural, ¿no es así? Todavía tienes bastante razón en CSS. Entonces CUBE CSS es así. Así que es una extensión de CSS. Así que todavía deberíamos escribir CSS, ya que CSS debería... bueno, se supone que debe escribirse. Seamos honestos, así es como se supone que debe escribirse. El nombre lo delata, hojas de estilo en cascada. Así que está aceptando eso nuevamente porque lo que descubrí es que bajé hasta el nivel de microoptimización. He estado en el camino en el que veo a muchas personas pasar recientemente donde... También mencioné esto en el artículo, donde puedo ver... Hay algunas pruebas de ello recientemente. He visto que la gente ha estado creando componentes espaciadores y cosas por el estilo, y entiendo ese problema. He estado en esa situación.

Andy Bell: La forma en que lo arreglé fue que, en lugar de profundizar e intentar microoptimizar, en realidad comencé a pensar en las cosas a nivel de composición porque no importa cuán pequeños sean los componentes. En algún momento van a ser páginas. Van a ser vistas. No puedes evitar eso. Así es como va a ser. Entonces, en lugar de tratar de decir: "Bien, necesito estos pequeños ayudantes para hacer este diseño", dice: "Bien, tengo una vista de página de contacto o una vista de página de producto, y esa es una composición de diseño esquemática. Luego, dentro de eso, puedo insertar los componentes que quiera allí”.

Andy Bell: Ahora tenemos cosas como Grid y Flexbox que hacen que eso sea mucho más factible, y básicamente puedes poner lo que quieras dentro del diseño esquelético. No importa. Luego, los componentes deberían, en ese punto, comportarse como usted quiere que se comporten, con o sin consultas de contenedor.

Drew: Gatsby fue el tema de mi conversación con Marcy Sutton. Si bien la mayoría de los generadores de sitios estáticos son independientes del código front-end, Gatsby usa React y, por lo tanto, termina con el código de Gatsby ejecutándose como parte de su experiencia web final. Le pregunté a Marcy cuál era ese código y qué funcionalidad proporcionaba.

Marcy Sutton: Sí. Diría que la mayor parte de eso es el enrutamiento del lado del cliente. Así que Gatsby en este momento está usando recauchutado debajo del capó. Es solo una especie de su propia implementación. Pero esa es la pieza que cuando carga su sitio estático por primera vez, hay archivos HTML allí. Entonces, si el usuario desactiva JavaScript por alguna razón, su sitio aún debería estar allí, aún debe tener contenido. Pero si JavaScript está habilitado, es cuando ocurre este paso de hidratación, donde cuando usa enlaces en su sitio de Gatsby, obtendrá recursos de esa página. Así se cargará más rápido. Así que todo eso está habilitado con esta capa de JavaScript que te da Gatsby.

Marcy Sutton: Más allá de eso, realmente depende de lo que estés usando en tu sitio, lo que terminará en ese paquete de JavaScript. Pero para cosas que usan mucha interactividad, como interfaces accesibles, ese es un buen lugar para estar. Para mí, realmente disfruto tener JavaScript disponible en todo momento y tener mi marcado en un buen lugar. Sé que es una cuestión de preferencia, ya sea que desee que su HTML, su JavaScript y su CSS estén perfectamente acoplados, y hay espacio para variaciones dentro de la construcción de Gatsby. No siempre tienes que usar algo como CSS y JS. Pero en realidad se trata de obtener el poder de esa capa dinámica de JavaScript disponible mientras escribe su sitio web. No es como este complemento en un archivo separado.

Drew: Cuando pienso en cómo funciona normalmente un generador de sitios estáticos, estoy pensando en el contenido de quizás archivos Markdown y el generador se ejecuta en ese contenido y lo fusiona con plantillas y crea decenas, cientos, miles de archivos HTML, que son los páginas de su sitio web. Cuando pienso en un sitio o una aplicación de React, pienso más en la experiencia de una sola página, donde React crea las interfaces sobre la marcha. ¿Estás diciendo que Gatsby hace ambas cosas? ¿Está creando todas las páginas y también mejorándolas con JavaScript?

Marcy Sutton: Lo es, sí. Gatsby usará Node.js en el momento de la compilación, revisará sus componentes de React y los compilará en archivos HTML, que, sinceramente, la primera vez que miré a Gatsby, no desactivé JavaScript y dije: "Está bien, ¿Hay otras páginas aquí? ¿Qué es esto?" Estaba tan feliz de que Gatsby funcione de esa manera por defecto. Creará archivos integrados a partir de sus componentes React, lo cual es increíble.

Marcy Sutton: He explorado más enfoques de mejora progresiva ya que está en JavaScript, como, ¿qué sucede si desea generar algo mejorado progresivamente para los usuarios, donde si tienen JavaScript desactivado, no desea todo este código roto que asume JavaScript? esta ahí. Así que hay algunas peculiaridades con él. Pero puede evitar ese tipo de cosas, al menos para sus flujos de usuarios principales en los que desea que alguien aún pueda comprar algo. Es posible que deba agregar algo de soporte y para esos casos de uso. Pero me ha sorprendido gratamente la forma en que Gatsby lo implementa de forma predeterminada.

Marcy Sutton: Así que es una elección que hicieron para construir sitios de esa manera, y siempre estamos evaluando, ¿sigue siendo la mejor manera? ¿Qué debemos hacer para dar a nuestros usuarios lo que piden? Así que estamos haciendo algunas exploraciones internamente, en curso solo para asegurarnos de que Gatsby esté haciendo el mejor trabajo posible en la creación de un sitio web, por lo que mantenemos pequeños los tamaños de los paquetes y nos aseguramos de hacer concesiones por lo que decimos es un código de alto rendimiento con pre -Buscando, ¿tenemos los datos para respaldar eso? Ese es el tipo de cosas que, como defensor de los desarrolladores, me interesan mucho, asegurarme de que lo que empaquetamos y empaquetamos en los sitios web sea realmente necesario y realmente haga el mejor sitio de Gatsby que pueda hacer.

Drew: Hablando con Chris Ferdinandi en julio, le pregunté si las mejores prácticas modernas eran malas para la web. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. He llegado a creer que mucho de lo que consideramos mejores prácticas hoy en día podría estar empeorando la web. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Pero también puede elegir idiomas de preprocesador. Digamos que te gusta Sass. Activas Sass en el CSS y escribes Sass. Bueno, algo tiene que procesar el Sass. En estos días, Sass está escrito en Dart o algo así. Theoretically, you could do that in the client. Pero estas bibliotecas que realizan preprocesamiento son bastante grandes. No creo que quiera enviarte toda la biblioteca de Sass, solo para ejecutar esa cosa. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Pero así es como funciona ahora, hay una lambda. Procesa Sass. Tiene un pequeño, pequeño, pequeño, pequeño trabajo. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. No tienes que preocuparte por la escala. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Pero hay uno para Sass. Hay uno por Menos. Hay uno para Babel. Hay uno para TypeScript. Hay uno para... Todas esas son lambdas individuales que manejamos. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Pero lo usamos para mucho más que eso, incluso recientemente.

Chris Coyier: Here's an example. Cada Pen en CodePen tiene una captura de pantalla. Eso es genial, ¿verdad? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Si lo compartes en Slack, obtienes una pequeña vista previa. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? No es animado de todos modos. Solo ganancias de rendimiento como esa.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. es un trabajador So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Sírvelo como estas dimensiones. No tengo que hacer la imagen en esas dimensiones. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Esos se convierten en puntos de entrada a su aplicación que puede compartir a través de todo tipo de medios.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js también, que es muy, muy bueno, busca automáticamente el resto de las páginas que están conectadas a ese punto de entrada, de modo que se siente como una aplicación de una sola página. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Entonces, en primer lugar, había una motivación para cambiar la reactividad. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Pero está bien. Te enseñaremos de todos modos.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Era TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Así que esta fue nuevamente una gran parte. El último fue que nos perdimos la funcionalidad de la lógica abstracta, en términos de no componentes, sino partes lógicas componibles, como ayudantes de funciones, etc., pero también deberían poder incluir la actividad de Vue. Un buen ejemplo aquí podría ser React Hooks, ¿verdad? Le permiten abstraer las partes de la funcionalidad, y esto claramente faltaba en Vue. Sé que en este momento suena como: "Robaste la función de React". De hecho, no. Creo que la polinización cruzada de ideas es una parte importante y agradable de nuestro ecosistema, y ​​también ayuda a los desarrolladores a cambiar entre sus favoritos, ¿verdad? Así que estábamos trabajando en estas características principales para crear Vue 3 como una versión principal.

Drew: Después de eso, nos sumergimos en TypeScript con Stefan Baumgartner para descubrir cómo puede ayudarnos a escribir mejor código con menos errores. Al observar la tendencia de las organizaciones de mover su base de código por completo a JavaScript, le pregunté a Stefan si TypeScript era algo de lo que los equipos más grandes se beneficiarían más que los individuos.

Stefan Baumgartner: Así que actualmente estoy en la misma transición. Así que tenemos muchos desarrolladores de Java y C++ que van a escribir mucho JavaScript en el futuro. TypeScript puede ser una especie de guía para esas áreas aterradoras del nuevo lenguaje de programación. JavaScript tiene muchas peculiaridades, mucha historia y muchos prejuicios si vienes de un lenguaje de programación diferente. Entonces, TypeScript puede ser una guía porque hay algunos conceptos con los que está familiarizado en el sistema de tipos.

Stefan Baumgartner: Pero también, creo, especialmente cuando hay muchas personas trabajando en la misma base de código o muchas personas que necesitan trabajar entre sí, esto puede ser una capa adicional de orientación en su proyecto, donde no No tengo malas sorpresas al final. Por supuesto, la tecnología no resuelve ningún problema de comunicación. Esto no es para lo que está diseñado TypeScript. Pero puede bajar, o puede hacer mucho más espacio para la discusión correcta, entonces si no tiene que hablar sobre qué espera de mí en su código, sino qué debe hacer su código o qué debe hacer su biblioteca hacer?

Stefan Baumgartner: Siempre digo que si alguna vez escribes código para otras personas o si escribes código con mucha gente o si solo escribes código para ti mismo, tienes que volver a visitarlo al día siguiente, considera TypeScript porque podría ayudarte en el largo plazo. Esto no es solo una inversión para el próximo proyecto de la próxima semana, sino más bien para alguien que dice, está bien, especialmente si tiene proyectos de larga duración por un mes, dos o años, definitivamente ofrezca eso. Nunca sabrás en qué estabas pensando cuando escribiste el pequeño fragmento de código hace un año, pero los tipos pueden darte una pista de lo que querías decir.

Drew: En noviembre, conversé con David Darnes sobre el generador de sitios estáticos, Eleventy. Hablamos sobre las plantillas y cuántos generadores de sitios estáticos son bastante obstinados sobre qué tipo de plantillas debe usar. Me preguntaba si Eleventy tenía el mismo tipo de fuertes creencias. Aquí está Dave.

David Darnes: No, tengo que decir que es lo más desinteresado que se puede estar. Un poco de una visión personal, pero luché por ver cualquier marco o cualquier cosa que no pueda tener opiniones porque, para crear algo, debes tener una opinión sobre cómo quieres hacer algo. Es una especie de oxímoron. Estoy seguro de que la gente podría corregirme en eso. Pero sí. Puede cambiar al lenguaje de plantillas con el que se sienta más cómodo. Quiero decir, solo estábamos hablando de idiomas con los que te sientes cómodo. Eleventy apela a eso en cierto sentido con los lenguajes de plantillas que usan dentro de su HTML, o diablos incluso su CSS, si lo desea.

David Darnes: Para mí, simplemente fui directamente a nunjucks porque nunjucks es el lenguaje de plantillas predeterminado dentro de Eleventy. Eso significa que puedo usar la extensión dot HTML y dejarlo como está. Ahora, solo voy a confundir a la gente aún más y decirles: “Puedes nombrarlo como quieras de todos modos. Puedes divertirte mucho con eso”. Pero puedes usar el manillar. Creo que puede usar plantillas de JavaScript regulares e iterar a través de ellas de esa manera. Manillares bastante populares y Liquid también. No puedo pensar en todos ellos, pero si configuras todo en la configuración, puedes elegir como quieras.

David Darnes: Diría que soy un verdadero gran admirador de los lenguajes de plantillas en general. No fue hace mucho tiempo cuando descubrí que podías usar twig dentro de WordPress, y eso me dejó alucinado. Yo estaba como, “Oh, gracias a Dios. No tengo que manejar un bucle for dentro de PHP”. Una vez más, creo que algo un poco más cómodo y comprensible, más legible también. Así que sí. Eleventy tiene muchas opciones de plantillas diferentes, y debería atraer a las personas que se sienten cómodas con esas diferentes.

Drew: Hablé con Leslie Cohn-Wein sobre cómo Netlify usa su propia plataforma para crear Netlify y cómo su función de vista previa de implementación se convierte en una plataforma de preparación eficaz para los cambios de front-end.

Leslie Cohn-Wein: Quizás mi parte favorita de todo ese proceso es la magia de las vistas previas de implementación, que obtenemos a través de Netlify. Entonces, lo que sucede es que estás trabajando en GitHub, aumentas tu PR. Así que abre su PR en GitHub, y eso creará automáticamente una compilación de su Vista previa de implementación de la aplicación. Así que en realidad usamos Deploy Previews de la propia aplicación para probar, para asegurarnos de que todo funciona como debería. Realizamos nuestras pruebas. Eso es lo que usamos para verificar manualmente durante la revisión del código. Así que tenemos toda esa implementación continua configurada directamente desde GitHub.

Leslie Cohn-Wein: Entonces, una de las otras cosas geniales que hemos configurado es que en realidad tenemos un par de sitios diferentes de Netlify que se extraen del mismo repositorio donde se encuentra nuestra aplicación. Así que tenemos nuestra aplicación. Tenemos una instancia de Storybook que tiene una especie de componentes de interfaz de usuario para la aplicación. Así que tenemos nuestra propia aplicación. Tenemos los componentes de la interfaz de usuario de Storybook, y tenemos básicamente un sitio de Netlify que muestra nuestra interfaz de usuario de Storybook, y luego también tenemos un tercer sitio que ejecuta un analizador de paquetes web. Por lo tanto, es una especie de interfaz de usuario visual que le brinda una visualización de mapa de árbol de todos los paquetes de aplicaciones, y podemos medir su tamaño, y es solo un recordatorio para que verifiquemos dos veces a medida que avanza cada implementación de la aplicación. out, podemos verificar y asegurarnos de que no estamos haciendo nada extraño con el tamaño de nuestro paquete allí.

Leslie Cohn-Wein: Esos tres sitios se generan en una sola solicitud de extracción de la aplicación. Por lo tanto, obtendrá enlaces para obtener una vista previa, esencialmente sus vistas previas de implementación, tanto de la aplicación Storybook como del perfil de esa aplicación para que podamos verificar.

Drew: En diciembre, hablé con Chris Murphy sobre el diseño de productos y lo que significa para los negocios estar enfocados en el diseño. Discutimos si el enfoque de diseño de un fundador individual se filtra en el negocio y si un producto es naturalmente una extensión de la persona que lo creó.

Chris Murphy: Creo que es una muy buena pregunta, Drew, y creo que la respuesta es depende. Creo que depende de esa persona, y depende de la escala de la empresa. Si echas un vistazo a Hiut Denim, y uso mucho Hiut en mi enseñanza, es un muy buen ejemplo de una empresa que está haciendo una cosa bien, y ese es su tipo de jeans con tiras. Creo que si miras el anterior de David... David y Clare, porque son una sociedad. Si nos fijamos en la empresa anterior de David Hieatt y Clare Hieatt, que era Howies, esa empresa había crecido tanto, había tanta gente involucrada.

Chris Murphy: Una vez que la escala comienza a aparecer, comienza a ser muy difícil controlar todos los pequeños puntos de contacto que importan en el recorrido del cliente. Creo que es muy revelador que cuando dejaron Howies, porque Howies había sido comprado por… Es complicado. Ve a leerlo en internet. Pero era Timberland, y se compró Timberland, y está toda esta historia.

Chris Murphy: Creo que es muy interesante que ahora se centren en los jeans. Eso es todo. Están contando una historia increíblemente buena sobre los jeans. También empaquetan todo muy, muy bien, y los jeans son como un vehículo para las historias, de verdad. Esto es algo que creo, Drew, se volverá más importante a medida que salgamos del otro lado de COVID, del cual espero que salgamos del otro lado. A todos los que fabrican esos jeans se les paga un salario adecuado. Uno de los problemas que tengo en este momento cuando miro el mundo es que no a todos se les paga un salario adecuado, y me parece un poco preocupante, como alguien... Mira, tengo 51 años. Mi hijo tiene 25, 24 , 25, algo así. Es terrible. Debería saber todas estas cosas. Es fotógrafo de bodas. Ha sido fotógrafo de bodas durante un año y poco. Su negocio está completamente diezmado porque nadie se está casando en este momento porque es difícil. No tiene salario porque no tenía suficientes libros de cuenta propia para conseguir el sustento.

Chris Murphy: Ha caído en el olvido, y hay muchas otras personas que también han caído en el olvido. Yo diría que es un problema de diseño, que debemos verlo como un problema de diseño. Pero si también miro ese tema más amplio de COVID y el gobierno y todas estas cosas sin ponerme demasiado político, ayer leí un artículo en The Guardian sobre el vecino de Matt Hancock, y cualquiera que esté escuchando que no sea del Reino Unido, Matt Hancock es el secretario de salud. Su vecino, que dirigía un negocio, le enviaba un mensaje de texto y le pedía consejo sobre: ​​"¿Cómo puedo suministrar productos para este asunto de COVID?" Hay un montón de rumores en torno a la quimocracia, así la llaman los periódicos, amigos de amigos de ministros del gobierno que parecen estar consiguiendo trabajo porque conocen a la gente adecuada.

Chris Murphy: Tengo la sensación de que vamos a llegar al otro extremo de esto y ver esto... Las personas ven eso y piensan: "Bueno, ¿adónde va este dinero? ¿Se les paga a las personas adecuadamente? ¿Cuál es el precio de esta camiseta de una libra de la tienda X? No quiero mencionar ninguna marca. Pero todo hay que pagarlo, y todo lo que se hace hay que pagarle a la gente para que lo haga. Creo que la gente está cada vez más interesada en saber si se les paga a las personas de manera justa.

Drew: GraphQL fue el tema de nuestro último episodio completo del año, y conversé con Eve Porcello y le pregunté dónde encaja GraphQL en la pila de desarrollo.

Eva Porcello: Sí. GraphQL encaja entre el front-end y el backend. Por lo tanto, es como vivir en el medio entre los dos y brinda muchos beneficios a los desarrolladores front-end y back-end. Si es un desarrollador front-end, puede definir todos los requisitos de datos de su front-end. Entonces, si tiene una gran lista de componentes de React, por ejemplo, podría escribir una consulta, y eso definirá todos los campos que necesitaría para completar los datos de esa página.

Eve Porcello: Ahora, con el backend, es realmente propio, porque podemos recopilar una gran cantidad de datos de muchas fuentes diferentes. Así que tenemos datos en API REST y bases de datos y todos estos lugares diferentes, y GraphQL nos proporciona esta pequeña y agradable capa de orquestación para dar sentido al caos de dónde están todos nuestros datos. Así que es realmente útil para todo el mundo en toda la pila.