Comparing Next.js and Remix: A Framework Battle

Kent C. Dodds and Lee Rob are engaged in a battle over React, a library turned meta framework. The discussion revolves around the necessity of having the entire system infected by React to use it effectively. The battle is anticipated to have one winner, either Intel or AMD, due to the need for faster CPUs to run resource-intensive programs like Slack.

Individuals embarking on new projects or seeking to upgrade to a more modern approach face the decision of selecting from various modern frameworks. The choice may involve factors like marketability, productivity, and dissatisfaction with current frameworks.

Remix, a full-stack web framework, aims to address common challenges encountered in web application development. It is positioned as a viable alternative to Next.js, a popular framework. The speaker, having used Remix since its inception in 2020, highlights its features and recommends it for web development.

The speaker explains why they prefer Remix over Next.js for teaching on Epic web.dev. They emphasize the focus on positive aspects of Remix and clarify that the intention is not to criticize Next.js but to share personal experiences and perceptions.

The speaker acknowledges the presence of Next.js on the site Epic web.dev, built by a team experienced in Next.js development. Despite personal preferences for Remix, the speaker respects the team's decision to use Next.js for the site's construction.

The speaker emphasizes that skill in using a tool is more crucial than the tool itself in achieving desired outcomes. Using a tool repeatedly enhances proficiency, enabling the creation of larger projects regardless of the tool's initial quality. This explains the enduring success of JavaScript as a language.

The speaker expresses a preference for using Remix over Next.js for creating superior user experiences. While acknowledging that using Next.js does not imply failure, the speaker believes that using Remix would lead to increased happiness and productivity.

The speaker discloses being an outsider to the Next.js framework for years, having not shipped anything with Next.js personally. Despite keeping up with Next.js developments and others' experiences, the speaker's past intuition guides a decision not to use Next.js.

Having transitioned from using Enzyme to developing a testing library, the speaker highlights a key difference in approach. While Enzyme provided a wrapper with utilities, the testing library exposes platform APIs directly, favoring simplicity and avoiding the need to support underlying changes.

One of the greatest reasons why Rust is a good language is its specific ability to do trait implementations, which enhances transferability by focusing on a standard API testing Library. This helps people become familiar with APIs and utilities available in other tools that rely on standard APIs.

Next.js is like Enzyme, providing utilities to interact with request headers and cookies, while Remix exposes APIs directly through its loaders and actions. Understanding how to return JSON with headers leads developers to MDN, the standard for web platform documentation.

The speaker prefers React + Vite + HDMX, emphasizing the importance of focusing on a framework that not only delivers the desired user experience but also equips developers with transferable skills across web development.

OpenEx converts Next.js build output into a package deployable to any Functions as a Service platform, currently supporting only AWS Lambda. Hosting in AWS integrates easily with backend and is cost-effective compared to Forrester. Next.js lacks self-hosting options like Remix or Astro.

Vercel is making efforts to support Next.js, even though hosting Next.js as a regular Node.js application can be challenging. The Netlify team has dedicated time to ensure Next.js support and keep up with changes in Next.js.

There are concerns about Vercel's pricing and profitability, with discussions on whether Vercel is profitable. Despite this, Vercel makes money on every request, raising questions about the sustainability of relying solely on Vercel.

Remix was designed to deploy anywhere JavaScript runs, emphasizing standards. This flexibility has been beneficial, allowing Remix to be deployed in various environments.

There is a blurring of lines between React and Next.js, causing confusion for developers. With Vercel hiring many React team members, concerns arise about the collaborative nature of the React team.

New developers face challenges distinguishing between Next.js and React, leading to increased complexity. The line blurring between the two technologies adds to the difficulty, making it harder for beginners to navigate the ecosystem.

Vercel's investment in server components aims to position Next.js as the go-to framework for using server components. By aligning Next.js closely with React, Vercel aims to establish itself as the primary choice for building applications using React.

A new person entering the ecosystem has the potential to increase profits by investing in the future. This move is seen as buying something to generate more revenue, making perfect sense for the individual involved.

Expressing discomfort with React not belonging to an open foundation and the lack of collaboration since joining Versell. The speaker notes a decrease in collaboration compared to the previous meta era, highlighting potential issues with the current dynamics.

Acknowledging the benefits of closer collaboration with React through Next.js. However, the speaker emphasizes that a lack of collaboration within a team could be a negative sign for software development.

Expressing concern over questionable decisions made by the Next.js team, particularly in marketing experimental features as stable. The speaker finds it amusing yet concerning, highlighting potential issues with the stability of features.

Explaining the concept of a canary release and its relation to Next.js, where stable features are shipped as canary releases. The speaker humorously compares this to turning an app into a sentient species, emphasizing potential risks and user experiences.

Expressing excitement for using React server components once they are production-ready, anticipating benefits for Remix. The speaker mentions the principle of least surprise and the importance of following web platform APIs to avoid surprising users.

