De la Arquitectura a la Adopción: Ingeniería y Escalado de un LMS Moderno con React

Hola a todos. ¿Cómo están encontrando su tiempo en Ámsterdam hasta ahora? ¿Bien? Perfecto. El clima es agradable. Así que eso siempre es increíble, especialmente para Ámsterdam. Pero sí, antes de presentarme quería hacerles una pregunta. Me preguntaba si en algún momento de su carrera, tuvieron que aprender algo que su jefe o su gerente de proyecto les pidió que hicieran realmente rápido, como arreglar ese error o implementar esa función dentro de su plataforma. Tuvieron que hacer algo así muy rápidamente, ¿verdad?

Así que lo siguiente es que supongo que luego revisaron la documentación, vieron algunos tutoriales de YouTube, o incluso si estaban realmente atascados en ello, tal vez compraron un curso. Pero supongo que lo que me sucede típicamente cuando trato de meter todo ese conocimiento en aproximadamente una semana, típicamente olvidamos lo que hemos aprendido. Así que eso nos pasa a la mayoría de nosotros, es completamente normal.

Así que mi pensamiento es que no es de extrañar que eso suceda, considerando que la mayoría de las plataformas de aprendizaje en línea se sienten casi idénticas. Hay un video, hay algo de texto debajo, y una sección de comentarios a la que nadie parece responder. También está YouTube, que es increíble para contenido interactivo, pero es más o menos lo mismo. Video en la parte superior, luego una descripción, y luego comentarios. Y como desarrolladores, estamos acostumbrados a documentación interactiva, especialmente hoy en día. Muchas de estas DevTools están creando documentación que realmente puedes mover y seleccionar tus opciones para tecnologías y las cosas simplemente funcionan al instante.

También está Stack Overflow y Code Sandboxes. Aprendemos haciendo. Y la mayoría de las plataformas de aprendizaje aún no han evolucionado para soportar eso. Y quiero decir, no es de extrañar, lo entiendo. Imagina una plataforma tratando de soportar a alguien tratando de aprender a jugar ajedrez, tal vez hornear masa madre, programar en Rust, o criar un petiguana todo a la vez. Simplemente no puedes hacerlo todo. Así que eso es porque necesitarías acomodar todos estos diferentes tipos de aprendizajes. Necesitarías un panadero para asistir a lanzar un chat en vivo, un widget de tablero de ajedrez, resaltado de sintaxis para cada lenguaje jamás creado, y un Simulador de Terrario, supongo. Así que hay muchas cosas que necesitarías que una sola plataforma no puede hacer todo. Creo que todos podemos estar de acuerdo con eso, y no deberían. Ninguna plataforma debería atender a cada audiencia.

Así que por eso creo que necesitamos una plataforma de aprendizaje hecha para desarrolladores. Así que, hola. Soy Adrian, el fundador de JavaScript Mastery, donde educamos, afortunadamente ahora, a millones de usuarios en todo el mundo a través de tutoriales de YouTube basados en proyectos. Y hoy, quiero compartir mi opinión sobre la construcción de esa plataforma de aprendizaje. Y no solo cómo la construimos, sino que quiero compartir algunos estudios de caso del mundo real de cómo lo estamos abordando.

La arquitectura, escalabilidad, rendimiento, obstáculos que encontramos, y luego retención, cómo realmente lograr que los usuarios regresen a la plataforma todos los días. Y honestamente, la mayoría de estas lecciones que voy a repasar hoy se aplican a cualquier aplicación pesada en contenido. No es solo sistemas de gestión de aprendizaje. No es solo CMSs. Cualquier cosa donde tengas que gestionar mucho contenido, algunas de las cosas que vamos a revisar hoy, podrás ponerlas en práctica.

