Some thoughts on Next.js

~/$: npm run post

We have been using Next.js on our capstone project where we are developing an opinionated project management system. It’s been the foundation for our development allowing us to build towards a performant and feature rich alpha release. However, despite its somewhat old approach to serving content (server-side rendering) the structure, workflows, patterns, and capabilities have been challenging to work with. This technology is probably had the largest learning curve for myself and the rest of my group. Basic features aren’t complicated but building a feature rich web application has its complexities in any framework. These difficulties have made themselves apparent especially while using such a new technology.

~/$: why –file_based_routing

Routing has been a problem with React applications for a long time. Next.js devised their own solution to this with file based routing. File based routing is nice because its simple and intuitive… but the folder structure is anything but. With our project we need to pass IDs, Tokens, and Query parameters into our components and pages and although Next.js has tools for doing this the file structure begins to feel a bit convoluted.

At the time of this blog post this mess is what our routing looks like…

Your will notice a couple of things by just looking at it. Next.js knows what content to render based off the name of the file page.tsx this is nice because its simple, but in practice its hard to work with. In VS code when switching between tabs it can be hard to know which page you are clicking on, it can be hard to search for the page you want, and its a pain to change routing, because you are changing the whole file… this can lead to lots of git conflicts.

~/$: what SSR SSG CSR

In the world of react server components and a shift to the server and the edge the terms, SSR, SSG, and CSR are becoming more important. These concepts are quite confusing.

SSR (Server-Side Rendering)

SSR is similar to a custom suit, designed to fit each request flawlessly. When a user visits a page, the server generates the HTML dynamically based on the current state and data, ensuring that the material is fresh and up to date. It improves initial page load performance and benefits SEO by presenting search engines with a fully rendered page.

SSG (Static Site Generation)

SSG, on the other hand, resembles a rack of ready-to-wear clothing. The HTML is pre-built throughout the construction process, ready to be pulled off the shelf and provided immediately. This strategy is ideal for pages that don’t change frequently, as it provides lightning-fast delivery without the need for dynamic rendering every time.

CSR (Client-Side Rendering)

CSR is the IKEA of rendering strategies, with the server sending a flat-pack of JavaScript and files and the browser assembling the page. This method shifts the rendering workload to the client, enabling for more interactive and dynamic user experiences. However, it can result in slower initial load times and may not always work well with search engine crawlers.

These concepts where a learning curve for me and my group it took use time to understand them, build features with them, and research them to feel comfortable with the concept.

~/$: score.py technologies.txt

Its not been all difficult technologies like Vercel have made it stupid easy to prototype, build, ship, test and deploy our project to the web. Next.js as a framework is slowly becoming more mature and as our skills within our team get better so will the framework.

The choice to use React, Tailwind, and Shadcn UI has made it a breeze iterating on features and moving quickly. We will have to wait and see what our final project looks like but overall things are coming along nicely.

~/$: ./move_forward.sh

As we negotiate the maze of current web development using tools such as Next.js, we are reminded of the significance of designing our projects to scale gracefully. The learning curve for Next.js is steep, but so are the benefits. It drives us to think critically about our architecture, optimize for performance, and maintain a strong SEO focus.

Whether we’re dealing with SSR’s personalized responses, SSG’s off-the-shelf speed, or CSR’s do-it-yourself interaction, the tools we utilize impact the user experience. And in this dance of simplicity and complexity, we’re not simply developers, but architects, creating digital experiences with every line of code.

Print Friendly, PDF & Email

Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *