Smashing Podcast Episodio 23 Con Guillermo Rauch: ¿Qué es Next.js?

Hoy, estamos hablando de Next.js. ¿Qué es y dónde podría encajar en nuestro flujo de trabajo de desarrollo web? Hablé con el co-creador Guillermo Rauch para averiguarlo.

Mostrar notas

• Guillermo Rauch en Twitter
• Siguiente.js

Actualización semanal

• "Dominar accesorios y tipos de props en React"
  por David Adeneye
• “Decisiones de diseño inspiradas con Bradbury Thompson: el arte del diseño gráfico”
  por Andy Clarke
• “Configuración de una API con Flask, Google Cloud SQL y App Engine”
  por Wole Oyekanmi
• “Formas y Validación en Ionic React”
  por Jerry Navi
• “Cómo ayudar a sus clientes a obtener más backlinks a través del diseño”
  por Suzanne Scacca

Transcripción

Drew McLellan: es el fundador y director ejecutivo de Vercel, una plataforma en la nube para sitios estáticos que se adapta a un flujo de trabajo de Jamstack. También es cocreador de Next.js. Anteriormente fundó LearnBoost y CloudUp, y es conocido como el creador de varias bibliotecas de código abierto de nodos populares como Socket.io, Mongoose y SlackIn. Antes de eso, fue un desarrollador principal en MooTools, por lo que sabemos que conoce JavaScript como la palma de su mano. ¿Sabías que una vez recibió una comisión real del Rey de España para crear una escultura de hielo con lechuga iceberg? Mis aplastantes amigos, denle la bienvenida a Guillermo Rauch. Hola guillermo como estas

Guillermo Rauch: Estoy muy bien, gracias por invitarme.

Drew: Quería hablarte hoy sobre todo el mundo de Next.js, ya que es algo sobre lo que, obviamente, tú personalmente estás muy bien informado, ya que participaste como cocreador desde el principio. Next.js es uno de esos nombres de proyectos que ha estado en mi radar mientras trabajaba en el espacio Jamstack, pero no es algo que personalmente haya visto o trabajado demasiado de cerca antes. Para las personas que son como yo, que tal vez no saben qué es Next.js, tal vez podría brindarnos un poco de información sobre qué es y qué problemas intenta resolver.

Guillermo: Next.js es un miembro muy interesante del universo Jamstack, porque Next.js en realidad comenzó siendo un framework completamente enfocado en SSR. Comenzó a tener mucha adopción fuera del espacio Jamstack, donde la gente creaba cosas muy grandes específicamente cuando querían tener contenido generado por el usuario o contenido dinámico o redes sociales o comercio electrónico, y sabían que querían SSR porque su conjunto de datos era muy grande o muy dinámico. Creo que pasó desapercibido para mucha gente en el mundo de Jamstack, pero más tarde Next.js obtuvo las capacidades para la optimización estática.

Guillermo: Por un lado, por ejemplo, si no hicieras la búsqueda de datos en el nivel superior de tu página con Next.js, tu página de React sería… También por cierto, para aquellos que no están completamente informados, Next.js es simplemente el marco React para producción, pero tiene la capacidad de hacer algo de renderizado. Luego, cuando obtiene capacidades de optimización estática, si no define la obtención de datos en el nivel superior de su página, se exporta automáticamente como HTML en lugar de intentar hacer algo con la representación del servidor.

Guillermo: Luego, más adelante, también obtuvo la capacidad de generar sitios estáticos, lo que significa que puedes definir un enlace de datos especial, pero ese enlace de datos obtiene datos en el momento de la construcción. Next.js se convirtió en un marco híbrido, dinámico y estático muy poderoso, y ahora también ha estado creciendo mucho en el espacio Jamstack.

Drew: La gente podría decir que React ya es un marco, ciertamente escuchas que se describe de esa manera. ¿Qué significa realmente ser un marco para React?

Guillermo: Esa es una gran observación, porque siempre le digo a la gente que Reaccionar en Facebook y Reaccionar fuera de Facebook son bestias completamente diferentes. React en Facebook en realidad se usa junto con el renderizado del servidor, pero incluso su renderizado del servidor, por ejemplo, no usa Node.js, usa una máquina virtual altamente especializada llamada Hermes que se comunica con su tipo de pirateo de producción y pila PHP y responde todas estas necesidades avanzadas y exóticas de Facebook.