Así que, después de luchar con intentar usar diferentes plataformas LMS, de nuevo, todas caían en el mismo diseño estándar, quería construir contenido de la manera en que construyo aplicaciones. Flexible, modular, reactivo, si se quiere. Entonces, ¿piensas que hay un formato específico que nos permitiría lograr ese nivel de flexibilidad con código? Tal vez diferentes tipos de formatos de texto, como Markdown. Markdown fue, por supuesto, lo primero que intentamos, pero aún se sentía un poco limitado. Sin interactividad, sin lógica. Más como una entrada de blog.

Luego, probamos diferentes plataformas CMS, que eran mejores, pero aún no había formas nativas de incrustar componentes interactivos o agregar algo de estado en las lecciones que la gente está aprendiendo. Luego, le di una oportunidad a MDX. Es Markdown más JSX. ¿Puedo ver una mano levantada de cuántas personas han oído hablar o han usado MDX antes? Eso es aproximadamente la mitad, diría. Principalmente para blogs, supongo, ¿verdad? La mayoría de ustedes tal vez tienen sus propios blogs funcionando en MDX o páginas de documentación, docs. Sí, son muchos docs. Es una tecnología increíble que nos permite básicamente inyectar componentes reales en cualquier lugar. En nuestro caso, para una plataforma de gestión de aprendizaje, eso es cuestionarios, llamados, tareas, reproductores de video, sandboxes de código, todo en vivo, interactivo, y consciente del contexto, lo cual es una historia completamente diferente a solo tener un video y un fragmento de texto.

MDX nos ayudó con eso. De repente, la creación de contenido se sintió más como codificación porque podía incrustar cualquier tipo de componente personalizado, o si aún no existía, lo construíamos en React y luego lo usábamos dentro de las lecciones dentro de la estructura de MDX. ¿Eso es todo? ¿MDX resolvió todo? Gracias por venir a la charla TED. Bueno, no realmente, por supuesto. Rápidamente encontramos obstáculos con la escalabilidad. ¿Por qué? Porque estábamos gestionando todos estos archivos markdown localmente. Tenía docenas, si no miles técnicamente, de lecciones de archivos MDX individuales que estábamos almacenando localmente. Cada vez que quería reutilizar una lección en otro curso, tenía que copiar y pegarla. No es realmente un sistema intrincado que nos permita reutilizar lecciones o contenido específicos. Las cosas rápidamente se volvieron bastante desordenadas.

Los archivos se multiplicaron, el tamaño de la aplicación creció, y la experiencia del desarrollador se fue por la ventana. Decidimos re-arquitecturar todo. En lugar de archivos y carpetas, comenzamos a pensar en términos de entidades y relaciones. Primero, moví todos los archivos MDX fuera del repositorio al bucket de AWS S3, lo que hizo que las actualizaciones de contenido fueran independientes de los despliegues. Se obtienen bajo demanda y se renderizan en tiempo de ejecución, no en tiempo de construcción, porque cuando los teníamos localmente, las construcciones tardaban mucho en completarse. Luego construí un modelo simple de cómo podemos estructurar todas esas lecciones. La pieza más pequeña es el archivo MDX, y lo llamamos una pieza de contenido, que es solo un archivo individual almacenado en S3. Luego tenemos módulos, que son esencialmente colecciones de piezas de contenido, y luego cursos, que son colecciones de módulos. No más duplicación. Los cursos podían reutilizar módulos, y los módulos podían reutilizar piezas de contenido. Así que en lugar de copiar y pegar contenido por todas partes, esto nos dio una verdadera reutilización. Como la composición de componentes en React, pero para contenido.

