Entrevista a GUILLERMO RAUCH, CEO de Vercel ▲ 💬

Estamos hoy con Guillermo Rauch, creador de Socket.IO y de Mongoose. Gracias por eso, por cierto. Fundador de Lirn, Boost y CloudApp, que adquirió Automattic, la empresa de WordPress, y hoy CEO y cofundador de Site, ahora Vercel. Muchas gracias por regalarnos un poquito de tu tiempo, Guillermo, y bienvenido. ¿Cómo estás? ¿Qué tal todo?

Muchas gracias. Muchas gracias. Muy entusiasmado.

La primera pregunta es un poco obligada. ¿Cómo llevas el confinamiento? Porque estamos todos pasando por esto.

Sí, mira, últimamente acá en San Francisco está siendo un toque más fácil. Han levantado algunas de las restricciones. Cuando salgo a correr noto que hay más actividad, más gente corriendo, mucho uso de mascarilla. Creo que la gente lo está llevando bien, en forma responsable. Mi opinión medio controversial es que me parece que tuvimos una overcorrection un poco. Porque en San Francisco en particular muy, muy pocos casos, la verdad, por suerte. Pero bueno, llevándolo adelante como se puede. Nosotros como compañía remota, la verdad lo llevamos muy bien. Al principio, obviamente, con todo lo sorprendente que fue todo, nos costó un poquito reacomodarnos, a pesar de que físicamente no nos teníamos que reacomodar tanto. Tenemos una oficina acá en San Francisco, muy poca gente, y después todo el team es remoto. Entonces reacomodarse era más mental, reacomodamiento mental que físico. Pero después, la verdad, lo llevamos adelante muy bien. Colaboramos muy bien en forma remota, así que por ahora todo bien.

Guillermo, o sea, es que lo lleváis tan bien, tan bien, que me gustaría felicitarte a ti y a todo el equipo por los 21 millones de dólares que habéis conseguido en esta ronda de inversión. Que bueno, me parece espectacular que estamos aquí todos confinados y vosotros traéis esta pedazo de noticia. Que bueno, enhorabuena, ¿no? Muchas felicidades.

Bueno, mira, cuando fue la peor semana de la pandemia acá en Estados Unidos, que los mercados estaban prendidos fuego, todos nosotros estábamos mirando nuestras propias métricas y era todo lo contrario, ¿viste? Era récord de uso de los builds, de concurrencia. Tráfico. Entonces era, siempre nos pasó esto de que, bueno, por un lado obviamente distintos sectores de la economía están muy impactados, pero lo que hacemos nosotros, que es de alguna forma hacer a la gente que incluso en muchos casos salvar costos, ¿no? Hablamos con muchísima gente que convierte su frontend en Jamstack con Next.js y ahorra muchísimo dinero que antes lo tenía en servidores. Entonces siempre tuvimos esta dualidad de que, por suerte, somos una compañía que estaba muy bien parada yendo a una situación como esta. No tan bien como Zoom, que bueno, crecieron 100 veces en una semana o lo que fuera, que fue como diseñado para la pandemia, pero semejante, viste, con el tema de los hyperlinks y hacer la colaboración más rápida. Ahorrar costos en servidores, en edge y todo eso. Así que por suerte estamos entusiasmados.

En este punto tengo que decir que un poco de cara a mi propia empresa, una de las primeras acciones fue de dónde podemos recortar costes. Y lo has clavado porque es justamente eso, ¿no? Era ¿y qué podemos hacer? Bueno, pues vamos a intentar hacer menos cosas en el backend y que sean archivos estáticos, pues para que la factura—

Seguro, seguro. Y cosas que antes, viste, uno capaz decía bueno, no, esto no lo caché, o lo que fuera. Obviamente si uno ya piensa de infraestructuras del comienzo, es como que eso lo recibe gratis. Pero si uno se pone a pensar bueno, ¿dónde recorto costos? Pasa mucho con las clouds, viste, que tienen esos modelos on demand. Amazon, por ejemplo.

Exacto.

Ahora hay compañías enteras dedicadas a cómo optimizar costos de AWS, pues se te va de las manos. Por eso eso fue un feedback que recibimos mucho en la compañía, que nosotros arrancamos con ese modelo on demand, pero el feedback que recibimos era que a la gente le daba estrés, viste, tener que estar todo el día mirando si vas a tener un spike. Eso fue medio el, digamos, el arma de doble filo con respecto a serverless, que podés recibir cualquier spike, todo escala, pero a la gente le da ansiedad. Entonces ahí es cuando pensamos el nuevo pricing, que para la gran mayoría de las empresas del mundo nosotros podemos predecir, bueno, mira, te va a costar este precio fijo y vas a poder escalar, escalar, escalar, y después crece con el tamaño de tu team. Entonces con eso le ahorramos estrés a la gente muchísimo, que ese estrés que hoy en día AWS, Google Cloud y Azure es tan grande que estamos viendo el surgimiento de una nueva industria dedicada a cómo optimizo y compañías que te ponen dashboards de cómo evoluciona el costo. Y bueno, nosotros esas las tenemos que usar, pero por suerte nuestros clientes no.

Claro, cost explorers, vamos, eso es lo que dices, como un nuevo profile que necesitas en tu propia empresa, ¿no? Porque claro, eso se te puede disparar.

Es como observabilidad de las métricas de HTTP, pero ahora tienes que observar spikes en costos, tienes que observar, tienes que debuggear de dónde viene. A veces la información es insuficiente y bueno, por eso es lo que estamos viendo, es este surgimiento de Layer 2 Clouds, ¿no? Vercel, Netlify, etcétera, son Layer 2 Clouds. O sea, hay un montón de complejidad debajo, pero puedes crear una nueva experiencia de usuario por arriba.

Claro, es una abstracción, ¿no? Te abstraes de esa complejidad que está muy bien el serverless, pero necesitas una abstracción porque si no te puedes perder Yo en Amazon Web Services, es una brutalidad. Sobre esto tengo una curiosidad muy buena y un aviso para mucha gente. Y es que resulta que en Amazon, cuando tú creas una Lambda, el log que te crea no vence nunca. Entonces, claro, ese log en realidad tiene un coste que puede ser muy poco, pero imagínate que es una Lambda que se ejecuta por cada request que llega a tu web.

