smaddock

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.

https://react.dev/blog/2025/10/01/react-19-2#performance-tra...

ShareX uploads videos in a pipeline: record, optimize, then upload.

Loom does this while the video is being recorded to give you the link as fast as possible.

Slack tracks close to the latest releases of Electron. Election also tracks close to the latest Chromium releases [0].

[0] https://releases.electronjs.org

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.

Can you elaborate on which security protections are not used by Electron, and by extension Min?

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.

[0] https://web.dev/webtransport/

Their comment is in reference to Hayao Miyazaka's thoughts on a particular AI-based animation: https://www.youtube.com/watch?v=ngZ0K3lWKRc

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.

[0] https://groups.google.com/a/chromium.org/g/chromium-extensio...

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.

[0] https://github.com/samuelmaddock/electron-browser-shell

I've been working on adding better support for browser extensions in Electron. It's an absolutely necessary feature for web browsers. Maybe OP can have a look: https://www.npmjs.com/package/electron-chrome-extensions

For those not in the know, 4242 is used as a common test card number.

https://stripe.com/docs/testing#cards

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.

Desktop and window capture is included for all platforms as part of WebRTC.

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.

https://github.com/samuelmaddock/electron-browser-shell

Content decryption through the Encrypted Media Extension (EME) web standard.

https://www.w3.org/TR/encrypted-media/

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.

https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...

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.

I'm honestly not sure about the legality of downloading from another distributor. I do know that distribution requires a license [0].

The risk doesn't seem worth it to use such a workaround for a serious project though.

[0] https://source.chromium.org/chromium/chromium/src/+/master:t...

Oh! That makes sense, they must have moved it from Issues to Discussions. Thanks, I'll update the parent comment.

Brave also started out this way—building a browser on top of Electron. [0]

Building something on top of the Chromium project is still building a browser. You're right that it's not building a rendering engine and JavaScript interpreter though.

[0] https://github.com/brave/browser-laptop

The intention was to build a media player based on a Chromium-derived web browser. Functionally it would playback content on Netflix, Hulu, and other DRM-enabled services.

The problem isn't the closed source nature of Widevine CDM, but rather that access to use it is rather difficult to come by.

DRM goes against the concept of an Open Web in which anyone can build a web browser without asking permission.

Blog post author here. Since this post, there's now an option available for DRM-enabled Electron. However, it's only available through a single vendor, castLabs [0].

This is a closed source, downstream effort which means no modifications can be made to Electron itself. All changes must make it upstream to show up in this fork. When asked whether they would eventually merge it upstream, they didn't provide a clear answer [1].

I also wrote a followup blog post with more detail on the current state of DRM options on the web [2]. Spoilers: it's not great.

Regardless of all of these problems, I still hold an interest in browser development and have been working towards making Electron a viable option for building a browser [3].

[0] https://github.com/castlabs/electron-releases

[1] https://github.com/castlabs/electron-releases/discussions/24

[2] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...

[3] https://github.com/samuelmaddock/electron-browser-shell

Chrome extension support for Electron-based web browsers: https://github.com/samuelmaddock/electron-browser-shell

Despite a fair amount of folks disliking Electron for replacing traditional desktop apps, I find it's a great fit for building unique web browsers.

I believe there's a lot of opportunity for making interesting web browsers, but building and maintaining them by forking something like Chromium or Firefox is a ton of work.

With Electron, it's possible to create something interesting with a team of one.

I'd love to see legislature go through a process like public GitHub pull requests. If we could create a culture similar to the best practices of code reviews, that'd be great.

- Keep changes limited in scope for easier review.

- Open the process to the wider public for inspection.

- Transparent revision history.

You're right that the issue described in the OP is more specific. However, I believe its a symptom of the larger, underlying problem.

Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.

The issue also affects Electron-based browsers, something I wouldn't consider "embedded". These are a few browsers affected off the top of my head:

- Beaker https://github.com/beakerbrowser/beaker/issues/1749

- Min https://github.com/minbrowser/min/issues/868

- Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65

From what I can tell, it's really any browser not well known by Google.

With measures like this, Google is actively preventing new, independent browsers from ever scaling on their own.

Want to sign in to Google? Use one of the selected browsers with a significant, existing market share.

But first though, are you actually human? Let's see if your browser is compatible with our reCAPTCHA service. [0]

Oh, you wanted to watch something on Netflix? I hope your browser is approved by Google for DRM playback. [1]

[0] https://twitter.com/bcrypt/status/1320410639244746753

[1] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...