Guillermo: Cuando abren React, es casi como abrir un componente. Siempre lo llamo como abrir el motor, pero no darte el auto. Lo que sucedió es que la gente realmente quería ir y conducir con él, querían llegar a lugares con React. En la comunidad, la gente comenzó a crear autos, e incorporarían React como el motor, que era lo que el conductor, el desarrollador buscaba en primer lugar, hacer de React la parte fundamental del auto. Comenzaron a aparecer cosas como Next.js y Gatsby y React Static y muchos otros marcos que estaban resolviendo la necesidad de "En realidad quiero crear páginas y aplicaciones completamente cargadas".

Guillermo: Mientras que React era más como el componente y el motor para widgets específicos dentro de la página, este fue sin duda el caso de Facebook. Admitirán de manera amplia y pública que lo inventaron para cosas como el lote de notificaciones, el widget de chat, el componente de suministro de noticias, y esos componentes eran rutas de reacción que se incrustaron en el contenido de la aplicación de producción existente con muchas, muchas líneas de código. e incluso otras bibliotecas y marcos JS.

Guillermo: Lo que significa crear un marco para React, significa que haces de React la parte fundamental de la historia, con suerte y esto es algo que intentaremos hacer con Next.js, la curva de aprendizaje se trata principalmente de React con algunos agregados. superficie para Next.js, particularmente en torno a la obtención y el enrutamiento de datos. También hacemos muchas optimizaciones de producción, así que cuando obtienes React, cuando obtienes la aplicación Create React, que es algo así como, me gusta llamarlo un auto de arranque que Facebook te brinda, tal vez las necesidades de producción no se satisfagan realmente. . O si intenta hacerlo usted mismo configurando Webpack y configurando Babel y configurando la representación del servidor y la generación estática, también es difícil armar un automóvil desde cero. Next.js le dará esta configuración cero y también un conjunto de valores predeterminados optimizados para la producción en torno a la creación de grandes cosas con React.

Drew: Es como si casi pusiera una especie de ecosistema alrededor de su aplicación React con una colección de herramientas preconfiguradas para permitirle:

Guillermo: Correcto.

Drew: comience a ejecutar y realice la generación de sitios estáticos o la representación o el enrutamiento del servidor.

Guillermo: Correcto, y ahí usaste una palabra que es muy, muy clave en todo esto, que está preconfigurado. Tenemos la suerte de llamar la atención de Google Chrome como colaborador de Next.js. Una de las líderes de este proyecto, lo suyo es que cuando estaban trabajando en marcos internamente en Google, enfrentaron muchos de los mismos problemas que enfrenta la comunidad y el código abierto hoy. Hubo muchas iniciativas diferentes que competían en Google sobre cómo escalar y hacer aplicaciones web realmente eficaces desde el primer momento.

Guillermo: Te unirías como Googler y se te daría un marco con el que crearías aplicaciones realmente grandes listas para producción y de muy alto rendimiento. Shubie formó parte de muchas de esas iniciativas, y lo que descubrió es que hay dos ingredientes clave para hacer que un marco tenga éxito a escala. Una es la configuración previa, lo que significa que viene a trabajar, va a iniciar una aplicación completamente nueva, debe recibir algo que ya esté listo para funcionar y cumpla con muchas de las demandas de producción que se conocen en ese momento. a tiempo.

Guillermo: Por otro lado, el otro paso muy importante en el que estamos trabajando es la conformidad. Se le puede proporcionar el marco preconfigurado listo para producción más optimizado, pero si sigue adelante y, por ejemplo, comienza a introducir muchas dependencias pesadas o scripts de terceros o usa diseños muy ineficientes que toman mucho tiempo para pintar y así sucesivamente y así sucesivamente, entonces vas a hacer que esa preconfiguración se desperdicie. Al combinar la configuración previa con la conformidad a lo largo del tiempo, el desarrollador no solo tiene un excelente punto de partida, sino que también lo guía hacia el éxito a lo largo del tiempo.