Entonces, no sabes lo que aprendimos de logging en Fun for Sale, ¿no? Ves de todo, ves ese problema, ves diferentes volúmenes, ves logging en sí. Es algo que uno no lo piensa al comienzo. Ah, eso es fácil. Ah, qué bueno, me viene el logging integrado, etcétera. Pero sí, eso que está diciendo mucho tiene que ver con este tema de que hay ciertos defaults que uno imagina, viste. Bueno, por supuesto necesito logging y logging no debería costar mucho. Y después cuando te sorprende más tarde, ¿viste? Bandwidth es lo mismo. Bandwidth es un universo de complejidad enorme. Ingress, egress, optimizaciones entre availability zones, optimizaciones entre data centers. Amazon to Amazon es más barato que Amazon to Google Cloud, ¿viste? Pero bueno, todo eso, nuestra tarea es tratar de remover todo eso, ¿viste? Y que la gente pueda, nosotros lo que siempre decimos, crear páginas, ¿viste? Porque Medio con Next.js, la idea fue, la gran idea de Next.js que le ha dado la popularidad que le dio, yo creo, yo siempre se lo atribuyo al sistema de páginas, ¿viste? Cuando vos empezás un proyecto con Create React App te dice que hay una sola página y a mí siempre eso me llamó mucho la atención porque yo decía, pero el mundo mismo piensa todo en páginas, ¿no? Este mismo software que estamos usando ahora, streamyard.com, barra, una página. Y entonces yo siempre digo, nosotros no estamos haciendo platform as a service, nosotros estamos haciendo Pages as a Service. Creo que el propósito de lo que quiere la gente es muy sencillo, es publicar páginas de internet. Y de alguna forma lo hicimos muy complejo, eso con la clave es muy potente, muy poderoso, pero al fin y al cabo es publicar URLs a internet. Y eso en sí, el espíritu de eso es sencillo y debería ser muy sencillo, ese proceso de publicar páginas de internet. Obviamente con más poder, ¿no? Porque Squarespace también hizo muy fácil publicar páginas, pero esos sistemas, viste, para los desarrolladores nos quedamos siempre cortos. Entonces es esa tarea de buscar esa flexibilidad entre, bueno, quiero que se sienta tan fácil como presionar un botón y publiqué mis páginas de internet, y sin embargo quiero más poder, quiero poder de ejecutar funciones, quiero poder de ¿Viste? Renderizar en forma diferente, estático, dinámico, etcétera. Y creo que bueno, eso es lo que hemos solucionado bastante bien con Next.js por ahora, que es darle esa dualidad, ¿no? Un poco de flexibilidad y después facilidad de uso.

Totalmente. Me gusta una cosa que has comentado porque estábamos hablando del pricing, que hace poco habéis estrenado uno y está muy bien, ¿no? Porque justamente yo creo que uno de los grandes éxitos que ha tenido en su momento Site y ahora Vercel es justamente ese pricing que empieza en 0 y que ha ayudado a tantos miles, a mí mismo personalmente, y miles y miles de frontends, sobre todo frontends, a publicar su proyecto. Hay grandes proyectos que han empezado así, como puede ser Carbón, que empezó con el de 0 y ahí están. Y que realmente habéis empujado a una comunidad entera a publicar realmente páginas.

Sí, por eso, de hecho, una de las cosas que nos dijimos es mira, cuando vos usás sitios como GitHub o GitLab, etcétera. Cuando vos estás en tu ámbito personal y de experimentación, es gratuito e infinito. Después, cuando vos lo llevás a un entorno profesional y trabajás con un equipo, bueno, ahí es cuando realmente pagás. Entonces, con el nuevo pricing eso es exactamente lo que queríamos. Yo quiero que cuando vos creás un pasaporte de desarrollador, es decir, cuál es tu identidad de desarrollador, Y de hecho, una de las cosas que estamos planeando es ir más este sistema de vista, de poder incluso compartir tus proyectos que has creado como si fuera tu portfolio, que es semejante a lo que Figma está haciendo con los diseñadores, es lo que queremos hacer con los developers. Por eso el entorno personal de Vercel ahora es ilimitado prácticamente. Obviamente hay ciertas restricciones de seguridad y abuso para nosotros Pero queríamos que cuando un developer está pensando en cuál va a ser la tecnología que va a utilizar a futuro, o está haciendo una contribución open source, o está pensando en experimentar con nuevas tecnologías, eso tiene que ser gratuito de por vida. Y además, y otra, esta es una ventaja que tenemos sobre el modelo de GitHub en general, es que tiene que funcionar para siempre. Esa es una de las grandes premisas que siempre quisimos tener con el tema de los deployments. Cuando vos creas un proyecto en GitHub, capaz pasan 6 años y no funciona más porque te lo bajás, lo clonás, ejecutás yarn y ya no funciona. Y esto es algo que con Jamstack y serverless a mí me entusiasmó mucho siempre esta tecnología porque es esa posibilidad de que Vos creás un proyecto y eso tiene que funcionar de por vida. Entonces tratar de aproximarnos a este modelo de, bueno, cuáles son los modelos económicos que pueden soportar ese sistema y cuáles son los modelos de programación que pueden soportar ese sistema. Eso es lo bueno de Jamstack, que de una forma lo que logra hacer ese modelo es transferir el cómputo del servidor al cliente, ¿no? Porque con las PWAs, por ejemplo, o sitios Jamstack, uno hace el build, prerenderiza muchísimo el sistema, lo cual lo hace muy barato para distribuir, ¿no? Porque al fin y al cabo estás distribuyendo HTML ya hecho.

No hay nada más rápido que un estático.

Exacto, que lo hiciste una vez y se lo repartiste a todo el mundo. Ahora, y después, cuando tienes que hacer algo más dinámico le transferiste la factura de electricidad al usuario en su casa, lo cual para proyectos que están recién empezando y son más chicos es un modelo increíble. Claro, ahora cuando pasas al tier pro y cuando pasas a hacer cosas más importantes, ahí sí podés hacer cosas más exóticas, no, pero la idea es poder alinear el modelo de cómo hacer un proyecto hoy que funcione y escale perfectamente hoy y en 10 años. Y eso es lo que hemos encontrado, que la verdad está funcionando muy, muy bien. Y bueno, como te decía antes, lo gracioso para nosotros fue que estaba surgiendo la pandemia y en una semana es como que todos los developers del mundo se sentían motivados a tratar de contribuir de alguna forma. Y empezamos a ver esta explosión de nuevos proyectos relacionados con coronavirus, de todo tipo de grupos, entornos, compañías. GitHub mismo, ellos, GitHub está usando nuestra plataforma, trabajando con researchers para deployar un sistema de creación de modelos para coronavirus online. Compañías y grupos de research, incluso individuos. Creo que se crearon en un momento 2500 proyectos en una sola semana. Lo publicamos en verself.com para el blog, para COVID, creo. No, sí, para COVID. Igual después lo podemos juntar al podcast. Y la verdad fue increíble ver ese poder de un developer solo poder llegarle a millones de personas. Algunos de estos proyectos están hoy en día todavía en el récord de los proyectos más visitados de la semana en Vercel. De la cantidad de gente que les está llegando es la verdad increíble. Y bueno, eso es medio lo que hace años nosotros nos propusimos hacer, ¿no? ¿Cómo podemos hacer que una herramienta que el developer individual pudiera utilizar y sin tener que consultarle a nadie publicar a internet y llegarle a todo el mundo. Y de una forma u otra, coronavirus ha demostrado que esto ha sido posible.

Además, súper rápido, con SSL, que siempre ha sido súper problemático desde la línea de comandos. Es solo un comando y ya lo tienes en internet con SSL, súper bien optimizado. O sea, que realmente es una de las cosas que nos llama mucho la atención, porque yo me cuento como ellos porque soy frontend. Y además estabas comentando lo del coronavirus y lo de los proyectos. Y yo mismo hice uno que también subía a Now, en ese momento, ahora Vercel. Hablando un poquito de esto, hay una cosita que tengo que decir sobre el tema de la inversión que me ha sorprendido mucho y creo que es muy positivo por vuestra parte, de que hay 3 nombres propios que llaman mucho la atención, que es Pete Hunt, Jordan Walke, que son creadores de React, y luego Nat Friedman, que es el CEO de GitHub. Y es como decir, vaya, Esta gente lo que nos está intentando decir es que confían tanto en esto que están invirtiendo. Y es como que están dando la confianza de que esta es la pieza correcta. Si tienes una aplicación con React y la quieres poner a disposición de la gente y tu código está en GitHub, pues ahí tienes tu ecosistema. O sea, es—