Luego las cosas fueron bastante simples en ese punto, pero decidí llevarlo un paso más allá desarrollando algo que llamamos rutas de aprendizaje. La forma en que funcionan es que los usuarios realizan encuestas cortas y comparten sobre qué quieren aprender y en qué etapa de su ruta de aprendizaje se encuentran en este momento. Basado en eso y en su stack tecnológico deseado, luego podemos generar programáticamente rutas personalizadas, mezclando todo lo que hemos hablado hasta ahora, lecciones individuales de MDX, módulos y cursos, todo junto para formar una ruta de aprendizaje lineal dependiendo del estado actual del usuario y hacia dónde quieren ir. Si lo piensas, se trata de composibilidad en React. Al igual que en React, podíamos reutilizar, sobrescribir y evitar cualquier tipo de duplicación. La conclusión aquí es que debes tratar el contenido como datos estructurados, no como código estático. Y nuevamente, esto no solo es aplicable a LMSs, esto es aplicable a cualquier tipo de aplicación pesada en contenido. Así que en este punto, la arquitectura se sentía simple, finalmente tenía sentido, pero eso tomó muchas iteraciones para hacerlo bien.

Pero finalmente estábamos en una etapa donde se sentía bien. Así que déjame contarte un poco más sobre cómo funcionaba la arquitectura y cómo se sentía. Todo vive dentro de un monorepo. Así que decidimos usar una estructura de monorepo gestionada con TurboRepo, lo que realmente nos dio una experiencia de desarrollador increíble con almacenamiento en caché de compilaciones y paquetes compartidos que podíamos reutilizar. ¿Reutilizar dónde? Donde lo dividiremos en dos partes diferentes. El lado de administración para análisis y creación de contenido, y el lado del usuario para navegación, aprendizaje y seguimiento del progreso. Así que pudimos reutilizar estas diferentes piezas de UI, así como la lógica, a través de ambas plataformas dentro de este monorepo.

El stack principal es, por supuesto, React 19. Pero como un marco de trabajo full stack para React, fue Next.js en este caso. Luego Postgres como una base de datos relacional, Drizzle ORM para modelado de esquemas, TRPC y Zod para APIs completamente seguras en tipo que nos permitieron conectar dos partes diferentes de nuestro monorepo. Y luego Tailwind y el chatCN para componentes compartidos. Este stack podría parecer familiar si ya has oído hablar del stack T3. ¿Cuántos de ustedes han oído hablar de este stack o lo han usado o han usado al menos algunas piezas de este stack en sus aplicaciones? Bien, puedo ver algunas manos aquí. Así que es bastante popular y es increíble para prototipar aplicaciones rápidamente y llevarlas al mercado para que puedas probarlas y prototiparlas. En este caso, para nosotros con Zod y TRPC, eso ha sido un cambio de juego porque obtuvimos seguridad completa en tipo a través de ambas aplicaciones con iteraciones rápidas y código de pegamento mínimo que tuvimos que agregar para que todo funcionara junto. Así que simplemente se sentía bien.

Y esta arquitectura nos permitió añadir características adicionales a la plataforma en sí. Fue muy fácil agregarlas. Así que una de las primeras características que resuelve el problema que mencioné al inicio, que es la rigidez de las plataformas de aprendizaje típicas, queríamos agregar sandboxes de código, que son básicamente como playgrounds interactivos que puedes agregar o ahora incrustar directamente dentro de lecciones individuales. Esto nos permitió tener código en vivo sin configuración y sin cambio de contexto. Si presentábamos un video sobre algo al inicio, podíamos inmediatamente luego seguir con eso y las personas podían probarlo. Los estudiantes podían experimentar con el código y ver vistas previas en vivo directamente dentro de la lección que estaban aprendiendo. También queríamos ayudar a los usuarios a retener lo que aprenden. Así que después de cada lección, generamos un cuestionario corto para permitirles simplemente recapitular lo que aprendieron. Y aquí, usamos un poco de IA porque, sí, ¿qué sería una aplicación sin IA en estos días? Pero nuevamente, no solo lo agregamos por el hecho de agregarlo. Lo usamos donde realmente tenía sentido. Así que le proporcionamos los detalles del video y la transcripción y le pedimos que luego generara buenas preguntas y las presentara a las personas instantáneamente. Esto funcionó increíblemente bien. A la gente le encantó. Así que estábamos viendo inmediatamente alrededor de 1500 cuestionarios completados diariamente.