Drew: Parece que una característica de Next.js, que es bastante obstinado, la capa de UI es React, usa script de tipo, usa Webpack, y esas son todas las elecciones que ha hecho el proyecto y eso es lo que obtienes. Corrígeme si me equivoco, pero no podrías cambiar React por Vue, por ejemplo, dentro de Next.js.

Guillermo: Ese es un buen punto, donde la toma de decisiones técnicas se encuentra con una especie de arte. Por un lado, realmente me gustaría afirmar que Next no tiene opiniones, y la razón de esto es que si vas específicamente a github.com/vercel/nextjs y al directorio de ejemplos, verás que hay casi como un Explosión combinatoria de tecnologías que puedes usar junto con Next.js. Verás basado en fuego, verás Graphic UL, verás Apollo, verás Redux, verás MobX, en el espacio CSS hay aún más opciones.

Guillermo: Tenemos un puerto CSS predeterminado que está incrustado, pero luego puede usar dos sabores, uno con importación, otro con etiquetas de estilo que llamamos Style JSX, que se parece mucho al enfoque de la plataforma web para Shadow CSS. La razón por la que quiero decir sin opiniones es que queremos que Next.js se mantenga muy cerca del "metal desnudo" de la web, y no introduzca muchas primitivas con las que la web de 10 años a partir de hoy sería incompatible. Luego, si observa los ejemplos, verá que hay todas estas otras tecnologías que puede conectar.

Guillermo: El nivel básico de opinión es que existe React y no podrás reemplazarlo, al menos en el corto plazo. Luego está el concepto de que debería poder crear páginas, y esto era como algo nuevo cuando lo lanzamos por primera vez, en el que todos intentaban crear aplicaciones de una sola página. Nos dimos cuenta de que Internet está compuesto de sitios web con muchas páginas que crean distintos puntos de entrada a través de motores de búsqueda, Twitter, Facebook, redes sociales, correos electrónicos complementarios, como si siempre guiaras a la persona hacia un punto de entrada. y esa persona que pasa por ese punto de entrada no debería tener que descargar la carga de la totalidad de la aplicación.

Guillermo: Luego ese camino nos llevó a implementar renderizado en servidor, luego generación estática para múltiples páginas, etcétera, etcétera. Ese otro nivel básico de opinión es Next debería ser un marco que funcione para la web, no contra la web. Luego, además de eso, a React le faltaban primitivas de obtención y enrutamiento de datos, y las agregamos. Hay un nivel de opinión que tiene que lidiar con que todo el mundo necesita un enrutador, por lo que también podría tener un enrutador integrado de forma predeterminada.

Drew: La gran ventaja de tener esos valores predeterminados es que elimina gran parte de la complejidad de la elección, que simplemente está ahí, está configurado y puede comenzar a usarlo sin necesidad de pensar demasiado, porque creo que todos tenemos -

Guillermo: Exacto.

Drew: He estado en situaciones en las que hay demasiadas opciones de qué componentes usar, y puede ser abrumador y obstaculizar la productividad.

Guillermo: Exacto.

Drew: ¿Para qué tipo de proyectos ves que la gente usa Next.js? ¿Es básicamente para cualquier situación en la que pueda crear una aplicación React de producción, o es más adecuada para tipos particulares de sitios con mucho contenido? ¿Importa en ese sentido?

Guillermo: Sí, entonces este ha sido un viejo debate sobre la web, ¿es la web para aplicaciones, es la web para sitios, es un híbrido? ¿Cuál es el papel de JavaScript, etcétera, etcétera? Es un poco difícil dar una respuesta directa, pero mi opinión es que la web evolucionó siempre para ser un híbrido de contenido que evoluciona para ser cada vez más dinámico y personal para el usuario. Incluso cuando dices como un sitio web de contenido, los sitios web de contenido de alto nivel del mundo tienen bases de código que son muy comparables a las aplicaciones.

Guillermo: Un gran ejemplo aquí es como el New York Times, te darán widgets incorporados con herramientas de análisis de datos y animación interactiva, y te recomendarán qué historia leer a continuación, y tienen un modelo de suscripción integrado que a veces te da parte del contenido y, a veces, cuenta cuántos artículos has leído. Como si les dijera esto cuando se inventó la web, como si Tim Berners-Lee dijera: "No, eso es una locura, eso no es posible en la web", pero esa es la web que tenemos hoy.