Sí, la verdad, eso fue un voto de confianza muy grande. Y por ejemplo, Pete Hunt, bueno, Jordan Walser, el creador de React. No, y es obviamente una de las mentes más brillantes del mundo. Pero lo de Pete Hunt es muy interesante también porque Pete Hunt fue la persona que tomó React y lo usó para hacer una aplicación entera, porque él crea Instagram Web con React entero. Y algo que es muy interesante, quizás la gente no sabe, es que en tecnología Siempre es todo muy bottoms up, ¿no? Siempre es yo propongo una idea y se la tengo que justificar a mi team. Y estoy seguro que hay muchísima gente que nos está escuchando que está peleando con algún jefe, manager, etcétera. No, pero pongamos eso en Vercel o usemos Next.js. Y algo que es muy interesante es siempre hay que, todo hay que sustanciarlo y justificarlo y de alguna forma como venderlo. No hay nada en tecnología que salga en forma de dictadura. A veces hay, pero esos teams no retienen a sus ingenieros. Entonces, algo que pasó en Facebook es que Jordan, Pete, Seth, Mark Pitsch, toda la gente que estaba laburando, que estaba entusiasmada por React en el comienzo, tuvieron que convencer al resto de Facebook. No fue que llegaron un día y dijeron: Hablé con Dios y me dio los 12 mandamientos de programación reactiva funcional, ¿viste? Entonces ellos era como que tuvieron que probar, justificar, adoptar incrementalmente, que es algo que para nosotros siempre fue un gran valor porque nosotros sabíamos cómo era esa historia, ¿viste? De que las tecnologías tienen que poder ser incrementalmente adoptadas. Claro. Y algo que pasó es que Pete Hunt fue el primer breakthrough de decir bueno, voy a usar React para todo, no solo para un pequeño componente adentro del newsfeed, viste. Que ese fue el caso original de Facebook y fíjate que le ha llevado años poder usar React para todo, que es lo que están haciendo ahora con el nuevo Facebook. Y todavía estoy casi seguro que no está roleado para todos los millones de usuarios que tienen. Entonces eso fue lo mismo que nosotros pensábamos con Next.js. Era React, tiene que ser la tecnología que corre todo, no solo un pequeño componente, un widget, el newsfeed, un botón, el badge de notificaciones. Para mí React es tan buena como tecnología que tiene que poder correr todo. Entonces eso es algo que fue una gran validación porque Pete Es una persona que fue pionera en eso, ¿no? De decir, mira, yo me la juego por React para que pueda correr todo Instagram. Y eso, Instagram es un producto también con billones de usuarios. Y fíjate que Instagram tiene un modelo JAMstack. Eso es muy interesante también, ¿no? Cuando vas a instagram.com, lo voy a abrir ahora para confirmarlo, lo primero que ves es el loguito de la cámara de Instagram. O sea, te dio un payload estático, prácticamente estático. Si uno inspecciona el source va a ver que hicieron inlining de data y lo que fuera. Después carga JS y se renderiza. Entonces cuando uno se hace la pregunta: ¿JAMstack escala? No hace falta ver, ir a Instagram. O se hace la pregunta de: ¿React escala? Hace falta ir a twitter.com O Instagram.com aparece React Scala. Entonces eso fue una gran validación del equipo, de la parte del equipo de inversión. Y obviamente esta gente es la que no, de alguna forma ellos invierten porque no para hacerse ricos, en muchos de estos casos ya son increíblemente ricos, sino que quieren ver ese producto que ellos mismos querrían usar. Quieren ver ese producto que sus compañías querrían usar. Pues lo otro decía de GitHub, que es muy interesante, es GitHub es uno de nuestros clientes porque ellos necesitan hacer deploys, ellos necesitan hacer nuevos proyectos, incluso ellos quieren usar Next.js. Tienen un monolito Ruby on Rails bastante viejo pero continuamente nos dan feedback de Next.js porque lo están usando para cosas nuevas. Por ejemplo, la UI de GitHub Actions está toda potenciada por Next.js, el design system que están haciendo, los componentes son compatibles con Next.js, son componentes React de Primer. Así que eso es un gran, gran backing, la verdad, y siempre nos pone muy contentos. Al mismo tiempo, nosotros somos una compañía que está tan enfocada en el cliente y en el producto que para nosotros inversión es muy importante, pero al mismo tiempo es— tratamos de olvidarnos un poquito, ¿no? Claro. Bueno, eso fue, es un milestone. Pero hay cosas mucho más importantes, que es para mí siempre es ese foco en el cliente, no siquiera es en el producto tanto, porque el producto siempre es una respuesta a lo que nos pide el cliente, o cómo hacer que el cliente esté más contento. Es inventar en base al cliente, no inventar, viste, en un una caverna y salir con la invención, dice.

Totalmente. O sea, si tienes al usuario en el centro, al final seguro que vas a acertar, vas a estar siempre alineado con lo que necesita el cliente. Por lo tanto, es un win-win. O sea que me parece que es una estrategia muy buena. Hay una cosita que ha venido con la inversión también, que ha sido un cambio de nombre. Me imagino que te han preguntado 80 veces. Estaba buscando 80, 80, 80.000, pero creo que es una de las cosas, tengo que decir, que demuestra el cariño que la comunidad le tenía a XITE, ¿no? Y es que Twitter se ha llenado de mensajes y de memes tristes por el cambio de nombre. Hasta el creador de JavaScript.