The discussion highlights the extensive use of magic in JavaScript frameworks like React, where non-JavaScript standards are compiled into JavaScript, executed in libraries, and involve server-side components for virtual diffing. Debugging React is challenging, requiring specialized tools like React Dev tools due to the intricate magic involved.

The speaker questions the relevance of using React without JSX, emphasizing that while it's possible through transpilation, it's not a common practice as JSX is integral to React development.

The transition from working with React on the web to Next.js and React Native was smooth for the speaker's company, facilitated by the ease of hiring React developers and the speaker's prior experience with React.

Next.js's decision to override the Global fetch function to add automatic caching raises concerns for the speaker, questioning potential hidden surprises in the framework's design choices.

The speaker supports Next.js's approach of making fetch act more like a browser for caching HTTP requests, suggesting a clear distinction between raw fetch and a cached fetch operator for better control.

The discussion recalls the lesson from the Mo tools era about the pitfalls of overriding built-in platform features, citing examples like string prototype includes replacing string prototype contains, showcasing the potential problems of such practices.

Users find Next.js overly complex due to features like server actions, experimental taint API, and increased level of complexity with mutations. The naming of APIs like taint API has sparked jokes and concerns about complexity.

The Remix team, led by individuals sharing similar principles, aims to avoid added complexity in features. They focus on reducing the overall API footprint rather than increasing it, ensuring stability and simplicity in the framework.

Next.js is on version 13, while React Router, built by the same team as Remix, is on version six. The Remix team prioritizes stability, as seen in the slow version updates and the use of future flags for feature releases.

React Router has faced criticism for affecting the URL structure and breaking where state should have been, leading to confusion and challenges in adapting to new versions. There are concerns about how React Router handles web standards and APIs.

Both Next.js and Remix offer capabilities to build impressive projects. The focus should be on capabilities rather than features, with personal preference leaning towards Remix for a wider pit of success. The distinction between features and capabilities is subjective.

There is surprise and confusion about a course priced at $1,000, questioning the value and capabilities it offers. The blog post emphasizes building great projects with both Next.js and Remix, highlighting the importance of capabilities over features.

The team rewrote the Next.js Eomer demo to address the Remix versus Next.js question. It was demonstrated that Remix resulted in a better user experience with much less code, which is crucial for user experience. Next.js has since updated to use the app router, relying on Canary features. A comparison between Remix and Next.js is recommended, as both frameworks have evolved with new features.

The speaker, Kent, recommends and teaches Remix over Next.js due to personal sensibilities on software maintainability and joy in long-term work. Kent believes that Remix provides more transferable knowledge and aligns better with his preferences. A VP of DX at Versel posted a response, but Kent stands by his recommendation of Remix for its maintainability and joy in development.

In the summer of 2023, Kent hosted an eight-week live presentation of the Epic web Workshop series. An attendee, Gwen Shapiro, later mentioned that the workshop helped her build mostly on the Next.js stack. Kent's class provided the mental framework needed to ramp up and feel confident in building on Next.js. Kent emphasizes the importance of strong foundations in learning and believes that the knowledge gained from the workshop is transferable to other frameworks.

Kent acknowledges the importance of web standards in software development, highlighting the need to follow standards for maintainability. He points out that deviating from standards can lead to increased maintenance efforts. While Kent appreciates the emphasis on web standards in the article, he struggles with the notion of 'magic' in development, particularly in the context of React's capabilities.

Kent Dodds, a prolific educator and co-founder of Remix, shares his perspective on using Remix over Next.js. He argues that learning Next.js helps in understanding the web platform, with features like self-hosted server components and server actions being independent of Versel. Kent's new course, Epic Web Dev, focuses on building full-stack web applications using Remix. Kent's contributions to the React Community, especially in testing, are noteworthy, showcasing his expertise in the field.

Lee, a good guy, is well-liked by the speaker who has worked on Next.js and created courses on it before joining Forell. Both the speaker and Kent are passionate about the tools they use. Next.js is a popular alternative to Remix, prompting discussions on why one would choose Remix over Next.js.

Remix has pushed the React Community forward in understanding the web platform and web APIs. Next.js, released in 2016, utilized Node.js request-response objects for server-rendered JavaScript frameworks. In contrast, Remix, released in 2021, benefits from a more powerful web platform and a new generation of developers learning web request and response APIs.

Next.js has evolved over the years, introducing API routes in version 9 in 2019 and middleware in version 12 in 2021. The framework's design choices have adapted to embrace standardized web APIs, moving away from older practices like page routing. This evolution reflects the need to align with community feedback, ecosystem changes, and new web platform functionalities.

After 6 years of feedback, Next.js 13 introduced a new foundation for the framework with the app router, while retaining the pages router. The framework evolved to handle reading values from incoming requests like cookies or headers and allowing developers to write custom API endpoints.

When designing a framework, it is essential to use web standard APIs and make it easy for developers to follow best practices. Next.js emphasized the importance of leveraging web APIs directly, enabling developers to access headers, cookies, and other web functionalities easily.