Guillermo: Next.js está respondiendo a muchas de estas complejas necesidades modernas, lo que significa que verá mucho uso del comercio electrónico, verá mucho contenido con eso. Comercio electrónico significa, por cierto, no solo como comprar artículos, sino experiencias como los sitios web de bienes raíces más grandes de la web, realtor.com, zillow.com, trulio.com, toda esa categoría es todo Next.js, luego el contenido sitios Acabamos de incorporar washingtonpost.com como cliente de Vercel y Next.js, luego tenemos una tercera categoría que es más emergente pero muy interesante, que son aplicaciones completas y contenido generado por el usuario, como tiktok.com, y algo así como usted. pensaría que el caso de uso de la aplicación original de una sola página también está bastante representado allí.

Guillermo: Next.js brilla cuando necesitas tener mucho contenido que se debe servir muy, muy rápido, tiene que estar optimizado para SEO y, al final del día, es una mezcla de dinámico y estático.

Drew: Anteriormente hablé con Marcy Sutton sobre Gatsby, que parece estar en un espacio similar. Siempre es bueno ver más de una solución a un problema y tener opciones de un proyecto a otro. ¿Diría que Next.js y Gatsby están operando en el mismo tipo de espacio problemático y qué tan similares o diferentes son?

Guillermo: Creo que hay una superposición para algunos casos de uso. Por ejemplo, mi blog personal rauchg.com se ejecuta en Next.js, también podría haber sido un gran blog de Gatsby. Existe esa superposición en el espacio del sitio web estático más pequeño, y por pequeño no quiero decir que no sea relevante. Muchas puntocom que son súper, súper importantes se ejecutan básicamente en una web estática, así que, en mi opinión, esa es la belleza de Jamstack. Debido a que Next.js puede optimizar estáticamente sus páginas y luego puede obtener excelentes puntajes de Lighthouse a través de eso, puede usarlo para casos de uso superpuestos.

Guillermo: Creo que la línea se dibuja cuando empiezas a tener necesidades más dinámicas y tienes muchas páginas, tienes la necesidad de actualizarlas de una vez. Aunque Gatsby está creando soluciones para ellos, Next.js ya tiene soluciones en vivo listas para producción que funcionan con cualquier tipo de base de datos, cualquier tipo de backend de datos para básicamente "generar" o "imprimir" montones y montones de páginas. Ahí es donde hoy los clientes van a Next.js en lugar de Gatsby.

Drew: Uno de los problemas con los que todos parecen encontrarse a medida que su solución basada en JavaScript crece es el rendimiento y cómo las cosas pueden comenzar a volverse bastante lentas, tiene paquetes de gran tamaño. Tradicionalmente, cosas como la división de código pueden ser bastante complejas para configurarse correctamente. Veo que esa es una de las características que me llamó la atención de Next.js, que afirma que la división del código es automática. ¿Qué hace Next.js en términos de división de código para que funcione?

Guillermo: Tu observación es 100% correcta. Una de las cosas más importantes de la web y uno de los mayores pesos en la web es JavaScript, y al igual que diferentes materiales tienen diferentes densidades y pesos independientemente del volumen físico real, JavaScript tiende a ser un elemento muy denso y pesado. Incluso pequeñas cantidades de JavaScript en comparación con, por ejemplo, imágenes que se pueden procesar de forma asíncrona y fuera del hilo principal, JavaScript tiende a ser particularmente molesto.

Guillermo: Next.js ha invertido una gran cantidad de esfuerzo en optimizar automáticamente sus paquetes. La primera que fue mi primera intuición cuando se me ocurrió la idea de Next.js fue que ibas a definir, por ejemplo, 10 rutas. En el mundo de Next.js, crea un directorio de páginas y coloca sus archivos allí Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.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: Cuando los ingrese, queremos brindarle JS que sea relevante para esa página en primer lugar, y luego quizás un paquete común para que las navegaciones posteriores dentro del sistema sean muy ágiles. 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. Mucha gente dice: "¿Por qué no usar la aplicación Create React si sé que tengo quizás un par de rutas?" Siempre les digo: "Miren, pueden encontrarlas como páginas, y como Next.js buscará automáticamente las que están conectadas, terminan obteniendo su aplicación de una sola página, pero está mejor optimizada con respecto a esa pintura inicial". , ese punto de entrada inicial.”