Yo me imaginaba que iba a ser, que iba a dar para hablar, ¿viste? Pero no me imaginaba que iba a tener ese tipo de impacto, ¿no? De 80 veces por día y 80 veces Yo el otro día hacía un chiste a mis colaboradores de voy a salir de mi casa y me va a estar esperando alguien para hacer un comentario sobre eso, ¿viste? No, pero tu apreciación es 100% acertada. Es en definitiva algo muy positivo porque demuestra esa conviction que la gente tenía sobre nosotros y Mira, como muy bien vos dijiste ya, o sea, y cuando mismo en esta entrevista dijiste site, dijiste now, y hay muchísimo que este nombre da para hablar, pero algo que es, ahí hay una parte creativa y hay una parte táctica, ¿no? La parte táctica que a mí me encanta es que buscamos algo que trajera esa simplicidad que tiene el producto a una marca unificada. Y en vez de Site y Now, y Site Now, ahora es Vercel. Y otra cosa que es uno de los grandes valores que tenemos nosotros, porque la realidad es que nuestro producto tiene dos partes. Uno lo puede pensar como cliente y servidor. Next.js y otros frameworks como Next.js son como el cliente open source, y después hay una plataforma que está completamente distribuida a través del mundo. Y el negocio está basado en esa plataforma y está basado en la escalabilidad de esa plataforma, porque la plataforma tiene que funcionar también como un proyecto hobby que recién arrancó, como para los clientes más grandes que tenemos que producen millones de hits por hora. Entonces uno de los grandes valores que tenemos como compañía es reliability, que es la fortaleza de la plataforma. Y muchísimo de lo que hemos hecho no se ve, no se ve. Por ejemplo, la cantidad de código que hemos escrito para lidiar con spikes de tráfico, resolver ataques, firewall, etcétera, etcétera. Y el nombre en sí mismo tenía que llevar y transmitir ese valor. Y algo que los nombres tienen, cuando nosotros hablamos con lingüistas, es que los nombres en sí mismos tienen reliability. Y cuando vos pensás cómo escribir y escuchar un nombre a través de distintos idiomas en el mundo, queríamos que ese valor de reliability fuera persistido por el nombre. Entonces el nombre tiene ese valor de ingeniería que es tan importante para nosotros. Y eso es algo que a mí me— yo sabía que iba a ser controversial, pero sé que a la larga nos va a dar ese, nos va a ayudar a transmitir ese valor a muy gran escala. Esa posibilidad de incluso poder escucharlo y escribirlo con facilidad o googlearlo con facilidad. Entonces como que el nombre anterior no encajaba en ese esquema, ¿viste? Era como para transmitir que esta compañía va a ser una roca sólida de simpleza y facilidad y escalabilidad. Y al mismo tiempo lo escuché y no sé escribirlo, ¿viste? Pero tenía ese valor, Guillermo Rauch, contribuir. Y obviamente hay varios motivantes para el nombre. Pero ese es uno de que, a pesar de que generó controversia, yo siempre estaba muy anclado en esa realidad de mira, esto es algo que va a ser muy positivo para el mundo. Entonces, pudimos llevarlo adelante con bastante eficacia. Y la verdad es que mira, la publicidad es así, ¿no? La gente está hablando. Yo siempre decía a mi team, acuérdense que cuando Slack rotó el logo 15 grados. Yo me acuerdo la controversia de internet era semejante, ¿viste? Era cómo puede ser que Black rotó el logo, ¿viste? Y bueno, sí, los primeros días son muy controversiales, pero en definitiva después las cosas se calman y ya los resultados de esa inversión que hicimos se están llevando, se están notando, ¿viste? Y a la gente en definitiva le gusta mucho.

Al final lo vamos a adaptar. A mí me parece un nombre muy bonito y además me ha encantado tu explicación y de verdad me parece que tiene todo el sentido del mundo. No había pensado en eso, de que os queréis asegurar que sea una marca que independientemente del lenguaje sepas más o menos cómo escribirlo.

Exactamente. Fue analizado en 5 idiomas, 5 expertos lingüistas de distintas lenguas del mundo. O sea, es parte arte y parte ingeniería, que es mucho lo que tratamos de hacer con la compañía. ¿No? Que hay mezcla. Exactamente.

Muy bien. Decía que eso, que Brendan Eich, el creador de JavaScript, incluso decía: para mí siempre seré Scythe. Y hay alguien en Twitter, es que imagínate, o sea, es que es verdad, es una pasión. Decía por aquí uno en Twitter, Andrés, decía: tengo sentimientos encontrados, Scythe se había metido en el corazón de mucha gente.

Sí.

Pero guau, es que, y os dice al final que estáis haciendo historia, lo cual tengo que corroborar, que sí, que creo que estáis haciendo historias sobre todo para la comunidad de Frontend. Supongo que obviamente el cambio de nombre no va a ser el único cambio que vais a tener en la empresa y me imagino que tenéis nuevos planes para acompañar.

Siempre hay step functions, ¿no? Del día a día, a mí me gusta mucho lo que dice siempre Sam Altman de que the days are short, sorry, the days are long and the decades are short. En el día a día es siempre trabajar en torno a esa función que hablábamos antes, que es bueno, qué podemos hacer para facilitarle la vida a los developers, a los clientes, etcétera. Pero uno hace zoom out y empieza a notar que están estos cambios que son step function, viste, que no puedo creer que estemos en este estadio. Nos pasó el otro día que hicimos un onboard de un cliente que tiene un sitio Next.js y lo pasó a nuestra plataforma, que es enorme. Y nos avisaron de un día para el otro, viste. Y en condiciones normales nosotros haríamos esto: ah, bueno, viste, hay que, paremos todo, se viene este cliente, viste. Y pasó así como un no glitch, no hay problemas, completamente smooth, etcétera. Y viste, eso que ahora pasa así tan naturalmente, la cantidad de días largos y largos y largos que nos llevó llegar a ese punto es increíble, viste. Y como bien dijiste, no va a ser el único gran cambio, que parece que es muy, parece que es instantáneo y te lo comes de un día para el otro. Obviamente no van a ser cambios de marca y de nombre y de logo y cosas así, pero se sienten así, se sienten como cambios instantáneos enormes que pasan de un día para el otro. Tienen que ver con financiación, hay veces tienen que ver con el tamaño de los clientes que se suman. Se sumó hace poco Airbnb como cliente de la plataforma y fue también alucinante. Y a veces parece que te despertás un día y pasó eso, pero en definitiva venís trabajando día y noche durante muchísimo tiempo para que esto pase.

Justamente me encanta porque la siguiente pregunta va un poco alineada con esto. Era en noviembre de 2015 nació Sight, que ahora es Vercel. Y casi 5 años después es la mejor plataforma, yo diría, que para hacer despliegue de proyectos de frontend. Y tenéis Next.js, que he leído por ahí que lo usan más de 300.000 desarrolladores y proyectos, lo usan grandes marcas como Airbnb, Nike, TripAdvisor. Hace 5 años, ¿qué pensabas de todo esto? ¿Cuál era tu visión?

En realidad, imposible, imposible. La verdad, o sea, lo bueno es que la visión fue muy consistente. Viste, yo estaba seguro, era una intuición, viste. Yo estaba seguro que deployment no podía ser difícil como lo era en ese momento, viste. Y estaba seguro que, de vuelta, hacer una página con React no tenía que requerir tener un, viste, Degree en Webpack, viste. Entonces, y tenía muchas intuiciones que eran bastante que iba en contra de la marea un poco, viste, porque el tema de pre-rendering muchísima gente en ese momento me decía que no, me decía que el futuro no tenía eso de mezclar la data con el HTML, y me lo decían muchísimos expertos. Me lo decía incluso, esto lo cuento para tu comunidad, no lo he contado mucho, pero yo tuve bastantes roces incluso con Facebook Porque yo tenía ideas muy, muy firmes y medio raras para ellos. Que hoy en día, el otro día le contaba a mi team, Dan Abramov tuiteó que hoy en día la inspiración para mucho de lo que está haciendo React fue el camino recorrido por Next.js. Lo cual es, fíjate, el timeline es rarísimo. Facebook lo inventa, Next.js lo lleva al siguiente nivel y ahora muchas de las ideas de Next.js inspiran a React mismo.

Una retroalimentación increíble.

