Estamos hoy con Guillermo Rauch, creador de Socket.io y de Mongoose,
gracias por eso, por cierto, fundador de Lean, Boost y CloudApp,
que adquirió Automatic, la empresa de WordPress,
y hoy CEO y cofundador de Sight, ahora Vercell.
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á haciendo 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 con 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, ¿no?
Que estamos aquí todos confinados y vosotros traéis este 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 o Next.js
y ahorra muchísimo dinero que antes lo tenían 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.
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, ¿no?
Una de las primeras acciones fue, ¿de dónde podemos recortar costes, no?
Seguro, seguro.
Y es que 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 se hagan archivos estáticos, pues para que la factura...
Seguro, seguro.
Y cosas que antes, ¿viste?
Uno capaz de decir, bueno, esto no lo callé o lo que fuera.
Obviamente, si uno ya piensa de esta arquitectura desde el comienzo,
es como que eso lo recibe gratis.
Pero si uno se pone a pensar, bueno, ¿dónde recortó 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, ¿viste?
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, ¿no?
Que podés recibir cualquier spike, todo escala, pero a la gente le daba 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, viste, dashboards
de cómo evoluciona el costo.
Y bueno, nosotros esas las tenemos que usar, pero por suerte nuestros clientes no.
Claro, con los explorers, damos, eso es lo que dices,
es como un nuevo profile que necesitas en tu propia empresa, ¿no?
Porque, claro, es que eso se te puede disparar, pero sobre...
Es como observabilidad de las métricas de, viste, HTTP,
pero ahora tienes que observar, viste, spikes en costos,
tienes que observar, tienes que vaguear 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?
Exacto.
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 abstrae 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, o sea, 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 del Login con Russell, ¿no?
Porque ves de todo, ves ese problema, ves diferentes volúmenes,
ves...
Login en sí es algo que uno no lo piensa en el comienzo.
Ah, eso es fácil.
Ah, qué bueno, me viene el Login integrado, etcétera.
Pero sí, eso que estás diciendo mucho tiene que ver con este tema de...
Hay ciertos defaults que uno imagina, ¿viste?
Bueno, por supuesto, necesito Login y Login 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 center, 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 es crear páginas, ¿viste?
Porque medio con Next.js, la idea...
La gran idea de Next.js que le ha dado la popularidad que le dio,
yo creo, yo siempre se lo tributo 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.
Porque 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.
Lo hicimos 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.
Y creo que, bueno, eso es lo que hemos solucionado bastante bien con ACS por ahora,
que es darles esa dualidad, ¿no?
Un poco de flexibilidad y, pues, 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 Sight y ahora Vercell
es justamente ese pricing que empieza en cero euros
y que ha ayudado a tantos, miles, a mí mismo, personalmente, ¿no?
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.
Exactamente.
Que empezó con el de cero euros 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 llevas a un entorno profesional
y trabajas 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 creas un pasaporte de desarrollador,
es decir, cuál es la identidad de desarrollador.
Y, de hecho, una de las cosas que estamos planeando
es ir más a este sistema, ¿viste?
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 Verceller 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, ¿no?
Esta es una de las grandes premisas
que siempre quisimos tener con el tema de los deployments, ¿no?
Que cuando vos creás un proyecto en GitHub,
capaz pasan seis años y no funciona más.
Porque te lo bajás, lo clonás,
ejecutás YARM y ya no funciona.
Y esto es algo que con JAMstack y Serverless,
a mí me entusiasmo mucho siempre es la 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, ¿no?
Que de una forma, lo que logra hacer de 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, pre-renderiza muchísimo el sistema,
lo cual lo hace muy barato para distribuir, ¿no?
Porque al fin y al cabo estás distribuyendo HTML y ya he 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 tenés que hacer algo más dinámico,
le transferiste la factura de electricidad a el usuario de su casa.
Al cliente.
Lo cual, para proyectos que están recién empezando y son más chicos,
es un modelo increíble.
Claro.
Ahora, cuando pasás al Tier Pro y cuando pasás 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 ha hecho 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, 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.
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 2.500 proyectos en una sola semana.
Lo publicamos en Vercel.com para 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 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 alguna 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 a internet.
Con SSL, súper bien optimizado.
O sea, que realmente es una de las cosas que nos llama mucha atención
porque yo me cuento como ello 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.
Pues 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, ¿no?
De que hay tres nombres propios que llaman mucho la atención.
Que es Pete Hunt, Jordan Walk, que son creadores de React
y luego Nat Friedman, que es el CEO de GitHub.
Y es como decir, vaya, o sea, 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.
Sí, la verdad, eso fue un voto de confianza muy grande.
Y por ejemplo, Pete Hunt, bueno, Jordan Walk es 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 y 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 me 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?
No hay nada en tecnología que salga, viste, en forma de dictadura.
Hay veces hay, pero esos teams, viste, no retienen a sus ingenieros.
Entonces, algo que pasó en Facebook es que Jordan, Pete, Seb, Mark Pitch,
toda la gente que estaba laburando, que estaba entusiasmada por React en el comienzo,
lo tuvieron que convencer al resto de Facebook, ¿viste?
No fue que llegaron un día y dijeron, che, 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.
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 billones 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 batch 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, mirá, 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 Jumpstack.
Eso es muy interesante también, ¿no?
Cuando vos 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 pelo 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, che, ¿Jumpstack 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 para saber React escala.
Entonces, eso fue una gran validación 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 casos ya son increíblemente ricos.
Claro.
Sino que quieren ver ese producto que ellos mismos querrían usar.
Exacto.
Quieren ver ese producto que sus compañías querrían usar.
Pues lo otro decía de GitHub que es muy interesante.
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 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 es un milestone.
Pero hay cosas mucho más importantes.
Que para mí siempre es ese foco en el cliente, ¿no?
Si quieres 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 una caverna.
Y es decir, salir con la invención, ¿viste?
Así que...
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.
Exactamente.
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.
He estado buscando...
No, no.
80.
80 por minuto.
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 Sainz, ¿no?
Y es que Twitter se ha llenado de mensajes y de memes tristes por el cambio de nombre.
Hasta el creador de JavaScript.
Hasta el creador de JavaScript.
Yo me imaginaba que iba a dar para hablar, ¿viste?
Sí.
Pero no me imaginaba que iba a tener ese tipo de impacto, ¿no?
De, como decía, 80 veces por día y 80 veces...
Yo el otro día hacía un chiste a mis colaboradores.
Voy a salir de mi casa y me va a estar esperando alguien para hacerme un comentario sobre eso, ¿viste?
No, pero tu precisió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, que cuando, mismo en esta entrevista, dijiste Sight, 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 Sight y Now y Sight 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 tan bien 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?
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 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 algo para...
Quiero 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?
Entonces tenía ese valor que queremos contribuir.
Y obviamente hay varios motivantes, ¿no?
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 podemos 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 Slack rotó el logo, ¿viste?
Y bueno, sí, los primeros días son, viste, 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 nos 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, ¿no?
De que os queréis asegurar que sea una marca que independientemente del lenguaje
sepas más o menos cómo escribirlo, ¿no?
Exactamente.
Fue analizado en cinco idiomas, cinco expertos de lingüistas
de distintas lenguas del mundo.
O sea, es parte arte y parte de ingeniería que es mucho lo que tratamos de hacer con la compañía, ¿no?
¿Qué hay en plan?
Exactamente.
Muy bien.
Él decía que eso, que Brendan Height, el creador de JavaScript incluso decía
para mí siempre seréis site.
Y hay alguien en Twitter, es que imagínate, ¿eh?
O sea, es que es verdad, es una pasión.
Decía por aquí uno en Twitter, Andrés, decía
tengo sentimientos encontrados.
Site se había metido en el corazón de mucha gente.
Sí.
Pero, wow, 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 historia
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 la compañía.
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 functions, ¿viste?
Que, ah, no puedo creer que estemos en este estadio.
Nos pasó el otro día que hicimos un on-board de un cliente
que tiene un sitio en X.js y lo pasó en nuestra plataforma,
que es enorme.
Y nos avisaron de un día para el otro, ¿viste?
Y en condiciones normales, nosotros habríamos estado,
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 y largos
es algo que nos llevó a llegar a ese punto.
Es increíble, ¿viste?
Y como vemos bien, dijiste, este no va a ser el único gran cambio
que parece que es muy, que 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 te parece, te despertaste 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, ¿vale?
Era, en noviembre de 2015 nació Scythe, ¿no?
Que ahora es Vercel.
Y casi cinco 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 cinco 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?
Decree en Webpack, ¿viste?
Claro.
Entonces, y tenía muchas intuiciones que eran bastante,
que iban 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 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 muchos
de lo que está haciendo React fue el camino recorrido
por Next.js, lo cual es, fijate, 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, una retroalimentación.
Es 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ía 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 JS,
pero tampoco tuve la knee-jerk reaction de,
oh, my God, I saw the light, ¿viste?
Sí.
Yo tenía que procesar eso.
Y entonces lo que me puse a hacer es,
yo reescribí React desde cero.
Hice mi propio VDOM, hice mi propio todo.
Y con eso creé Videopress para WordPress.
Yo en ese momento, como dijiste, trabaja para WordPress
porque adquirieron mi compañía interior.
Y cuando escribí Videopress de cero,
ahí sí vi the light.
Porque hacer un videoplayer parece fácil,
pero la cantidad de asincronía en realidad te vuelve loco.
Claro.
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 pará, mientras estábamos caídos y reintentados,
se había caído el stream, el usuario hace sick.
Y hace sick a una parte del video que ya teníamos basfereada.
O a una parte que no teníamos basfereada.
O hace pausa, o hace...
O el mismo...
Hay formas de incluso parar el video sin pasar por tu UI.
Porque el video del navegador nativo,
este video que estamos viendo yo ahora,
puede ser right click.
Y podés activar loop o podés activar show controls.
Entonces, ni siquiera controlás la UI para un videoplayer.
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 es...
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, muy cercano, incluso ahora más cercano,
pero se está mudando a Nueva York ahora,
de Sebastian, que laburaba en React.
Y nos encontrábamos en una cafetería
que yo laburaba todos los días de la cafetería.
Trabajo remoto desde hace cinco años.
Ya estabas preparado, Guillermo.
Y me lo encontraba a él.
Y yo le decía, pará,
estoy implementando mi propio React para Videopress, etc.
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, viste, 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, ¿no?
Fíjate lo que llevó al team de React poder generar esa,
poder concretizar esa intuición, ¿no?
De que los components tenían que ser funciones.
Y eso es algo que yo había logrado para mí.
Versión de React adentro de WordPress.
No utilizaba clases.
Pero era muy difícil de usar.
No tenía esa facilidad que tienen los...
Y aparte, hay de haber gente que le 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, pará, lo bueno de React
es que podés hacer este mapping de inputs a outputs
y que podés 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 routeg.com el artículo sobre Pure UI
que yo escribí en 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?
O sea, 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, ¿no?
De los eventos, los cambios de la información,
la evolución de la tecnología, la evolución de los navegadores.
Y es medio siempre un, ¿no?
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
desde el punto de vista económico.
Porque CMS, fíjate que hoy en día arrancás una compañía de CMS
y ¿cuántas más hay?
Hay 15 más.
Mientras que generás una compañía de infraestructura para front-end
y hay dos, ¿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 que es una de las 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 estaba 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, Gats,
VisVault, 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 vos 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 tenés esta base sobre la que podés 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 backends 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 usas get static crops 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 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 devaguear cuál fue el código que fue escrito, ¿no?
Y por eso hay gente como Elon que está asustada porque dice, pará, 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, pará, 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, dices, sean los adecuados, ahí obviamente estamos empujando el mundo en la dirección correcta.
Sobre, hablando del futuro, hemos hablado un poco del pasado, hace 5 años.
Hace 5 años empezó Scythe.
Dentro de 5 años, ojalá tengamos esta misma conversación y podamos estar charlando de esto mismo.
Pero, ¿de qué estaremos hablando, Guillermo, dentro de 5 años?
Va a ser alucinante, va a ser alucinante.
Mirá, 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, mirá, vos tenés que poder correr un comando.
En ese momento era Now, ahora es más GitPush, 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, mirá, 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 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 esa 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, mirá, hay muchísimos de estos tests que los podemos generar con la inteligencia artificial.
Y empezamos, hicimos una conversación en la que 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.
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, mirá, estamos por hacer un nuevo release.
Acá está el URL que va a ir a producción, dame el ok, tac, tac, tac, tac.
Mucho del trabajo que estamos haciendo hoy en día tiene que ver no con expandir el producto en forma, 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 creciente 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 cash control y que miss y que hit.
No, yo creo que el desarrollador crea la página y se le lleva directo al cliente.
Entonces, 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.
Parece que es lo mismo.
Si vos mirás, bueno, va a leer el motor adentro del chasis y 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 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 interacciones 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 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 hace un meme popular.
Hoy en día la tecnología ya está para poder hacer estos cambios en forma instantánea en real time.
Obviamente no van a ser a través de los DevTools y no van a ser con screenshots, pero la tecnología ya está.
Eso es la ventaja de la web.
La podemos manipular en forma directa.
Y ya tenemos una infraestructura para hacerlo porque en 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 el cliente, no por mí, que me tenga que hacer un ticket y que yo pueda editar el contenido.
Y la verdad es que esto estamos muy cerca, no van a ser cinco años.
Si vas a next-preview.now.sh, que pronto vas a pasar a ser .versell, uno ya puede testear un prototipo que está en producción, que escala a 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 de forma, o sea, no 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.
Los 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 que hoy en día con Rigia, que con todo esto, lo hicimos bastante tedioso.
Con Git y con los Build System y con todo eso. Es tedioso.
Pero manipular directamente lo que estoy viendo es alucinante.
Entonces, en cinco años yo creo que vamos a estar haciendo páginas que sean manipulables directos desde el 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 distribuyó a todo el resto del mundo y es increíblemente barata de distribuir.
Y no digo barata, viste, como 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 una remera de Target, es cheap.
Como que es barato, pero en todos sus sentidos, no solo de costes.
iPhone SE es inexpensive. iPhone SE es un celular increíble. La tecnología es increíble. Es inexpensive, though.
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 es lo que yo veo a cinco años, es las partes de un sitio que sean estáticas van a ser 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 sistema. Hay cosas que son increíblemente dinámicas y que si vos generás HTML cada vez que se genera el cambio,
te 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 resto 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 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 HolyGS de Moscú.
Estuve allí dando una charla y coincidimos allí, justo dice, 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 NextGS y un poquito de Jamstack y 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 quita 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 estuve 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 va a meterse.
Seguro, eso sigue siendo increíblemente importante para nosotros, porque estoy de acuerdo con vos.
El tema de rehidratar todo, hace mucho trabajo.
Exacto.
De vuelta, es esta idea de si vos puedes extraer partes que son estáticas.
Exacto.
Uno lo puede pensar que es posible hacerlo para un trick, ¿no?
Porque para qué rehidratas si hay solo un componente adentro que es dinámico.
¿Por qué no hacemos que eso sea un React Brute?
Exacto.
Ahí está.
Y mi charla iba sobre esto porque creé un componente que se llama Static Content,
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 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 lo que 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,
esa conferencia fue excelente porque muchas de las preguntas fueron relacionadas
no solo con static y todo eso, que de vuelta, eso es lo que uno aprende yendo a un sitio web, ¿viste?
Hace poco, de hecho, reicimos Next.js.org para learn, que es para enseñarle a la gente
cómo utilizar Next.js.
Y lo reicimos de cero y pudimos explicar bien esto de, bueno, empezar con static,
y después cuándo uso más cosas dynamic, etc.
Entonces, uno lo puede explicar online eso.
Entonces, ¿cuál es el propósito de estas conferencias?
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, ¿viste?
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,
las hace las mismas preguntas 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 de lo que hacemos nosotros con Vercel 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 .com no lo están pasando a Vercel,
pero están lanzando un producto muy grande, un .com nuevo,
que para ellos es el futuro de la compañía.
Cuando escuchás los reportes del CEO en los quarterly reports,
dicen, nos las vamos a jugar por esto.
Y eso está siendo construido sobre Vercel.
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, ¿no?
Y no preocuparse en cosas que alguien ya se ha preocupado.
Y llevarlo en el 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 siete 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 cien, ¿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,
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, ¿no?
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 el Tim Cook en Apple.
Eso es lo que permite hacer el hipervínculo.
Es literalmente un hipervínculo.
Es alucinante.
Es como, 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 DevThought,
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 estaba 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,
me iba a hacer un problema con la computadora,
seguro que el vecino no me conocía,
pero no me conocía a nadie.
Pero yo ahí estaba sacando esos hipervínculos.
De cualquier,
mientras sea algo muy pequeño,
pero muy,
en argentino no sé si es 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 Hundred Days of Code en Twitter.
Se está generando como esta comunidad de gente que puede conectarse a una misma
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,
un salto cuántico,
¿no?
Uno puede estar aprendiendo y metido muy profundo en un tutorial,
pero es como que te quedas encerrado ahí.
Pero cuando empezás a mostrarle al mundo,
ya sea en Twitter con el hashtag Hundred Days of Code,
o con hipervínculos,
y de esto se trata,
¿no?
De hecho,
yo creo que hasta está yendo más allá de lo que pasó con GitHub y los repositorios.
Porque es lo que te 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.
Claro.
De vuelta,
ponete 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 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,
¿qué medio que 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 Vercell,
con el nuevo nombre,
con los nuevos inversores,
y con las nuevas ideas y estrategias que vais a tener.
Espero que nos podamos volver a ver pronto.
Si no,
es la Jolly Yes de Moscú.
Seguro.
En Moscú,
en St. 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 mejor 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 Vercell.
Muchísimas 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 cómo ha sentido esta evolución de Scythe,
ahora Vercell.
Y es que,
al final,
el impacto que tiene es enorme.
Para mí,
personalmente,
que todos mis proyectos,
mi blog incluso,
está hospedado en Vercell,
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
del Fronten
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,
Guillermo,
y nos vemos en el siguiente.
Seguimos aquí,
en el canal,
en VidoDev,
para seguir con el Fronten.
Hasta luego.
¡Gracias!