Guillermo: Ese fue el enfoque inicial de división de código, pero luego se volvió mucho más sofisticado con el tiempo. Google contribuyó con una muy buena optimización llamada Módulo y sin módulo, que brindará JS diferencial a los navegadores modernos, y JS heredado que está lleno de policampos para otros navegadores, y esta optimización está 100% automatizada y produce ahorros masivos. Se lo dimos a uno de nuestros clientes que hospedamos en Vercel llamado Parnaby's, creo que si no me equivoco, fue algo muy, muy significativo. Tal vez fue un ahorro del 30 % en el tamaño de los códigos, y eso fue solo porque actualizaron Next.js a una versión que optimizaba mejor los paquetes de JS.

Guillermo: Ese era el punto que estábamos analizando antes, que es que eliges Next.js y solo mejora y se vuelve más óptimo con el tiempo, continuará optimizando las cosas en tu nombre. Esas son, de nuevo, configuraciones previas con las que nunca tendría que lidiar o con las que nunca tendría que preocuparse, y cuya investigación ni siquiera quiere hacer, para ser honesto. Obviamente, no estaba muy involucrado con esto, pero observé algunas de las discusiones internas y estaban discutiendo todos estos policampos que solo importaban para Internet Explorer X y Soho, dije: "Ni siquiera quiero saber , actualicemos Next.js y obtengamos todos estos beneficios”.

Drew: A veces hay grandes beneficios al apegarse a los valores predeterminados y apegarse a la configuración más común de las cosas, que parece ser realmente el enfoque de Next.js. Recuerdo cuando comencé a escribir PHP a principios de la década de 2000, y todos usaban PHP y MySQL, y en ese momento yo acababa de venir de Windows, así que quería usar PHP y Microsoft Sequel Server. Puedes hacerlo, pero estás nadando contra la corriente todo el camino. Luego, tan pronto como cambié a MySQL, todo el ecosistema comenzó a funcionar para mí y no tuve que pensar en ello.

Guillermo: Sí, todo simplemente hace clic, esa es una gran observación. Vemos eso todo el tiempo, como que el ecosistema de Babel es tan poderoso ahora que podría volverse, por ejemplo, un poco más rápido cambiando Babel por otra cosa, pero luego cambia esa increíble compatibilidad con el ecosistema. Esto es algo que mencionó anteriormente sobre el rendimiento y, como para muchas personas, el rendimiento de compilación y el rendimiento de generación estática es un gran cuello de botella, y esto es algo en lo que somos muy diligentes para mejorar el rendimiento de nuestras herramientas de forma incremental.

Guillermo: Por ejemplo, una de las cosas que está haciendo Next.js ahora es que está actualizando su valor predeterminado de Webpack 4 a Webpack 5, que tiene algunas cosas innovadoras, y es por eso que primero lo ofrecemos a las personas como una opción. en la bandera, pero luego se convertirá en el valor predeterminado. Webpack 5 realiza increíbles mejoras de rendimiento, pero no estamos sacrificando el ecosistema de Webpack, lo mejoramos gradualmente. Claro, había algunas cosas muy pequeñas que debían sacrificarse, pero ese es un beneficio increíble del ecosistema JS hoy en día que mucha gente está pasando por alto, creo, porque tal vez ven, "Oh, podríamos haber hecho X en Soho, tal vez fue un poco más rápido, o tal vez MPM en Soho tomaría menos tiempo”. Captan algunos detalles y se pierden el panorama general, que es que el valor del ecosistema es enorme.

Drew: El valor de tener toda la configuración y el mantenimiento y ese lado realizado por un proyecto como Next.js en lugar de asumirlo usted mismo cambiando a usar otra cosa es increíble, porque tan pronto como se aleja de esos valores predeterminados , estás asumiendo la carga de mantener todas las compatibilidades y haciéndolo tú mismo. Una de las cosas que me ha interesado mucho con Next.js es que hay opciones disponibles para hacer la generación de sitios estáticos o la representación del lado del servidor, o tal vez un híbrido de los dos. Creo que ha habido algunos cambios recientes a esto en una actualización reciente, ¿puede contarnos un poco sobre eso y cuándo puede elegir uno u otro?