Y eso yo no me lo podía haber imaginado. Yo tuve una gran ventaja, que es un ejercicio que lo recomiendo muchísimo, de que yo cuando empieza a surgir React, yo soy una persona que siempre tiene que internalizar muchísimo las ideas y creerlas muy firmemente antes de poder distribuirlas, ¿viste? Entonces yo estuve quiet durante muchísimo tiempo con React. Yo no emití opinión, no tuve el knee-jerk reaction que tuvieron muchísimos web devs de: ¿Pero qué estás haciendo? Estás mezclando concerns y todo eso, estás metiendo HTML en el CSS. Pero tampoco tuve la knee-jerk reaction de: Oh my God, I saw the light. ¿Viste? Yo tenía que procesar eso. Y entonces lo que me puse a hacer es yo reescribir React desde cero. Hice mi propio videón, hice mi propio todo, y con eso creé Videopress para WordPress. Yo en ese momento, como dijiste, trabajaba para WordPress porque adquirieron mi compañía anterior. Y cuando escribí Videopress de cero, ahí sí vi the light, porque hacer un video player parece fácil, pero la cantidad de sincronía en realidad te vuelve loco, porque el video se para porque se te paró el stream, o el video se te para porque hay un error y hay que reintentar, o para mientras estamos caídos y reintentamos, se haya caído el stream, el usuario hace seek y hace seek a una parte del video que ya tenemos bafereada, o a una parte que no teníamos bafereada, o hace pausa, o hace el mismo, hay formas de incluso parar el vídeo sin pasar por tu UI. Porque el vídeo del navegador nativo, este vídeo que estamos viendo ahora, puede ser right click y puedes activar loop o puedes activar show controls. Entonces ni siquiera controlas la UI para un vídeo player porque vos tenés tu UI y después el navegador inventó su propia UI. Entonces yo dije holy shit. Esto es, los eventos pueden venir de todo el mundo, hay la cantidad de estados, me vuelve loco. Y yo tengo que hacer que sea robusto, pues se lo tengo que dar este widget de video a todos los usuarios de WordPress del mundo. Entonces ahí dije holy shit. Y algo, imagínate lo bueno que a veces es ser, ¿cómo se llama? Cabeza dura. Yo, por esas casualidades de la vida, pero también obviamente es uno de los beneficios de estar en San Francisco, Yo soy vecino, era vecino muy cercano, incluso ahora más cercano, pero se está mudando a Nueva York ahora, de Sebastian, que laburaba en Reel. Y nos encontrábamos en una cafetería y yo laburaba todos los días de la cafetería, trabajo remoto desde hace 5 años. Ya estabas preparado, Guillermo, Y me lo encontraba a él y yo le decía: "Pará, estoy implementando mi propio Reel para Videopress, etcétera, pero lo que no me cierra es el tema de las clases." le decía yo a él. Y yo no sabía cómo resolverlo. No era que al día siguiente te iba a dar hooks. Y fíjate lo que lleva, por eso "the decades are short and the days are freaking long". Fíjate lo que llevó al team de React poder generar esa, poder concretizar esa intuición, ¿no? De que los componentes tenían que ser funciones. Y eso es algo que yo había logrado para mí versión de React para Android WordPress, no utilizaba clases, pero era muy difícil de usar, no tenía esa facilidad que tienen los— y aparte hay gente que les resultan hooks complicados, no les quiero describirlo cómo yo resolví ese problema, era muy semejante a RxJS y era utilizando valores observables. Pero yo estaba con esa cabeza dura de que no me cerraba el tema de las clases, ¿viste? Porque yo decía, para, lo bueno de React es que puedes hacer este mapping de inputs a outputs y que puedas pensar en funciones. Claro. Y bueno, lo de los hooks ahora me ha resultado una invención increíble. De hecho, si hoy leen en Rauchy.com el artículo sobre Pure UI que yo escribí el 13 de julio de 2015, habla de cómo los designers y developers van a poder colaborar en base a esta muy buena forma de colaborar basada en básicamente inputs y outputs, ¿no? Pues se llama Pure UI, pero también Pure UI en el sentido de lo único que me preocupa es la UI, ¿no? Y hablamos de cómo se generó la compañía Y esta es una de las ideas, ¿no? Que los developers tienen que estar preocupados básicamente por ese problema, ¿no? Que es medio el problema también del designer. Es, yo quiero estar preocupado por el producto, la UI, puramente eso. No servidores, clusters, CDNs, build systems, no. La UI, la data y transformar la data en una representación creativa que es visual, y lidiar con esta complejidad que viene con el territorio de los eventos, los cambios de la información, la evolución de la tecnología, la evolución de los navegadores. Es medio siempre un territorio cambiante. AMP, Lighthouse, es como que las variables del entorno están siempre cambiando y uno se tiene que adaptar rápido. Entonces mira, la verdad es que siempre esa trayectoria de 2015 fue siempre encontrada con desafíos, desafíos de todo tipo, ya sea el mundo no está completamente de acuerdo con nosotros, o la verdad que es difícil generar infraestructura. Yo siempre le digo, hablo mucho con inversores y digo, me llama la atención que haya tantas compañías de CMS, ¿no? Y no haya tantas compañías de infraestructura. Porque en definitiva es un problema muchísimo más interesante del punto de vista económico. Porque CMS, fíjate que hoy en día arrancas una compañía de CMS y ¿cuántas más hay? Hay 15 más. Mientras que generas una compañía de infraestructura para frontend y hay 2, ¿viste? Y la realidad es que es más difícil. Es como, ¿por qué hay una sola compañía de autos eléctricos en Norteamérica? Si vos escuchás a Elon Musk, él te dice cosas más difíciles que ha hecho en su vida, que a veces sentía que estaba agonizando por la complejidad y la dificultad.

Y estamos hablando de una persona que está llevando cohetes al espacio.

Exactamente, o que ya lo hizo con PayPal en medio del dot-com bust, que es como decir, bueno, hice una compañía en medio de una pandemia, ¿viste? Pero ese es el tema, infraestructura es muy difícil, es muy rewarding también. Porque te permite hacer cosas que nadie puede hacer, ¿no? O sea, nosotros, como nosotros tenemos la infraestructura global y tenemos el build system y tenemos el conocimiento del framework que usa el cliente, ya sea Next.js pero también Vue, Gatsby, Svelte, etcétera, nos permite hacer cosas que son imposibles para otras compañías. Optimizaciones, integraciones, UI/UX improvements, etcétera. Que son imposibles, pero lleva ese recorrido. Como dijiste, que es primero lleva tiempo y segundo lleva muchísima inversión. No es que 21 millones de dólares es porque mi cara es linda, viste, es porque realmente trabajos de infraestructura requieren muchísima inversión. Pero bueno, después llegas y tienes esta base sobre la que puedes crear muchísimas cosas interesantes.

Es súper paradójico, Guillermo, de que digamos que os estáis convirtiendo en la plataforma de facto para miles de proyectos de frontend y está construida en muchísimo trabajo de infraestructura y backend.

