Traditionally, when browsers were much less capable than today, websites were mostly static with the logic being performed on the server. Back then, most websites served some HTML that was rendered using a templating language such as PHP, which would then be taken over on the client by a different codebase (powered by jQuery or similar).
While Single Page Applications allow developers to embed their application logic into a single codebase, they suffer from some serious issues. Most notably, webpages now need to fully loaded before the browser will be able to show content. This in turn affects search engine crawlers, which might not be able to propely index the website1, affecting its SEO ranking2.
Universal React Made Easy and Simple
To bring this vision forward, Next.js has set out a few primary goals:
- To ease development of server-side rendered React apps.
- To create modern web applications that load as fast as they can.
- To be easy to deploy and test, to speed up the development process.
What Does the User Want?
To understand what Next.js is and how it accomplished its goals, we have to dive into the mind of a user. In this section we investigate who the users of Next.js are and try to understand what they want. For Next.js there are two main types of end users we must keep in mind: the developer and the common web application user.
One may use Next.js to simplify their time spent developing a web app. Next.js
provides a very easy setup through
create-next-app and an immediate
development environment with
yarn dev. Additionally, it takes away
difficulty in developing by implementing code splitting and prefetching.
The common web application user wants any page they wish to see to load quickly. They want to navigate fast and without errors. Next.js helps this by making it easy to have an effortlessly created mapping from routes to pages. By performing server-side rendering, automatic code splitting and prefetching, Next.js tries to load the first page a user sees as fast as possible and fetch other resources in the background.
Six Principles of Next.js
To achieve its vision, Next.js is built around six core principles:
- Zero setup: Next.js believes project do not need setup to get started. Instead, it provides simple filesystem based routing to quickly create new webpages. For more advanced use cases, Next.js allows users to take control.
- Automatic server rendering: Next.js provides by default server side rendering and code splitting. Building the pages on the server reduces the number of round-trip messages which in turn reduces latency. This guarantees that pages are still easily indexed by search engines like Google.
- Performance out of the box: Next.js incorporated features to increase the performance of the created webpages. For example automatic code splitting for faster load times and client-side routing.
- Serverless functions: You can build your API using the routing functionality and serverless functions.
- Static exporting: This feature allows the user to create static website with all the benefits the bring to the table. While doing this it is still able to use modern front-end features and a modern developer workflow.
- Styling: Next.js offers built-in support for CSS-in-JS. The benefits of this feature are that it is component friendly, intuitive, automated and scalable.
The vision of a software product is steered by the stakeholders. To be successful as software means to tend to the requirements of the stakeholders. Why the requirements of the users matter is almost trivial, the users will only use the software if they need the software. It extends however to other stakeholders as well. For instance the development is open source and therefore relies upon the open source community. This means that the code and documentation has to be of a certain standard and quality.
We identified the stakeholders according to the classification of Rozanski and Woods3. We did add the End-User classification as we think that their is a significant difference between the “user” of Next.js and the “end-user”.
|Acquirers||Vercel||Next.js is a product owned by Vercel|
|Assessors||Vercel||Since Vercel owns the software they are also responsible for standards and legal regulation|
|Communicators||Vercel, GitHub Community, Bloggers and others||Vercel offers a range of guides, tutorials and examples on their website and GitHub. These examples are created by the contributors as well. Bloggers and other content creators also write articles and posts on the system.|
|Developers||Vercel and GitHub Community||Vercel has developers working on Next.js and since the project is open source and open for contribution the GitHub community helps in the development as well|
|Maintainers||Developers||Most notably the GitHub users: @timneutkens, @ijjk and @Timer|
|Production Engineers||Dependency owners||Next.js is dependent on a lot of other frameworks, libraries and software. Most notably the React framework, Babel and Node.js|
|Suppliers||npm and GitHub||The Next.js dependency can be retrieved via npm or the source code can be downloaded from GitHub|
|Support Staff||Vercel, GitHub Community, Developer Community||Issues and problems with the software are addressable and solved on GitHub. Forums like StackExchange are also actively offering support.|
|System Administrators||Users||Since Next.js is a framework that means that in principle the responsibility of the working system lies with the user. Vercel does offer a hosting platform for Next.js|
|Testers||Developers||According to the CONTRIBUTING.md the developers are responsible for documenting and testing the software|
|Users||Organizations and Individuals that use Next.js to power their website||Some notable companies that use Next.js to power (a part) of their website are: Netflix, Uber, Nike, AT&T, Docker and others|
|End users||Actual users of website created with Next.js||The requirements of the End-User is given to the respective User. This requirements might reflect on Next.js and are therefore the End-User is a stakeholder in Next.js|
Next.js in Perspective
Software never exists in isolation, but instead manifests itself as an element in a larger ecosystem. The stakeholder analysis that we performed in the previous section is just one of the many facets of this ecosystem. To truly understand the Next.js project, it is crucial that we consider how the project operates in its greater context. Formally, Rozanski et al. define this context as the relationships, dependencies and interactions between the system and its environment, consisting of the people, systems, and external entities with which it interacts3.
We have identified several relevant facets of the Next.js ecosystem and depict them in the figure below:
The project uses Lerna for organizing and managing its multi-package repository. Yarn and Taskr are then used to manage dependencies and run the build scripts (Build Tools). During runtime, Next.js relies on other libraries to provide its core functionality, most notably React and webpack to provide (Dependencies).
Next.js is tested using Jest in conjuction with Selenium WebDriver (Testing) on both Github Actions and Azure Pipelines (Continuous Integration). To keep code consistent and maintainable, Next.js uses ESLint and Prettier for respectively linting and formatting (Static Analysis).
The project is developed by both Vercel Inc (previously ZEIT) and external Github developers (Developers), with the source code made available under the MIT License (Copyright). Most communication between developers is done through Github issues and also the recently introduced discussions functionality. The Next.js website hosts the project’s documentation and blog, with Twitter being used for announcements (Communication).
Next.js is used by a diverse community that also includes large companies such as Nike, Netflix and Hulu (Users). These users may choose to deploy their Next.js application using Vercel or decide to host the application themselves (Deployment).
Next.js competes with projects such as Gatsby and Create React App that share a similar vision, but approach the problem from different angles (Competitors).
Software is never finished, only abandoned5. Instead, software evolves as requirements change over time. Projects may use roadmaps to communicate the the key priorities of a project and illustrate how these align with the project’s vision and strategy. Roadmaps inform the customers what they can expect from the project in the future. Moreover, they help developers align their contributions with the project’s directions.
Unfortunately, the Next.js project does not have a public high-level roadmap. Instead, Vercel has chosen to maintain a private roadmap and in addition use milestones on Github to disclose any part of the roadmap that can be made public, as issues under these milestones6.
At the moment, Next.js has milestones for the next minor and patch versions of
the project, respectively
9.3.0. Issues and pull requests are
linked to a specific milestones to indicate which future release they are
targeting. However, a concrete timeline for these changes is missing as the
maintainers do not specify a due date for these milestones.
While current approach of Vercel conveys more detailed information about the changes to appear in a release to external contributors, the high-level goals and overall direction of the project are not clear, possibly hindering external contributions6. Moreover, the milestones are not frozen, with as result that new changes may be added to a milestone even after its start.
Though, we can still infer some future plans on the roadmap based on the public communication of maintainers inside the repository. We have identified three important changes that are currently on the roadmap of the project:
- Improved Static Site Generation (SSG)7
- Support for React Concurrent mode and streaming rendering8
- Support for partial hydration9
Search Engine Optimization, which is the process of increasing quality and quantity of website traffic. ↩
N. Rozanski and E. Woods, Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley, 2012 ↩ ↩2
J. Saddington, Software: Never Finished, Only Abandoned. Blog, 2014 ↩