They mentioned React is missing timing information in the devtools profiler. This was actually added in React 19.2 which should be helpful for debugging.
It gets difficult when you have users saying they can't connect to each other. Then you have to get a better grasp on networking to understand why they can't, sometimes staring at Chrome's webrtc-internals page hoping something clicks. Otherwise you'll have your hands tied and just assume their network is incompatible. Even with a TURN server configured, the same problem can occur.
It's probably worth mentioning that WebTransport just shipped in Chrome 97 (2022-01-04), which seems to be a worthy successor to WebSockets [0]. It allows for reliable and unreliable modes which is a problem for games using WebSockets, among other things.
I appreciate that yourself and other folks are engaging in the community to request improvements.
Prior to the group being formed, most discussion regarding MV3 occurred on the Chrome Extensions Google Group [0]. While feedback was accepted and open there, I hadn't seen the Chrome team acting on it to make changes. That's where most of my pessimism on the situation comes from.
I believe the Chrome team's main motivation is removing any functionality in MV3 which would have the possibility of reducing performance in normal browsing. I personally don't have much hope that they'll be backpedaling on any changes.
I am an extension developer, but have resigned from engaging with development in the ecosystem. One of my extensions has >300k subscribers on the Chrome Webstore which will be killed by MV3.
Many ongoing changes are being made in extensions and the web in general to improve security while reducing capabilities in existing applications.
At this point, for more complex use cases such as one of my own, the only hope is building your own web browser with complete control over its systems. I've changed focus to improving Electron for this reason.
Ideally, I'd like to see MV3 continue supporting the persistent context use case as well as maintaining webRequest blocking support.
Thanks for mentioning this. I've been aware of this group since its announcement, but have been ignorant of the ongoing discussions.
Hopefully Google and others are receptive to some of the proposals made in the issues. I recognize the value of reintroducing the persistent capabilities to the SW model.
As someone who is intimately familiar with the Chrome extensions internals and is not employed by a big tech company, I believe most of the changes seem like a step in the right direction.*
I've been working towards implementing greater support for Chrome extensions in Electron which has involved reading and interacting with Chromium code [0].
- Using service workers instead of a hidden background webpage is more idiomatic for web developers.
- Forced non-persistent extensions guides developers to a better implementation which relies on less resources.
*The deprecation of webRequest's blocking behavior is what's most concerning. The implementation in Manifest V2 requires sending a message back and forth between processes with JS processing for each network request which seems to be in part why they redesigned it.
However, that optimization costs so much for innovative ad blocking technologies as gorhill of uBlock Origin has mentioned. When ad blocking begins requiring new methods of detection or filtering, it'll now be up to Chromium maintainers to implement support for it in the new declarativeNetRequest API. This is a tradeoff of performance for reduced flexibility where it is absolutely needed.
Wouldn't this completely break accessibility support of such web apps? This is part of the reason why omitting the DOM and rendering a UI with WebGL isn't the best idea. Maybe this could be resolved by sending the accessibility tree to the client, but it seems like a step backwards.
Tired of walled gardens and increased limitations of Chrome extensions, I'm building enough of the web extensions API to let me run them in my own desktop browser. Eventually I plan to build products from this project.
At the time of the article, Chromium Edge hadn't been released yet with PlayReady CDM integrated. The followup article I wrote elaborates on these options further.
The code included in the GitHub repository downloads the closed source Electron binaries. Just for comparison, the full source would look something more like what's accessible here: https://github.com/electron/electron
I feel you regarding Chromium, I use Firefox as my daily browser. As for building my own browser, Electron/Chromium just seems like the most achievable option to empower individuals to create a browser.
https://react.dev/blog/2025/10/01/react-19-2#performance-tra...