Exacto. Es bastante irónico, pero de alguna forma te estás sacando ese trabajo de backend, lo cual está bueno porque nosotros hicimos una conferencia y la llamamos Backendless. Que obviamente es medio un nombre provocativo porque obviamente los backend siempre van a existir, pero es cierto, ¿no? Hay muchísimo trabajo que está desapareciendo de backend. Por ejemplo, una de las features que tenemos que genera páginas estáticas incrementales ejecuta, utiliza funciones de Lambda que el usuario nunca escribió. Es alucinante. O sea, vos usás getStaticProps y estás escribiendo el código que se ejecuta at build time para traer la data y generar la página estática. Y después nosotros agarramos ese código y automáticamente creamos una función que puede ser ejecutada por nuestros sistemas para actualizar el contenido de esa página. Eso es código que nadie escribió. O sea, fue código que fue automatizado, fue una función que nadie escribió. Ese tipo de automatización no es que el backend desaparece, eso sería mentir, no, es simplemente que es automatizado. Es medio como los self-driving cars de alguna forma, no, no es que el código desapareció. De hecho, lo que es muy interesante sobre las redes neuronales e inteligencia artificial es que en definitiva están escribiendo código. Es código que fue automatizado, es código que fue derivado de estadísticas. Están todos los if, están todos los while, están por ahí. Y mucho, aparte del trabajo que se está haciendo hoy en día en inteligencia artificial, es poder tratar de debuggear cuál fue el código que fue escrito, ¿no? Y por eso hay gente como Elon que está asustada porque dice, para, estamos generando estas mejoras exponenciales en la calidad del output, ¿No? Porque ahora ponemos la red neuronal y el auto se está manejando y nunca nadie vio el código. Entonces dice, para, eso hace 10 años ni existía, ahora el auto se maneja solo, ¿qué va a pasar en los próximos 10 años? Y vamos a estar siempre en este medio, ¿viste? Caminando sobre este peligroso punto de, ¿viste? Entregué tanto que ahora ni siquiera sé qué código se está ejecutando. Lo bueno de nuestro problema es que uno puede imaginar el código y el código está ahí, ¿no? En el caso de inteligencia artificial, el código ni siquiera se puede leer. Es como que hay que usar un disassembler, ¿no? Sí, sí. Pero mientras los resultados sean los adecuados, ahí obviamente estamos empujando el mundo en la dirección correcta.

Hablando del futuro, hemos hablado un poco del pasado, hace 5 años. Hace 5 años empezó Site. Dentro de 5 años, ojalá tengamos esta misma conversación y podamos estar charlando de esto mismo. Pero, ¿de qué estaremos hablando dentro de 5 años?

Va a ser alucinante, va a ser alucinante. Mira, algo que yo creo muy firmemente y que es una de las— es como arrancó la compañía y creo que va a estar hasta el final de los tiempos, es esa idea de la URL. Que es cuando nosotros divisamos el producto, es mira, vos tenés que poder correr un comando. En su momento era now, ahora es más git push porque estamos más integrados con los sistemas de git, pero sigue la misma idea. Vos ejecutas un comando y recibís la URL. La URL como nexo de la comunicación de todo el mundo, ya sea desarrolladores de frontend que están colaborando entre ellos y dicen mira, acá está la URL. Ya sea entre sistemas, estamos empezando a ver robots hablando uno con el otro. Una de las partnerships que estamos haciendo es con una compañía llamada Checkly, que es, nosotros le damos la URL y cuando creaste el frontend, y ellos van a ejecutar tests automatizados de end-to-end simulando navegadores web a esos frontend. Nosotros hoy en día usamos esta tecnología para probar nuestro frontend y nuestro backend de forma tal que estamos simulando el tráfico del mundo antes de rolear un deploy. Entonces el otro día hablamos entre ellos y decíamos: mira, hay muchísimos de estos tests que los podemos generar con inteligencia artificial. Y empezamos una conversación ahí y dice: wow, entonces vamos a hacer que robots estén hablando con robots. Porque decíamos, si algo sale mal con el test habría que crear un canal de Slack automáticamente en el que el robot diga hay que solucionar este problema y que invite a la gente involucrada en ese cambio al canal de Slack, que traiga al desarrollador experto de esa página, que traiga al desarrollador de backend, etcétera. Entonces la URL es el nexo en la integración de estos sistemas. Ya sea para evaluar que funcionen correctamente, le damos la URL a un sistema de testeo. Ya sea para evaluar la performance, le damos la URL a un sistema que evalúe que la performance se está manteniendo en forma óptima. Ya sea para teams de QA de seres humanos, que decir: mira, estamos por hacer un nuevo release, acá está la URL que va a ir a producción, dame el OK. Mucho del trabajo que estamos haciendo hoy en día tiene que ver no con expandir el producto en forma de, viste, hagamos un nuevo sistema de X y Z. No, es generar, es explotar el valor de esta URL para la integración de sistemas. Mucho tiene que ver con que yo soy muy creyente que una de las grandes ventajas que tenemos es el tema de que llevamos la página de desarrollador a cliente end to end. ¿Por qué? Porque nosotros ponemos la página al lado del consumidor. Nosotros la ponemos en forma voluntaria. No esperamos que el cliente venga y por un CDN que configuraste y que cache control y que miss y que hit. No, es yo quiero que el desarrollador crea la página y se les lleva directo al cliente. Esa ventaja es a nivel económico, a nivel muy, muy alto. Es como pasar de un motor de los años 90 a un motor moderno eléctrico, ¿no? Parece que es lo mismo, ¿no? Si vos mirás, bueno, va el motor adentro del chasis, lo que fuera, pero la diferencia es astronómica. Entonces mucha de la inversión que estamos haciendo hoy en día con Vercel sigue siendo en esta idea de los builds instantáneos de las páginas, pero también llevar la página al lado del cliente en forma push. Y también otra de las cosas que estamos observando muy, muy de cerca es el tema de cómo podemos traer la interfaz del cambio de las páginas más cerca del cliente también. Una de las integraciones que estamos haciendo hoy en día con Sanity y con Tina va a permitirle al cliente cambiar el frontend desde el frontend. Y algo que yo siempre le cuento a la gente, que es muy interesante, es hoy en día la gente que hace memes va, abre DevTools y escribe y cambia una página y le saca un screenshot y es un meme popular. Hoy en día la tecnología ya está para poder hacer estos cambios en forma instantánea, real time. Obviamente no van a ser a través de los dev tools y no van a ser con screenshots, pero la tecnología ya está. Es eso la ventaja de la web, la podemos manipular en forma directa y ya tenemos la infraestructura para hacerlo porque Next.js y React, nosotros ya sabemos cuáles son los puntos de inserción de los cambios. Es como que vos te acordás del atributo content editable, ¿no? Claro. Imagínate que yo pueda ir a cualquier componente de React y decir: este componente tendría que ser editable por mi team de marketing, por mi cliente. Las agencias, ese es un sueño de las agencias, ¿no? Es decir: mira, hice un componente en React, quiero que sea editable por la gente, por el cliente, no por mí, que me tenga que hacer un ticket y que yo pueda editar el contenido. Y la verdad es que estamos muy cerca, no van a ser 5 años. Si vas a next-preview.now.sh, que pronto va a pasar a ser .vercel, uno ya puede testear un prototipo que está en producción, que escala infinito. O sea, no es un prototipo al estilo, es un prototipo al estilo cuando Elon sacó, viste, el primer auto eléctrico, que era, viste, no era para todo el mundo, era para la gente que se inscribía y lo compraba en forma preventiva, pero se lo compraba antes que el resto del mundo. Hicimos un sistema que te permite generar páginas estáticas pero después editarlas y ver los cambios en forma no estática, lo puedes ver en forma síncrona. Y este es el sistema que estamos integrando con todos los CMS del mundo para que cuando vos hagas un sitio le puedas dar al mundo esta capacidad de manipular directamente el contenido. Y la verdad, eso va a ser alucinante, eso va a ser el próximo cambio de que te va a dar 100 veces mejor latencia, ¿no? Porque de alguna forma es cuando vos pensás hoy en día hacer un cambio de tu página web, es un trabajo. Hoy en día con React y con todo esto lo hicimos bastante tedioso, con Git y con los build systems y con todo eso, es tedioso. Pero manipular directamente lo que estoy viendo es alucinante. Entonces en 5 años yo creo que vamos a estar haciendo páginas que sean manipulables directos del frontend con un edit button. Vamos a estar haciendo cambios que se distribuyen a todo el mundo en forma instantánea, pero que retengan esta propiedad tan interesante de Jamstack, que es una vez que se hizo la página ya se distribuye a todo el resto del mundo y es increíblemente barata de distribuir. Y no digo barata Viste, como lo digo en inglés, no sé si en español se hace esta distinción. En inglés, viste, decimos inexpensive versus cheap. Y cheap es medio negativo. Es como decir, ah, esta remera, de hecho, es la remera de Target, es cheap. Como que barato, pero en todos sus sentidos, no solo en de costes. iPhone SE es inexpensive. IPhone sí es un celular increíble, la tecnología es increíble, es inexpensive. A mí lo que me gusta de Jamstack es que es una tecnología que genera muchas cosas que son inexpensive. Cuando vos tenés algo que es estático, lo construís una sola vez y después no tenés que ejecutar ciclos de CPU para regenerarlo y regenerarlo y regenerarlo y regenerarlo. Entonces eso lo que yo veo a 5 años es Las partes de un sitio que sean estáticas van a ser creadas, generadas una sola vez y se van a distribuir por el resto del mundo. Después va a haber partes que no van a ser estáticas, y esa es la realidad del mundo, ¿no? No todo puede ser modelado bajo este, bajo este sistema. Hay cosas que son increíblemente dinámicas y que si vos generás HTML cada vez que se genera el cambio, vas a estar haciendo un montón de trabajo que es completamente innecesario. Porque te convenía hacerlo just in time. Entonces el mundo puede ser modelado bajo este modelo de ahead of time versus just in time.