Guillermo: Sí, seguro. Uno de los componentes clave de este enfoque híbrido combinado con el sistema de páginas que describí anteriormente es que puede tener páginas completamente estáticas o páginas procesadas por el servidor. Una página que es completamente estática tiene el increíble beneficio de lo que yo llamo elevación estática, que es que puedes tomar ese activo y colocarlo automáticamente en el borde. Al ponerlo en el borde, quiero decir que puede almacenarlo en caché, puede almacenarlo en caché de forma preventiva, puede replicarlo, puede hacer que cuando llegue una solicitud, nunca toque el servidor porque sabemos de antemano, " Oye, Slash Index es estático”.

Guillermo: Ese es un beneficio muy, muy interesante cuando se trata de servir a audiencias globales. Básicamente, obtiene una CDN automática lista para usar, especialmente cuando implementa las redes de borde modernas como Vercel o AWS Amplify o Netlify, etc. Next.js tiene la premisa de que si se puede hacer estático, debería ser estático. Cuando comienza un proyecto por primera vez y está trabajando en su primera página o está pateando los neumáticos del marco, también podría hacer que todo sea estático.

Guillermo: Incluso para necesidades de alto nivel, por ejemplo, vercel.com, nuestro propio uso de Next.js es totalmente estático. Es una combinación de generación de sitios totalmente estáticos y estáticos, por lo que todas nuestras páginas de marketing son estáticas, nuestro blog se genera de forma estática a partir de una fuente de datos dinámica y luego nuestro panel de control que tiene muchos datos dinámicos, pero podemos entregarlos como conchas o esqueletos. , todas las páginas asociadas con la visualización de sus implementaciones, la visualización de sus proyectos, la visualización de sus registros, etcétera, etcétera, son básicamente páginas estáticas con JavaScript del lado del cliente.

Guillermo: Eso nos sirve increíblemente bien porque todo lo que necesitamos un rendimiento de primer panel muy rápido ya está prerenderizado, todo lo que necesita SEO ya está prerrenderizado y todo lo que es extremadamente dinámico, solo tenemos que preocuparnos por la seguridad, por por ejemplo, desde la perspectiva del lado del cliente que usa las mismas llamadas API que, por ejemplo, usó nuestra CLI o nuestras integraciones, etcétera, etcétera. Un sitio web completamente estático, muy económico de operar, increíblemente escalable, etc.

Guillermo: Ahora, una cosa particular que necesitábamos con nuestro blog era que queríamos actualizar los datos muy rápidamente. Queríamos corregir un error tipográfico muy rápidamente y no esperar a que sucediera una compilación completa, y este es un beneficio muy significativo de Next.js, que a medida que pasa de lo estático a lo dinámico, también le brinda estas soluciones intermedias. . Para nuestro blog, usamos la generación estática incremental, por lo que esencialmente podemos reconstruir una página a la vez cuando cambia el contenido subyacente.

Guillermo: Imagine que no solo tuviéramos un par de cientos de publicaciones de blog y tuviéramos muchas publicaciones de blog que se generan todo el tiempo y se actualizan todo el tiempo, como mencioné a uno de nuestros clientes, Washington Post, en ese caso usted necesita ir más hacia SSR completo, especialmente a medida que comienza a personalizar el contenido para cada usuario. Ese viaje de complejidad que acabo de describir comenzó desde que tengo una página de marketing, tengo un blog que tiene un par de miles de páginas, tengo decenas de miles o millones de páginas. Ese es el viaje de Next.js que puede recorrer con su propio negocio.

Guillermo: Entonces comienzas como desarrollador a elegir entre quizás menos responsabilidad o más responsabilidad, porque cuando optas por usar SSR, ahora estás ejecutando código en el servidor, estás ejecutando código en la nube, hay más responsabilidad con más poder. El hecho de que puedas decidir dónde usar cada tipo de herramienta es, en mi opinión, una ventaja muy, muy interesante de Next.