Y parece que a los usuarios realmente les gustó ese resumen rápido después de una lección de 30 minutos. Para análisis, utilizamos PostHog. Creo que en este punto, además de Google Analytics, es una de las mejores plataformas de métricas amigables para desarrolladores. Lo usamos para rastrear todo. Así que rastreamos clics, eventos, eventos personalizados, repeticiones de sesiones, mucho de ello. Y rápidamente se volvió abrumador.

Solo porque PostHog te permite agregar todos estos diferentes paneles con métricas, agregamos cada uno de ellos. Estábamos trabajando con muchas piezas de datos, pero nos excedimos. No podíamos dar sentido a esos datos porque recopilamos demasiado. Finalmente trajimos a un especialista en crecimiento que luego nos ayudó a simplificar y enfocarnos en estos pasos accionables.

Porque como desarrolladores, tal vez no deberíamos enfocarnos en tratar de hacer cada pieza nosotros mismos. Por supuesto, si tenemos la oportunidad de que alguien más dentro de la empresa lo haga, deberíamos enfocarnos en lo que hacemos mejor, que es el desarrollo. Una vez que simplificamos los datos, empezaron a tener más sentido. Así que pudimos tomar decisiones más informadas sobre los tipos de características o tipos de contenido que queremos agregar a nuestra aplicación. Y esto fue genial.

Así que en este punto, hemos elegido nuestro sistema de entrega de contenido como Markdown. Lo hemos hecho escalable al alojar esos archivos en otro lugar y creamos un sistema que funcionó. Y también teníamos análisis y todas estas plataformas interactivas que van a facilitar que los futuros desarrolladores aprendan sobre algo. Así que una interfaz de usuario limpia, toneladas de características. Estaba funcionando genial. Y dado que tenemos una gran audiencia de desarrolladores, estábamos más o menos listos para lanzarlo.

Preparamos algunos materiales. Lo compartimos a través de un boletín. Y la gente rápidamente comenzó a llegar. Pero una vez que hicimos el despliegue y compartimos el enlace, esperamos. La gente parecía amar la idea. Pero luego dijeron que se siente lento. Cuando intentamos agregar tantas de estas características, de alguna manera pusimos el rendimiento en un segundo plano. Solo estábamos tratando de llenarlo con muchas características. Pero luego, sí, resultó ser lento.

En mi máquina, funcionaba bien. Pero una vez que lo probamos en redes más lentas, dispositivos más antiguos, la realidad golpeó. Las páginas de aterrizaje, para algunos usuarios, tardaron unos 10 segundos en cargar. Las páginas de lecciones, unos 15, porque tenían ese enorme archivo Markdown con diferentes elementos interactivos. Fue embarazoso. Estos son tiempos muy terribles. Pero eso sucedió porque intentamos encajar tantas características sin necesariamente pensar en el rendimiento al mismo tiempo, lo cual es algo que nunca deberías, obviamente, hacer.

Especialmente porque Next.js, de manera predeterminada, y React hoy en día, con React Server Components, te da un conjunto de herramientas de diferentes cosas que puedes intentar usar de inmediato para mejorar la carga. Como SSR, SSG, ISR, React Server Components, pre-renderizado parcial. Todas estas herramientas están a nuestra disposición. Pero la elección de cuáles deberíamos usar no es binaria. Lydia dio una gran charla justo antes de hoy, hablando sobre React Server Components y React Compiler. Y hay muchas cosas diferentes que podemos hacer si sabemos cómo usarlas correctamente. Pero mi error fue intentar renderizar todo del lado del servidor. El SEO va a ser genial. Los tiempos de carga deberían ser geniales. Pero ese no fue el caso.