Yo creo que el reto será la granularidad, ¿no? Es intentar— ahí está.

Exactamente eso. El reto va a ser poder guiar al developer a decidir correctamente: esto tiene que ser hecho ahead of time, esto tiene que hacerse just in time. Y entonces el developer es medio que se convierte en un economista de alguna forma, ¿no? El developer va a tener la inteligencia de decir y las herramientas para poder decir esto se hace con este modelo, esto se hace con este otro modelo. Y bueno, las cosas en definitiva van a ser muchísimo más rápidas, muchísimo más baratas. El developer como individuo le va a poder llegar a más y más y más gente, lo cual va a ser muy interesante. Yo creo que lo que estamos viendo con coronavirus va a pasar a una escala muy, muy grande de poder decir, mira, Hice algo de un día para el otro y revolucionó el mundo. Brutal.

Tengo una curiosidad contigo, Guillermo, que tú a lo mejor no lo sabes, pero el caso es que coincidimos en la Holy JS de Moscú. Estuve allí dando una charla y coincidimos allí justo de hacer la charla de inicio de la feria, que por cierto me gustó mucho. Y tengo que decir que lo pasé fatal, lo pasé fatal, porque cuando saliste y empezaste a charlar de Next.js y un poquito de Jamstack y un un poco de performance sobre todo, mi charla iba casi sobre lo mismo. Y entonces cuando estabas hablando y vi que además mi charla iba justo después de la tuya. Entonces fue como: por favor, que alguien quite a Guillermo ya del stage, que pare de hablar, porque yo he venido desde Barcelona, estoy muy nervioso con el inglés, solo me faltaba que venga Guillermo Rauch a hablar justo de lo mismo que yo para que me entierren aquí. Y bueno, tengo que decir que al final por suerte no iba de lo mismo, sino que iba tú un poco más por el tema de Jamstack y de cómo mejorar la performance, a veces dando cosas estáticas. Y lo mío era más esa granularidad de tener la posibilidad de saltarte la hidratación en React, que es súper costosa. Y teníamos el dynamic rendering, progressive hydration, que es una cosa que ahora React sí que va a meter.

Seguro, eso sigue siendo increíblemente importante para nosotros porque Estoy de acuerdo con vos. El tema de rehidratar todo hace mucho trabajo. De vuelta, es esta idea de si vos puedes extraer partes que son estáticas, uno lo puede pensar que es posible hacerlo para un tree, ¿no? Porque, ¿para qué rehidratas si hay solo un componente adentro que es dinámico? ¿Por qué no hacemos que eso sea un React Root?

Exacto, ahí está. Y mi charla iba sobre esto, porque creé un componente que se llama StaticContent, que cuando envuelves una parte del árbol, pues no le hace la hidratación. Se lo salta. Es muy hacky, es muy hacky, no lo recomiendo. Pero bueno, que me hizo mucha, mucha gracia que coincidimos allí. La verdad es que estuve a punto de saludarte, pero nada, cuando salí a buscarte estabas rodeado de gente y digo, madre mía, es que Guillermo, cómo lo petas hasta en Moscú.

Sí, no, yo trato de hacer eso en las conferencias, trato de que me pierdo las charlas porque trato de, bueno, voy a dar una charla que como este, como lo estamos haciendo ahora, la gente lo puede consumir online igual, ¿no? Entonces, ¿para qué vas a las conferencias? Y trato de pasar tiempo con la comunidad y con la gente. Que fue esa conferencia, fue excelente porque muchas de las preguntas fueron relacionadas no solo con estática y todo eso, que de vuelta eso lo que uno aprende siendo un sitio web, viste. Hace poco, de hecho, rehicimos Next.js nextjs.org/learn, que es para enseñarle a la gente cómo utilizar Next.js. Y lo hicimos de cero y pudimos explicar bien esto de, bueno, empezar con static, y después cuándo uso más cosas dinámicas, etcétera. Uno lo puede explicar online eso. Entonces, ¿cuál es el propósito de esta conferencia? Para nosotros terminó siendo darle a la gente la posibilidad de preguntar cosas que capaz uno no puede preguntar online. Entonces me terminé haciendo un montón de preguntas sobre cómo progresar en la carrera de uno, cómo hacer el, esa de dejar un trabajo de 9 to 5, hacer cosas, viste, más menos tradicionales, más de emprendedurismo. Y fue una gran experiencia porque me encantó ver que En todo el mundo está este sentimiento de la iniciativa y el emprendedurismo, ¿no? Fueron preguntas que las escuchás en Silicon Valley, le hacés la misma pregunta a la gente de Moscú. Y yo creo que ese es el camino, ¿no? Ese es el camino para muchísima gente, es arrancar nuevas cosas. Entonces mucho lo que hacemos nosotros con Versado es, bueno, ahora te estamos dando la plataforma para arrancar más fácil. Ya sea para nuevos proyectos en compañías. Nos pasó el otro día de una compañía muy, muy grande. Es una compañía pública que su punto com no lo están pasando a Vercel, pero están lanzando un producto muy grande, un punto com nuevo que parece ser el futuro de la compañía. Cuando escuchas los reportes del CEO en los quarterly reports, dice: nos la vamos a jugar por esto. Y eso está siendo construido sobre el Versailles. O sea, ni siquiera le ayuda al emprendedor que arranca algo de cero, le ayuda a las compañías mismas a arrancar algo de cero, lo cual es excelente.

