La web de Joppy: un proyecto frontend con Next.js

Un proyecto frontend con Next.js que empezó como una idea personal pero se ha materializado en la nueva web de Joppy. Un front end developer que sabe que una web no solo se construye con HTML y CSS… y aprovecha la oportunidad para aprender sobre nuevos elementos y frameworks de JavaScript. Una web a la altura de lo que esperamos en 2023.

Las tecnologías avanzan rápidamente, a veces demasiado desde el punto de vista de los desarrolladores, tanto que una página web por muy bien hecha que esté puede quedar desfasada en pocos años.

En el caso de Joppy, su página web había sido creada hacía aproximadamente 5 años. En aquel momento se utilizaron las tecnologías y el diseño que correspondía a la época pero todo el equipo estábamos de acuerdo en que se acercaba el momento de hacerla de nuevo.

Como surgió la idea de empezar por mi cuenta el proyecto

Hace unos meses empecé a investigar y leer documentación más en profundidad sobre Next.js. Estuve unos días conociendo su funcionamiento y aprendiendo la teoría pero pronto me di cuenta de que necesitaba iniciar un proyecto a modo de práctica (que luego podría ser un proyecto real o no) para entender mejor el funcionamiento del framework.

Decidí comenzar una web personal, una especie de portfolio/cv hablando sobre mis trabajos y mis habilidades como programador. Unas horas después ya me había dado cuenta de que no era buena idea, odio hablar de mi, buscar fotos mías para el proyecto y todo lo relacionado con generarme una marca personal como está de moda ahora. Así que dejé aparcada la idea de momento.

Al poco tiempo escuché en la oficina de Joppy comentar precisamente la necesidad de dar prioridad al proyecto de la nueva web de la compañía. También comentaban que sería complicado por falta de tiempo.

Fue entonces cuando pensé que ya tenía un proyecto perfecto para empezar a practicar con Next.js, la nueva web de Joppy. Así que me puse manos a la obra.

Stack tecnológico utilizado

Tenía claro el framework en el que se basaría pero necesitaba concretar más las herramientas que iba a utilizar.

Typescript

Decidí que programaría todo en Typescript para darle más solidez al proyecto, disminuir la cantidad de errores y facilitarme a mí mismo el trabajo.

✅ TypeScript puede utilizarse en cualquier proyecto creado con Javascript

❌ No se recomienda para proyectos pequeños, pues no sería eficiente en tiempo

✅ Se detectan antes los errores gracias al editor (sin necesidad de compilar)

❌ Aún así, requiere de compilación (JS no lo necesita)

Next.js

✅ Tiempo de carga muy eficiente

✅ Herramienta con mucho soporte de otros desarrolladores

✅ SEO friendly y UX friendly

❌ Muchos se quejan de su forma de enrutar

Tailwind

Para el CSS opté por Tailwind ya que me permitiría aprender una nueva herramienta, al parecer combinaba muy bien con Next.js y en teoría me ahorraría tiempo para la parte de maquetación y diseño.

✅ Da libertad en el estilo ( y lo hace rápido)

❌ Mezcla reglas de estilo con los archivos HTML

❌ Le falta documentación y soporte

Framer Motion

Ya tenía casi todas las herramientas definidas pero como quería una web moderna y adaptada a los tiempos que corren, en el ultimo momento, decidí que usaría Framer Motion para añadir animaciones css y darle a la web un toque dinámico y profesional que encajaría con las tendencias actuales.

El mayor aprendizaje: CSR vs SSR vs SSG

Cuando empecé este proyecto tenía por delante varios aprendizajes. Pero en el que más me quería enfocar fue en diferenciar y entender los tipos de renderizados que existen a al hora de desarrollar una SPA y la combinación de varios de ellos según las necesidades.

Para alguien como yo que ha estado mucho tiempo focalizado en el backend todos estos conceptos sonaban un poco confusos.

En la nueva web de Joppy he usado tres de ellos (CSR,SSR y SSG) y voy a tratar de explicarlos de manera simple:

• CSR: Hasta hace poco ha sido el tipo de renderizado más común. El cliente solicita una página al servidor y este le envía una página en blanco. El navegador (cliente) empieza a ejecutar el código Javascript y a hacer las peticiones necesarias para obtener los datos que necesita mostrar. Con todos los datos obtenidos se renderiza el html en el navegador.

• SSR: El cliente solicita una página. En el servidor se ejecuta el Javascript necesario para obtener todos los datos y montar el HTML. En este caso al cliente se le entrega de una vez el HTML final.

• SSG: En este caso el HTML con los datos obtenidos a través de Javascript se genera en el momento de hacer la build del proyecto, de esta manera cuando el cliente solicite una página se le entregará de inmediato el HTML generado y cacheado en la build.

En el caso de la nueva web de Joppy casi todas las páginas utilizan SSR ya que una de sus mayores ventajas es lo bien que funciona este tipo de renderizados con el SEO.

Pero aunque hasta ahora no había tenido la necesidad de utilizarlo hubo un momento en que entendí que necesitaba SSG para un par de páginas. Si veis la nueva web encontrareis dos páginas que recopilan en un histórico todas nuestras newsletters enviadas hasta la fecha tanto para recruiters como para candidatos.

Estas dos páginas han sido creadas con SSG por varios motivos. El principal es que la obtención de estas newsletters es un proceso lento en el que no nos interesa que el usuario esté esperando. De esta manera se hacen estas peticiones de datos en la build y cuando está todo listo se cachea la página para que el usuario pueda obtenerla de manera inmediata.

El resultado: una nueva web más SEO, más responsive, más Joppy

Después de algo más de un mes llevando el proyecto en privado llegó el momento de, primero compartirlo con Andrés (Head of content) para que me ayudara con el contenido de la página web y después al resto del equipo.

Andrés: “Quise hacer algo de texto que dejara claro lo que ofrece Joppy, sin trampa ni cartón. Para ello me basé en tres premisas. La primera es la filosofía de Joppy, que es entender el código del developer a la hora de buscar trabajo. La segunda es la técnica storybrand, que convierte al cliente en héroe. La tercera es… ¿si existía el clean code por qué no el clean content? Textos sin florituras, directamente al grano, a la esencia”.

Yo había arrancado la idea pero nadie puede hacer un proyecto completo y bien refinado sin la ayuda de su equipo. Necesitaba la ayuda de David (Product designer) para mejorar el diseño, de Felipe (Senior frontend developer) para optimizar el código y corregir algunos bugs que se me habían atascado, de Antonio (Senior backend developer) para conectar el frontend con el backend, de Fiorella (Business Support) para perfeccionar nuestras traducciones al Inglés y de Nico (CEO) y Laura (Talent advocate) que hicieron de QA’s y aportaron nuevas ideas maravillosamente bien.

Después de pasar por manos de todo el equipo este fue el resultado de mi proyecto front end: www.joppy.me

---