Muchas cosas estaban sucediendo en el servidor, bloqueándonos para devolver los datos, y simplemente no estaba funcionando bien. Así que tenemos que ser estratégicos sobre la renderización del contenido, no solo pensar en términos de cliente versus servidor. Así que lo mapeamos, o los componentes en las páginas, por intención. Así que renderizamos en el servidor las lecciones para beneficios de SEO, para que la gente pueda buscar a través de todo el contenido que creamos. Renderizamos en el cliente el progreso, los comentarios, la búsqueda, y todo con lo que el usuario interactúa. Y luego renderizamos completamente de manera estática las páginas de marketing.

Además de eso, también agregamos muchas estrategias diferentes para mejorar aún más el rendimiento. Agregamos React Suspense Boundaries para dividir la renderización en islas asíncronas, así que tal vez podamos mostrar algo en la parte superior, mientras el resto de la parte aún se está transmitiendo. Eso también ayudó mucho con el rendimiento. Usamos el useHook de React 19 para la hidratación progresiva sin bloqueo de diseño. Esto mejoró aún más el rendimiento.

Por supuesto, optimizamos los activos, convertimos cada PNG o JPEG en un WebP, y precargamos los que aparecen por encima del pliegue, y luego cargamos de manera diferida los que aparecen por debajo del pliegue. Algunas cosas que deberíamos hacer antes de lanzar cualquier tipo de aplicación. También deshabilitamos la precarga de Next.js para evitar descargar páginas enormes de manera preventiva, porque nuestros MTXs tenían muchos enlaces dentro de ellos y la plataforma estaba súper interconectada. Detrás de escena, Next.js estaba precargando muchas cosas, así que tuvimos que deshabilitarlo. Y luego, más adelante, tal vez hagamos una precarga basada en la intención en lugar de simplemente precargar todo.

Así que el resultado es que pasamos de FCPs de 4.6, así que el primer Contentful Paint, una vez que algo aparece en la pantalla, y el mayor Contentful Paint de aproximadamente 8 a 10 segundos. Y una tasa de rebote muy, muy alta, porque los desarrolladores son, si vamos a ser honestos, un público muy exigente y quieren que las cosas se carguen muy rápido y que funcionen sin problemas. Así que mucha gente simplemente dejaba el sitio sin siquiera intentar registrarse. Y eso está bien. Tiene sentido, ¿verdad? Pasamos a aproximadamente 0.5 segundos en FCP, 1.5 segundos a LCP, y la tasa de rebote disminuyó significativamente, lo que significa que las personas estaban más comprometidas con la aplicación y la usaban con más frecuencia.

Lo cual creo que es una gran lección. Todos lo sabemos. Cuanto más rápida es la aplicación, la tasa de rebote va a bajar, pero realmente muestra cuán importante es para las aplicaciones orientadas al usuario. Y logramos eso sin pre-renderizado parcial, que también agregaremos pronto. Era una nueva característica de Next.js, pero aún no actualizamos a la última versión de Next.js. Parecen estar saliendo cada vez que abro Twitter. Así que tomará algún tiempo para que actualicemos a la última versión para poder usar esto. Pero el punto de la historia aquí es que el renderizado no debería ser binario. Debería ser estratégico. Realmente deberías pensar en cómo quieres renderizar contenido específico y qué obstáculos creará eso para renderizar otras piezas de contenido en la misma pantalla o en otras pantallas. Así que en este punto, todo está funcionando bien y el rendimiento fue solo una pieza del rompecabezas. Pero debajo de todo, teníamos una pregunta. Y es cómo realmente hacemos mejor la educación en codificación en línea. El objetivo no era solo agregar tantas características como fuera posible. Es hacer que el aprendizaje se sienta como construir aplicaciones. MTX nos dio esa base. Composable, reusable e interactivo. La pila de la que hablamos también ayudó con eso, nos permitió escalar y movernos rápido. Y funcionó bien. Muy pronto pudimos alcanzar 100,000 usuarios en el primer mes, 18,000 rutas de aprendizaje creadas, y miles de desarrolladores aprendiendo diariamente. Así que pasamos por un par de obstáculos, pero al final del día, es un proceso continuo.