Drew: Solo en los aspectos prácticos de combinar la generación de sitios estáticos y la representación del lado del servidor, ¿cómo funciona eso en términos del elemento del servidor? ¿Necesita una plataforma dedicada como Vercel para poder lograrlo, o es algo que se puede hacer de manera más directa y sencilla?

Guillermo: Next.js te da un servidor de desarrollo, así que descargas Next y ejecutas tu Next Dev, y ese es el servidor de desarrollo. El servidor de desarrollo obviamente está increíblemente optimizado para el desarrollo, como si tuviera la última tecnología de actualización rápida que lanzó Facebook, donde... En realidad, Facebook no lo lanzó, Facebook lo usa internamente para obtener el mejor reemplazo de módulo caliente, el más confiable y el más confiable. , de modo que básicamente estás escribiendo y los cambios se reflejan en la pantalla, así que ese es el servidor de desarrollo.

Guillermo: Luego, Next te brinda un servidor de producción llamado Next Start, y Next Start tiene todas las capacidades del marco para el autohospedaje. Lo interesante de Vercel es que cuando implementa Next, se optimiza automáticamente y es 100 % sin servidor, lo que significa que no hay responsabilidad alguna de administración, escalado, cobro y validación de cobro, depuración, replicación, conmutación por error global, etc. etc., que tendría que asumir cuando ejecute Next Start usted mismo.

Guillermo: Ese es también el gran beneficio de Next.js, así que, por ejemplo, apple.com tiene varias propiedades, subdominios y páginas diferentes en puntocom en Next.js que se autohospedan, debido a necesidades de seguridad y privacidad muy, muy avanzadas y estrictas. . Por otro lado, washingtonpost.com usa Vercel, por lo que tenemos este tipo de amplia gama de usuarios, y estamos muy contentos de apoyarlos a todos. En mi opinión, lo bueno de hacia dónde se dirige sin servidor es que puede brindarle lo mejor de ambos mundos en términos del rendimiento más óptimo que solo mejora con el tiempo, con la mejor experiencia de desarrollador de, "Oye, no tengo preocuparse por cualquier tipo de infraestructura”.

Drew: Next.js es un proyecto de código abierto que está desarrollando el equipo de Vercel. ¿Hay otros colaboradores fuera de Vercel?

Guillermo: Sí, entonces Google Chrome es el principal que envía activamente PR del servidor, nos ayuda con las optimizaciones y lo prueba con socios, como usuarios muy grandes de Next.js que ya son parte del ecosistema de Google, por ejemplo, debido al uso de muchos y muchas aplicaciones, por lo que deben involucrarse estrechamente como socios. Facebook, mantenemos una gran relación con el equipo de Facebook. Por ejemplo, la actualización rápida, fuimos el primer marco de React en aterrizar eso, y nos ayudaron a guiarnos a través de todo lo que aprendieron sobre el uso de React y la actualización rápida en Facebook.

Guillermo: Trabajamos con muchos socios que tienen implementaciones muy grandes de aplicaciones Next.js en la naturaleza de todo tipo de casos de uso diferentes, como imaginar comercio electrónico y contenido. Luego hay montones y montones de colaboradores independientes, personas que usan Next.js personalmente, pero también educadores y miembros de equipos de infraestructura frontal en grandes empresas. Es un esfuerzo comunitario muy, muy amplio.

Drew: Suena como la preocupación que alguien podría tener, que esto está siendo desarrollado en gran parte por Vercel, que podrían tener la preocupación de que van a quedar atrapados en la implementación en esa plataforma en particular, pero suena muy parecido a ese no es el caso en absoluto, y podrían desarrollar un sitio e implementarlo en Firebase o Netlify o...

Guillermo: Sí, absolutamente. Me gusta mucho compararlo porque, en cierto modo, es como los Kubernetes de la era Front End, porque al final del día creo firmemente que... Kubernetes es algo que casi todo el mundo necesita cuando necesita ejecutar procesos de Linux. , como si estuvieras hablando de opinión y estás diciendo que es una buena tecnología, no es mucho opinión, pero hay algunas opiniones que olvidamos. Es como si al final del día, surgió de la ejecución de demonios específicos de programas de Linux empaquetados como contenedores.