Claro, y entregar cuanto antes el producto y no preocuparse en cosas que alguien ya se ha preocupado.

Exacto, llevarlo al mercado.

Exacto, llevarlo cuanto antes. Pues para ir terminando, ya solo un poco alineado con esto, hay que decir, a lo mejor hay gente que no lo sabe, pero empezaste creo que en 2005 y durante 7 años estuviste trabajando en Mutools. En ese momento, aquella competición de jQuery. Entonces, tu trayectoria la verdad es que ha sido espectacular, pero siempre muy cerca del desarrollo y en, la verdad, en proyectos que han tenido un impacto en la comunidad de frontend. Sinceramente creo que ahora multiplicado por 100, ¿no? Ahora lo que has llevado. Entonces, un poco alineado con lo que comentabas, ¿no? Lo que te preguntan muchas veces, ¿qué consejo le darías Con todas tus experiencias que has tenido, con todo lo que has aprendido, ¿qué le dirías a alguien un poco para animarle, para que pudiera tener una línea ascendente como tú en este caso?

Para mí siempre lo más importante fue esta idea del hipervínculo. Y yo siempre digo: el hipervínculo es una tecnología de liberación de alguna forma. Cuando vos haces un demo copado, de hecho he visto muchísimos de los tuyos y creo que así es como yo te conozco a vos. Por haber visto tus hipervínculos. Entonces, por esa capacidad de poder mostrar tu trabajo en forma funcional, para mí es alucinante. Es la tecnología que le permite a alguien llegar de nada a, no sé, a que tu trabajo esté visto por Tim Cook en Apple. Eso es lo que permite hacer el hipervínculo, es literalmente un híper vínculo. Es alucinante, es mejor que time travel, es mejor que nuclear fission, es mejor que todo eso, y lo tenemos hoy en día. Y bueno, ya de la forma que puedas encontrar, generar ese nexo, ¿no? Para mí, en su momento yo tenía un blog llamado Dev Thoughts que me permitía mostrar ese trabajo. Hice un proyecto llamado Fancy Menu, que era un menú que parecía que estaba hecho en Flash, pero está hecho en JS, porque en ese momento había que derrocar a Flash. Y yo así le llegaba al mundo. Yo estaba en Argentina, no me conocía ni el vecino, especialmente el vecino, porque yo no salía nunca de mi casa, entonces le digo a mi computadora seguro que el vecino no me conocía, pero no me conocía nadie. Pero yo ahí estaba sacando esos hipervínculos de cualquier cosa, mientras sea algo muy pequeño, pero muy en Argentina no sé si esa palabra, pero muy guay, muy cool. Ya hablo español en distintas lenguas. Ya sea que puedas sacar eso, es increíble los vínculos y las posibilidades que genera. Algo que estoy viendo que me resulta increíble es #100DaysOfCode en Twitter. Se está generando como esta comunidad de gente que puede conectarse a una misma letra y mostrar eso que está haciendo en forma inmediata, y se autodesafían entre ellos a siempre mostrar, mostrar, mostrar. Entonces, participar de esos proyectos me parece una de las mejores formas de avanzar una carrera en forma cuántica, digamos. O sea, es una forma que pasa un salto cuántico, ¿no? Uno puede estar aprendiendo y metido muy profundo en un tutorial, pero es como que te quedás encerrado ahí. Pero cuando empezás a mostrarle al mundo, ya sea en Twitter con el hashtag #100DaysOfCode o con hipervínculos, y de esto se trata, ¿no? De hecho, yo creo que esto está yendo más allá de lo que pasó con GitHub y los repositorios, porque es lo que decía antes, si yo muestro un repositorio No sé, no sé si estoy tan— puedo mostrar un montón de código, pero no sé si me convence tanto. De vuelta, ponerte en los zapatos de alguien que es un cliente, ¿no? O alguien que puede apreciar lo que has construido. Y algo que funcione y se vea tiene muchísimo más valor para mí que una abstracción. Y de hecho se trataba ese Ese ensayo que escribí sobre Pure UI, que medio fue ahora mirando hacia atrás, medio fue lo que yo estaba pensando, ¿no? Esta idea de focalizarse más en el diseño, focalizarse más en el frontend, focalizarse más en el outcome del producto, que medio generó esta trayectoria.

Pues Guillermo, no te quito más tiempo, de verdad. Muchísimas gracias. Estoy muy agradecido por el tiempo que nos has dedicado. Por tu energía, por tu enseñanza y sobre todo por todo el trabajo que haces, que está bien que tenga éxito porque ayudas a un montón de gente y a la comunidad frontend. Así que te agradezco muchísimo que te hayas pasado por aquí.

Muchas gracias.

Ha sido un verdadero placer. Guillermo, te deseo los mejores éxitos, no solo a ti, sino a todo el equipo de Vercel con el nuevo nombre, con los nuevos inversores y con las nuevas ideas estratégicas que vais a tener. Espero que nos podamos volver a ver pronto. Si no, es la holy yes de Moscú, seguro.

En Moscú, en Saint Petersburg, en España, en algún lado.

Y así podemos charlar de ese español que tienes, que veo que ya lo tienes muy trabajado, con el cual... Bueno, de verdad, muchísimas gracias, Guillermo. Ha sido un verdadero placer. Muchas gracias. Hasta luego. Y hasta aquí la entrevista a Guillermo Rauch, cofundador y CEO de Vercel. Muchísimas gracias. Gracias, Guillermo, muchísimas gracias por dedicarnos una hora y por haber sido tan honesto y habernos enseñado tanto. Yo personalmente he aprendido un montón, me ha encantado, me ha encantado conocer a Guillermo, saber más de su visión, saber pues cómo ha sentido esta evolución de site ahora a Vercel. Y es que al final el impacto que tiene es enorme. Para mí personalmente, que todos mis proyectos, mi blog incluso, es que está hospedado en Berzel. Me ha parecido pues muy bien poder conocer a Guillermo mejor y saber un poquito qué es lo que piensa que nos va a venir en el futuro de Frontend y de su compañía. Y si a ti te ha gustado, pues te pido que le des like, que le des like al vídeo, que le des like a Guillermo, por supuesto que te suscribas al canal, que lo compartas, compartas el vídeo y que lo comentes, que sigamos un poquito con la discusión para que esta entrevista pues no se quede aquí, sino que terminemos de escribirla entre todos. Así que espero de corazón que te haya gustado tanto como a mí esta entrevista a Guillermo, y nos vemos en el siguiente. Seguimos aquí en el canal, en VideoDev, para seguir con el frontend. Hasta luego.