Y vamos a seguir mejorándolo y trabajando en cosas nuevas. Por ejemplo, el próximo desafío es la retención. Así que ahora que realmente estamos logrando que los usuarios entren y prueben la plataforma, tenemos que hacer que se queden. Tenemos que proporcionar suficiente valor para que tenga sentido para ellos volver. Vamos a abordarlo desde un punto de vista de ingeniería, no solo como un líder de producto, sino tratando de hacer tal vez lo que Duolingo hace mejor. Puntos, rachas, insignias. Realmente aprendimos que la gente quiere tener algún tipo de rachas. Quieren tener empujones inteligentes. Así que si están inactivos, les enviamos un correo electrónico y los traemos de vuelta. Y queremos crear algunos bucles de retroalimentación porque incluso esos pequeños reenganches, cuando se acumulan, tienen un gran impacto. Así que estos son algunos de los próximos pasos porque aprender tal vez no es como Netflix. Tienes que poner algo de esfuerzo para que la gente quiera venir y ver la próxima lección.

Sí. Así que para concluir la charla, quiero resumirla en un par de conclusiones clave. La número uno es que la arquitectura importa. Así que comienza escalable desde el primer día. Claro, no va a ser perfecto. Algunas cosas tendrán que ser ajustadas, pero comienza con algo escalable en mente y construye sobre eso. La segunda es que el renderizado es estratégico. SSR, del lado del cliente, híbrido. Realmente deberías abordarlo desde un punto de vista estratégico, no solo tomar una decisión u otra. Hablando de análisis, mide lo que importa, no todo. Porque si pudieras recopilar muchas piezas de datos, simplemente no podrías darles sentido a todas. Así que más bien comienza pequeño, crea un par de embudos y rastrea solo los puntos clave que importan para tus usuarios y tu plataforma. Y luego, ve la retención como un problema de ingeniería. Trata de idear sistemas dentro de la aplicación para que realmente hagas que la gente quiera volver. Nuestro objetivo siempre fue no solo enseñar, sino construir experiencias que permitan a las personas seguir construyendo cosas adicionales. Y si esta charla te ayuda a construir algo así también, entonces valió la pena. Así que eso es todo de mi parte. Gracias.

Tenemos bastantes. Voy a empezar desde el principio. Sí, suena bien. Así que, de alguna manera, aprendiste mucho. Hablaste sobre tu viaje de aprendizaje, cómo abordaste el aprendizaje de cosas, y a menudo la retrospectiva es 20-20. Así que vamos a retroceder en el tiempo. Si fueras a empezar de nuevo con tu nuevo conocimiento, ¿qué cambios harías en el stack? En el stack. Bien, eso es interesante. El stack evolucionó con el tiempo. Así que inicialmente comenzamos con un stack T3 básico, pero eventualmente creo que usamos Prisma. Nuevamente, nada malo en contra. Pero cambiamos a Drizzle. Parece que más desarrolladores ahora están cambiando a Drizzle, no es algo importante. Pero sí, como dije durante la charla, el TRPC y el Drizzle y esa seguridad de tipos, así que con TypeScript definitivamente hizo una gran diferencia. Así que definitivamente comenzaría con esos ahora mismo. Eso tiene sentido.