Route handlers in Next.js accept web requests and produce responses, allowing developers to access cookies, headers, and other web APIs directly. By providing abstractions and reusable functions, developers can work with web functionalities without passing headers as function parameters.

Kent emphasized the importance of new frameworks embracing web APIs, as seen in Remix, Felt Kit, Solid, Astro, and Next.js. These frameworks prioritize utilizing web standards and functionalities to enhance developer experience and platform compatibility.

The Open Next project on AWS aims to provide a platform for easily deploying serverless applications. Maintainers of Open Next are building an infrastructure as code tool to simplify the deployment process, addressing challenges faced with deploying Next.js applications.

Kent discusses deploying with Docker to various services, emphasizing the flexibility to choose preferred services for deployment.

Next.js supports self-hosting for platforms like Walmart, TikTok, GPT, Starbucks, Target, and DoorDash, providing developers with the freedom to eject and control their hosting environment.

Next.js offers self-hosting capabilities, infrastructure, and workflow on top of the framework, allowing hosting anywhere with funding and incentives aligned through Vercel.

Kent and TJ discuss the challenges of building and maintaining adapters for various deployment targets, highlighting the complexity and resource-intensive nature of such an endeavor.

There is a misconception about hosting Next.js as a node application being difficult, with Kent debunking this notion by sharing his experience of successfully containerizing and deploying Next.js apps for five years.

Vercel's philosophy of 'framework-defined infrastructure' ensures compatibility and consistency across frameworks like Next.js, Remix, and Svelte, with an open-source build output API powering these frameworks on Vercel.

Kent addresses the correlation versus causation debate regarding Vercel's pricing, acknowledging the impact of pricing on user experience and hinting at upcoming pricing changes to address user concerns.

Running Next.js on serverless infrastructure presents challenges as it requires a deep understanding that it's not just about thin compute cost layers. The negative starting point of not aiming for a thin compute cost layer complicates the deployment process.

Contrary to popular belief, it's not entirely true that Next.js is easy to run anywhere. The claim dismisses the significant effort the open-source Next.js community puts into making it feasible to run correctly outside of Vercel.

With serverless functions, the challenge of explicitly controlling versioning for API endpoints arises. Vercel's infrastructure allows every deployed version of an app to coexist, solving versioning issues by routing old clients to the correct version. This problem is inherent in self-hosting and requires careful management.

Next.js has been developed under the technical direction and vision of the React team, emphasizing compatibility and alignment with React's architectural model. The collaboration ensures that APIs are designed with a broader perspective beyond Next.js specifics, reflecting a commitment to technical excellence.

Selecting Vercel for deploying Next.js is beneficial for those who prioritize ease of deployment and infrastructure management. Vercel's platform handles infrastructure concerns, allowing developers to focus on building and scaling their applications without worrying about the underlying server setup.

Next.js is compared to Kubernetes, while Vercel is likened to Google Kubernetes Engine. The discussion highlights that Next.js is betting on the future of React, emphasizing the importance of the app router builds and the collaboration with the meta team for documentation improvements.

There are reservations about Next.js extending the web fetch API, with plans to move away from adding Next.js specific extensions based on community feedback. Changes in Next.js 14 include opting out of caching using 'no store' and separating programmatic caching and revalidating features into standalone APIs.

The app router in Next.js is described as a different model from the pages router, almost resembling a new framework. The need to incrementally adopt the new router while maintaining stability and support for existing routers is emphasized, along with the creation of a new free course to teach the model.

The discussion addresses the misconception that the number of major versions correlates with a framework's stability. Kent mentions that being on version two does not inherently indicate stability, emphasizing the importance of code mods and upgrade guides for smooth transitions between versions.

Both Next.js and React are acknowledged as highly capable frameworks for creating web experiences. The speaker appreciates Next.js for enabling full project development without separate backends, focusing on React components, utilizing the latest features, and providing continuous performance improvements and new features.

The speaker appreciates the benefits of using Next.js and Remix for web development, highlighting features like image sizing, caching, and ease of use. They acknowledge the advantages these frameworks offer in handling images and improving site performance. Despite the positives, the speaker expresses concern about new developers solely relying on these frameworks without understanding the fundamentals of web development.

The speaker expresses a personal preference for HDMX due to its ability to separate server-side logic from client-side interactions. They believe that having the server as the source of truth and the client as a responsive entity is a superior approach. The speaker values the clarity and separation of concerns that HDMX provides in web development.

The speaker emphasizes the importance of using programming languages for specific tasks, such as JavaScript for DOM manipulation, Go for server-side operations, and Rust for server-related tasks. They advocate for leveraging languages based on their strengths and suitability for particular use cases, rather than relying solely on frameworks like Next.js and Remix.

The speaker mentions that while they may not currently use Next.js or Remix for their projects, they remain open to exploring these frameworks in the future. They express a willingness to try Next.js for a project named 'the primagen' at some point, indicating a potential interest in experimenting with different tools and technologies.