Next.js 16 and React 19 Upgrades Introduce Significant Compatibility Hurdles

Key Quotes

"Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day: I think the patch is a great change so hats off to everyone involved for getting it done so quickly. It's already in Canary and don't really know when it'll get the stable but that sure will be good."

The author expresses significant gratitude towards Bramus Van Damme for quickly addressing and resolving an issue related to iframe allow attributes. This highlights the positive impact of community involvement and rapid problem-solving in software development. The author also notes the swift integration of the fix into a pre-release version, indicating confidence in its effectiveness.

"But there's the rub: we'd rather not do any user-agent sniffing at all. If we could just put all the possible allow attributes we want on there, and not be terribly concerned if any particular browser didn't support any particular value, that would be ideal."

The author articulates a preference for a more robust and less brittle solution than user-agent sniffing. This desire points to the goal of creating cross-browser compatible code that doesn't rely on detecting specific browser versions or behaviors. The ideal scenario, as described by the author, is a system where unsupported attributes are gracefully ignored by browsers.

"We're waiting for the change to Chrome to get to stable. We're hoping Safari stays the way it is. OH HI FIREFOX."

This quote humorously summarizes the current state of a technical issue across different browsers. The author indicates that a resolution is pending in Chrome, a desired behavior is already present in Safari, and a new challenge has emerged with Firefox. This illustrates the common development challenge of managing platform-specific behaviors.

"And I think it's I think it's completely required in in next 15 um and so we had to take a look at was it because of the was it the components or whatever they call those in react I bet it is right I think so and they at least from 17 to 18 they changed like some of the react dom apis and like all that all that kind of stuff so you really had to make sure you were using the the latest for that"

The author explains that upgrading to Next.js 15 necessitated an upgrade to React 19 due to dependencies. This points to the interconnectedness of different libraries and frameworks in a development stack. The author speculates that changes in React DOM APIs between versions 17 and 18 were a key factor in this requirement.

"they dropped prop types support and which which isn't that bad like you know if if it's if it's there it can stay there but it won't be used and that that's fine it can still inform oh it didn't error or whatever I I think it I think they started throwing warnings in in react 19 about it so they were like deprecated but not they didn't kill the api or something right it it just doesn't actually do anything anymore in react 19 but we mainly used them for like client for editor hints you know so like when you're looking at a particular component you can see what what the props are for it"

The author discusses the deprecation of propTypes in React 19, noting that while the API is no longer functional, it may still provide warnings or inform developers. The author highlights that propTypes were primarily used for editor hints, offering developers visibility into component props. This illustrates how features can be phased out, even if they served a useful purpose for developer experience.

"but you know it is appealing i guess i mean that's why you're doing it i suppose is it does seem like if we get it it's faster right i haven't seen any speed increases yet because i haven't been able to get past all the error modals but i guess the error modals are delivered fast that's that's great that's good yeah but yeah i mean supposedly it will compile faster"

The author expresses a hopeful anticipation for performance improvements with a new technology, even though current progress is hindered by errors. The expectation is that the new system will offer faster compilation times. This reflects a common development scenario where the promise of speed is a significant motivator for adopting new tools, despite initial challenges.

"and then you just start running into other blockers so our we use sas for for all of our stuff and occasionally we need to use like global styles within the sas and turbopack global is like a that's a post or what do you call what do you call that thing css modules feature right I think so but that means that turbopack has its own implementation of that and so you can't just directly directly use it in the same way like they only support the like function version of it where it's colon global and then the parentheses around a selector"

The author details a specific compatibility issue encountered when integrating Sass with Turbopack. The problem arises from Turbopack's distinct implementation of CSS Modules' global styles, which deviates from the expected syntax. This highlights how different build tools can have unique interpretations of features, requiring developers to adapt their code.