Y algo que en la siguiente pregunta, de alguna manera hablamos es los desarrolladores, vamos a estos sitios web, muchos de nosotros, somos muy conscientes de la privacidad. Y no solemos permitir cookies. Usamos navegadores web que, si acaso, lo hacen más difícil para los creadores, para los desarrolladores rastrear las métricas en los sitios web que construimos. Entonces, ¿cómo puedes rastrear las métricas necesarias? Esto viene de Nico JS, así que gracias por la pregunta. Es una gran pregunta. Así que también usamos Google Analytics. Si queremos eventualmente emparejarlo con Google Ads, simplemente lo hacen una necesidad para hacerlo. También usamos PostHog, como mencioné. PostHog tiene algo llamado seguimiento sin cookies, que te permite eludir algunas de las cookies completamente de manera legal, por supuesto. Así que creo que manejan la mejor parte de eso, permiten rastrear adecuadamente incluso sin bloqueadores modernos. Y también es realmente interesante con las cookies porque hay muchas cosas que probablemente no son geniales desde una perspectiva de privacidad, pero solo saber cómo un usuario usa tu propio sitio web, no es una invasión de privacidad en muchos aspectos a veces. Sí, los datos pueden ser aleatorizados. No tienes que obtener los nombres o los correos electrónicos, puedes tomar solo los IDs y luego darles sentido más adelante a escala global, como estadísticas, en lugar de solo casos de uso individuales.

Y esta es otra buena pregunta, y nos lleva de vuelta a la parte de las métricas, que es como, ¿qué tienes en marcha para asegurar que los usuarios realmente están aprendiendo y no solo tropezando? Así que tuvimos una gran charla de Matthias antes sobre cómo usan métricas para cuantificar un poco la psicología humana. ¿Tienes algo similar o tal vez incluso diferente? Sí, esa es una gran pregunta. En este momento, no. Pero definitivamente suena como algo que tendría sentido implementar algún tipo de comprobaciones, ¿verdad? Los cuestionarios podrían ser un punto que no les permita avanzar hasta que respondan esas preguntas, ¿verdad? Pero a veces es difícil porque los desarrolladores a menudo solo quieren acelerar para hacer algo, así que se saltan cosas y no queremos bloquearlos si ya conocen algún contenido del que han aprendido antes, ¿verdad? Absolutamente. Nosotros los desarrolladores, es un público difícil para construir, ¿verdad? Público súper difícil. Sí, mientras hablo con muchas herramientas de desarrollo diferentes que también publicamos en el canal, las personas de dev real, las personas de marketing, me dicen que los desarrolladores son el público más difícil de comercializar. Me gusta porque me da un trabajo. Sí, exactamente. Y lo mismo para nosotros. No intentamos comercializar a los desarrolladores, intentamos acercarnos a ellos a través de la educación. Así que nuestro objetivo es siempre proporcionar valor, enseñarles algo. Y luego les damos valor, aprenden sobre ello, eventualmente van a terminar usándolo dentro de sus herramientas. Y esa es la manera de llegar a los desarrolladores, no a través de publicidad pagada o marketing. Sí, eso tiene sentido. Eso tiene sentido.

Y el último. ¿Cuál fue el problema más común para el rendimiento degradado cuando estás renderizando todo en el servidor? Es como la primera victoria fácil para la gente. La primera victoria fácil es no renderizar todo en el servidor, ¿verdad? Inicialmente, especialmente con Next.js, el renderizado del lado del servidor, básicamente, lo hicieron la opción predeterminada. Todo se renderizaba en el servidor por defecto. Pero tienes que entrar y ajustar algunas cosas un poco, renderizar algo en el cliente, tal vez, especialmente si es interactivo porque pone mucha carga en el servidor, especialmente para archivos MDX pesados que tuvimos que traer de vuelta. Así que simplemente no era la mejor opción. Nuevamente, intenta ser un poco estratégico. Intenta no necesariamente renderizar todo en el servidor. Bueno, esa fue una manera muy articulada de decir que depende. Si quieres hacerle más preguntas, tendrá un espacio en la sesión de preguntas y respuestas de los ponentes, así que definitivamente hazlo. Recuerda, al salir, por favor coloca tus auriculares en la silla en la que estás. Solo ayuda a las personas que vienen después de ti. Y vamos a tener un breve descanso para el café. Vamos a tener muchas charlas durante el resto del día. Así que nos veremos pronto. Gracias a todos. Que tengan un gran día.