Next.js 14: A Game-Changer for Front-End Development!

Vercel recently released the NextJs 14 Stable version as a serve-client front-end framework.

But we are more interested how this will change the web development flow. 😉

Many people will compare it with Php or will say “This is what we were doing in PHP 10 years ago”, the answer is a bit complicated.

PHP is indeed a server-side programming language, primarily used for server-side processing and generating dynamic web content. By itself, PHP doesn’t directly interact with the front-end or provide client-side interactivity. To achieve front-end interaction or real-time updates, additional technologies like Ajax or JavaScript are typically used in conjunction with PHP.

PHP Vs Modern JS Framworks/Libraries ?

When React was released people were excited to learn and develop apps into it, since we can now make a single-page app; which is best for React to handle. How React work is by letting you write your logic in the ship the complete bundle to the user’s browser. Now the question comes what happens once you start filling with multiple libraries or your code base starts increasing? Your production bundle size will also start growing which will give a hard time for users to ship.

During my journey of learning React, I undertook a project and ensured its readiness for production. Initially, it was a basic React project without any additional frameworks or libraries. However, as the code base expanded and I integrated external libraries, the bundle size gradually increased. Unfortunately, this led to complaints from users regarding noticeable sluggishness on mobile devices.

Now React introduced the concept of code-splitting, where we can split these bundles and lazy load them. Fine, we can solve the bundling with code-splitting & one can argue we can cache some bundle or file to the user’s machine so it won't download it back, which is perfect for solving slowness or website loading issues.

Now the question arises: how can one manage the processing of JavaScript code? 🤕 As our codebase grows larger, it can undoubtedly have an impact on the loading speed of a JavaScript engine. When a JavaScript file is loaded by a browser, the engine needs to parse and interpret the code before executing it. The larger the codebase, the more time it takes for the engine to process and load the JavaScript file.

As we are aware, JavaScript is a single-threaded language specifically designed to be lightweight, allowing it to run smoothly on users’ browsers. Instead of delivering hefty software packages, a web-based approach involves shipping a lightweight user interface while keeping the logic on the backend. This is one of the compelling reasons why major companies are transitioning their software to web-based platforms.

Now the problem comes when you start making UI code heavy with more complex logic and heavy rendering and then ship it to production. Code splitting/caching won't solve this problem. Your single-threaded language is doing multiple tasks like fetching, data rendering, logic processing, etc. & it's all happening on the user’s machine.

PHP solved this issue by pre-rendering most of the logic on the server and shipping it to the user’s machine, a good reason why it's one of the popular languages. However, it’s worth noting that PHP’s main strength lies in server-side processing and generating HTML content. For more interactive and dynamic browser behavior, JavaScript is commonly used in conjunction with PHP. JavaScript, being a client-side scripting language, can handle real-time browser events, manipulate the DOM, and provide a more interactive user experience. A very good reason why react, angular, or other JS libraries/frameworks are popping up. Written in javascript we can design more interactive forms/website/application which makes users more pleasing 😉.

But aren’t we just going back and forth?

How NextJs 13 solves this issue?

With NextJs 13, every component you write is by default a server component. You can make it a client-side component by writing it as ‘use-client’ on top of the file.

Now according to NextJs docs, we should make interactive components as client components and other to server components, just like the image mentioned above.

Now let's discuss how NextJs 13 is solving the issues mentioned above. Client-side rendering, brings whole new possibilities; means now we can move heavy UI logic like data-fetching, pre-rendering & complex js logic to the server side and ship only light weighted UI to the user’s browser. All of these things can be written in Javascript.

Additionally, Next.js 14 simplifies the development process with its built-in functionalities such as Server-Side Generation (SSG), Server-Side Rendering (SSR), and Client-Side Rendering (CSR). These features can be seamlessly incorporated into the workflow without requiring extensive knowledge, resulting in leaner and more comprehensible code compared to earlier versions of Next.js.

My Final Conclusion

In summary, Next.js 14 brings about significant advancements in web development by offering a comprehensive solution for server-side and client-side rendering. By leveraging the strengths of JavaScript and server-side processing, it provides a more efficient and interactive user experience while addressing performance concerns associated with large codebases.

There can be multiple perspectives on this topic, but I believe we are undoubtedly benefiting from languages like PHP and Ruby on Rails in our learning process.

Additionally, we may encounter certain UI libraries that may not function as expected with Next14 or require an upgrade. Nevertheless, I am confident that we are progressing in the right direction.