A frontend project with Next.js that started as a personal idea but has materialized in the new Joppy website. A front end developer who knows that a web is not only built with HTML and CSS… and takes the opportunity to learn about new JavaScript elements and frameworks. A web at the height of what we expect in 2023.
Technologies advance rapidly, sometimes too fast from the point of view of developers, so much so that a website, no matter how well done it is, can be outdated in a few years.
In the case of Joppy, its website had been created about 5 years ago. At that time they used the technologies and design that corresponded to it, but the whole team agreed that it was time to do it again.
How did I came up with the idea of starting the project on my own
A few months ago I started researching and reading more in depth documentation about Next.js. I spent a few days getting to know how it works and learning the theory but soon I realized that I needed to start a project as a practice (which later could be a real project or not) to understand better how the framework works.
I decided to start a personal website, a kind of portfolio/cv talking about my work and my skills as a programmer. A few hours later I had already realized that it was not a good idea, I hate talking about me, looking for pictures of me for the project and everything related to generate a personal brand as it is fashionable now. So I shelved the idea for the time being.
Soon after, I heard in Joppy’s office commenting precisely the need to prioritize the project of the new website of the company. They also commented that it would be complicated due to lack of time.
It was then when I thought that I had a perfect project to start practicing with Next.js, the new Joppy’s website. So I got down to work.
Technological stack used
I was clear about the framework I was going to base it on but I needed to be more specific about the tools I was going to use.
Typescript
I decided that I would program everything in Typescript to make the project more robust, decrease the amount of errors and make it easier for myself to work.
✅ Typescript can be used in any project created with JavaScript.
❌ It is not recommended for small projects, as it would not be time efficient.
✅ Errors are detected earlier thanks to the editor (no need to compile).
❌ Still requires compilation (JS does not need it).
Next.js
✅ Very efficient loading time
✅ Tool with a lot of support from other developers.
✅ SEO friendly and UX friendly
❌ Many complain about their routing.
Tailwind
For CSS I opted for Tailwind as it would allow me to learn a new tool, apparently it combined very well with Next.js and in theory it would save me time for the layout and design part.
✅ It gives freedom in styling ( and does it fast).
❌ Mixes styling rules with the HTML files.
❌ Lacks documentation and support
Framer Motion
I already had almost all the tools defined but as I wanted a modern website adapted to the current times, at the last moment, I decided that I would use Framer Motion to add css animations and give the website a dynamic and professional touch that would fit with the current trends.
The greatest learning: CSR vs SSR vs SSG
When I started this project I had a lot of learning ahead of me. But the one I wanted to focus on the most was to differentiate and understand the types of renderings that exist when developing a SPA and the combination of several of them depending on the needs.
For someone like me who has been a long time focused on the backend all these concepts sounded a bit confusing.
In the new Joppy website I have used three of them (CSR, SSR and SSG) and I will try to explain them in a simple way:
- CSR: Until recently it has been the most common type of rendering. The client requests a page from the server and the server sends a blank page. The browser (client) starts executing the Javascript code and making the necessary requests to get the data it needs to display. With all the data obtained, the html is rendered in the browser.
- SSR: The client requests a page. The server executes the Javascript necessary to obtain all the data and assemble the HTML. In this case the final HTML is delivered to the client at once.
- SSG: In this case the HTML with the data obtained through Javascript is generated at the time of building the project, so when the customer requests a page, the HTML generated and cached in the build will be delivered immediately.
What rendering have we used at Joppy?
In the case of the new Joppy website almost all pages use SSR because one of its biggest advantages is how well this type of rendering works with SEO.
But although until now, I had’nt had the need to use it there was a moment when I understood that I needed SSG for a couple of pages. If you look at the new website you will find two pages that compile in a history all our newsletters sent to date for both recruiters and candidates.
These two pages have been created with SSG for several reasons. The main one is that obtaining these newsletters is a slow process in which we do not want the user to be waiting. In this way these data requests are made in the build and when everything is ready the page is cached so that the user can get it immediately.
The result: a new website more SEO, more responsive, more Joppy.
After a little more than a month of taking the project private, it was time to first share it with Andrés (Head of content) so he could help me with the content of the website and then with the rest of the team.
Andrés: “I wanted to make some text that would make clear what Joppy offers, without any catches. I based it on three premises. The first is Joppy’s philosophy, which is to understand the developer’s code when looking for a job. The second is the storybrand technique, which turns the client into a hero. The third is… if clean code existed, why not clean content? Texts without frills, straight to the point, to the essence”.
I had started the idea but no one can do a complete and well refined project without the help of his team. I needed the help of David (Product designer) to improve the design, Felipe (Senior frontend developer) to optimize the code and fix some bugs that had stuck, Antonio (Senior backend developer) to connect the frontend with the backend, Fiorella (Business Support) to refine our English translations, Nico (CEO) and Laura (Talent advocate) who did QA’s and contributed new ideas wonderfully well.
After passing through the hands of the whole team this was the result of my front end project: www.joppy.me
Leave a Reply