Guillermo: Next está en una posición similar, porque lo que tomamos por ser el primitivo universal del mundo como un componente de React, obviamente es obstinado, pero sí creemos que para muchas empresas, al igual que todas gravitan hacia Linux, somos viendo lo mismo con React y Vue, pero Vue afortunadamente también tiene Nuxt, que es una solución increíble, es equivalente en ideación y principios a Next. Estamos gravitando hacia estas plataformas como Next.js, como Nuxt, como Sapper para el ecosistema Svelte.

Guillermo: Creo que deberían ser plataformas abiertas, porque, de nuevo, si todo el mundo va a necesitar esto, es mejor no reinventar la rueda en toda la industria, ¿no? Damos la bienvenida a esa posición, damos la bienvenida a las personas para implementarlo y reconfigurarlo y reconstruirlo y redistribuirlo y así sucesivamente.

Drew: Recientemente se lanzó una nueva versión de Next.js, creo que la versión 9.5. ¿Qué cambios significativos hubo en ese lanzamiento?

Guillermo: Lo más asombroso es que, como decía antes, muchas cosas comienzan estáticas y luego se vuelven más dinámicas a medida que crecen. Esta fue la aventura de WordPress, por cierto. Al principio, WordPress se basó en un enfoque de base de datos de archivos estáticos, y luego creció hasta necesitar una base de datos, algo así como lo que describiste con la forma en que PHP evolucionó para convertirse cada vez más en MySQL. Lo bueno de Next.js 9.5 es que hace que la generación estática incremental sea una función lista para la producción, por lo que la eliminamos de la bandera inestable.

Guillermo: Esta función te permite hacer ese viaje de lo estático a lo dinámico sin renunciar a todos los beneficios de lo estático y sin tener que pasarte por completo con lo dinámico generado por el servidor, por lo que extiende la vida útil de tu tipo de estático. La forma en que lo usamos en Vercel, por ejemplo, como mencioné, es como si nuestro blog se renderizara por completo en el momento de la compilación, pero luego, por ejemplo, estamos en un par de minutos a punto de hacer un anuncio importante, y cuando escribimos en un blog al respecto, queremos poder modificarlo, arreglarlo, obtener una vista previa, etcétera, sin tener que emitir una compilación de cinco a 10 minutos cada vez que cambiamos una letra de una publicación de blog.

Guillermo: Con la generación estática incremental, puedes reconstruir una página a la vez. Lo que podría tomar minutos o incluso segundos, dependiendo del tamaño de su sitio, ahora toma milisegundos. Una vez más, no tenía que renunciar a ninguno de los beneficios de la estática. Eso es quizás lo que más me emociona que se estabilizó en Next.js 9.5, y específicamente porque la comunidad JS y la comunidad React y la comunidad del marco y la comunidad generada por el sitio estático han estado hablando sobre este unicornio de hacer un incremental estático para a long time, so the fact that Next.js did it, it's being used in production and it's there for everybody to use, I think it's a major, major, major milestone.

Guillermo: There's lots of little DX benefits. One that's really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let's say that I'm uber.com and I've decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?

Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn't match the Next.js routing system, it goes to the legacy system.

Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.

Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We're doing a lot in this space, by the way, like we're making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we're going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.

Guillermo: A great example is we're rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we're already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that's extremely valuable, because when you're pre-rendering you're not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.

Guillermo: One of the most exciting things that's coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we're also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we're always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you'll have more and more opportunities to do kind of a mix of the two.

Drew: Sounds like there's some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?

Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it'll walk you through building your first small static site with Next.js, and then it'll walk you through the journey of adding more and more complexity over time, so it's a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that's being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.

Drew: I've been learning all about Next.js today, what have you been learning about lately, Guillermo?

Guillermo: As a random tangent that I've been learning about, I decided to study more economics, so I've been really concerned with like what is the next big thing that's coming in terms of enabling people at scale to live better lives. I think we're going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you're going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.

Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I've been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I've found there's lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.

Drew: Eso es fascinante. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. ¿Tienes alguna palabra de despedida?

Guillermo: No, thank you for having me.