Question: what's the future of Muon with the upcoming move to Chromium frontend?

[maxart]

Following the 1.0 announcement ( https://brave.com/development-plans-for-upcoming-release/ ) what can the community expect regarding development of Muon in the future?

[tomByrer]

I'm also interested.

Or will much of muon be ported back to Electron?

[jhult]

Any news on this?

[patrickalima98]

Any news? I am very interested in working on this project, in case I have no future I am seriously thinking about creating a project fork and keeping it.

[bsclifton]

Hi there folks! Apologies for not responding sooner; I wanted to make sure we could give a good response. I can start off with an update as to where we're at with Brave

• as noted in the original post (above), we have moved to a direct fork of Chromium. With Muon, there is the browser-laptop-bootstrap repo. The comparable repo for this new version of Brave (which we've been referring to as brave-core) is https://github.com/brave/brave-browser
• Myself, @kjozwiak on QA, and a few other individuals (@darkdh, @bridiver) are still working on browser-laptop and Muon as needed. We're just finishing up the Chromium 69 upgrade (PR can be found here)
• we've released the new product as a developer channel build
• most of the desktop developers have moved over to the new version of the product. They've been sharing roadmap updates and there is a published release scheduled (which includes when we'll move our users to the new product)

Chromium 69 is going to be the last major update that we do for Muon. brave-core is using Chromium 70 right now and (per the release schedule) is slated to go live sometime in October 2018

I think the future of Muon is up to us here in this issue. What would you like to see done, @maxart, @tomByrer, @jhult, @patrickalima98? I would love to see more discussion and find who may be interested as a maintainer

Since we diverged from electron with Chromium 54 (~November 2016-ish?), many parts of our code are not upstreamable to electron. One of the major tasks that should be considered if folks wanted to continue using Muon would be to move from using GuestView to OOPIF (out of process iframe). This is not an easy move to make, but it would fix a lot of compatibility issues we have when upgrading Chromium versions

[patrickalima98]

Hello @bsclifton I'm working on a OS based on Firefox OS, muon is a great framework the way it is, but before proceeding, I would like you to explain what limitations Muon has to build complete browsers? Could these limitations be agreed upon?

Now about Muon, I'd love to help, I can not do everything myself, besides I'm not that experienced in C ++ to work with Chromium and Node.JS at the level I'm in today, but I wish I could help, he has some things like:

• Outdated and disorganized Doc
• There is a beautiful and documented site like the electron
• More examples of how to get started, a better organization
• A clear and objective explanation of what Muon really does and Electron does not, which he does not have ...
• Refactor the entire electron module for muon

Ex:

// bad
require('electron'); `
// Good
require('muon');

I could help with the site, with doc maybe (Depends on my English), with examples of how to start among other things, of course I could not do it alone, I'm very interested in helping this project, however it depends on how things Are they going to stay, how hard is it to work on a Chromium version update today?
Also if we helped you would you help us keep? Would Muon follow the latest versions of Chromium? Could we use it in production?

thanks in advance

[bsclifton]

@patrickalima98 the major pain points we experienced were:

• difficulty of upgrading Chromium version. As noted in my original post, we are using the GuestView basically, which is a legacy component at this point (from a Chromium perspective). When upgrading Chromium, we'd typically run into build errors which have to be resolved either by updating the code in Muon OR putting in a patch for the base Chromium code that solves our issue. You can see by viewing our master patch that we have to do a LOT of patching to get things working how we'd like (which has a significant cost associated with it)
• adding extension support was up to us. We added support for a decent number of APIs, but many were never implemented, which prevents extensions from being used properly

For those reasons, I believe Chromium 69 will be the last upgrade of Chromium that we (Brave Software) do. If someone wanted to get a feel for what an upgrade would look like, you can check out the latest browser-laptop-bootstrap and update the Chromium version in the package.json to 70.0.3538.12. After this is done, you can run npm run init to grab the code / run the hooks and then start a build

Electron wasn't created with browsers in mind, something that is acknowledged in the documentation. As we addressed those known issues and hardened the security in our fork, Muon did provide a low barrier for entry and allowed for rapid development. That part of the project was amazing and is how I got involved with the browser months before joining Brave Software

As you've noticed, the docs are outdated. I don't know that we've ever made an effort to update them. We did create a muon-quick repo (meant to be similar to electron-quick-start) but never really iterated on it. We've typically chosen to use GitHub wiki pages instead (the ones on browser-laptop-bootstrap being fairly comprehensive)

[patrickalima98]

I understand, NW.JS has extensions support but I do not know how many. I'd like for Muon to continue, but only Electron and NW.JS remain. The electron takes a long time to update, the NW.JS is much faster and follows the latest versions of Chromium. In my case I would need an environment that would provide a more secure webview, I do not know the security level of nw.js, I looked at the docs that you mentioned, however I believe we would need to give a better organized in them, I pointed out a short list of things that I think should be changed. What about upgrading to OOPIF you talked about, would it make it easier to keep Muon up?

Besides me if anyone wants to help keep Muon I try to help in the best way possible, after all I need this kkk.

[bsclifton]

Just merged some great documentation by @samuelmaddock and @shadowcodex 😄

I've personally been mostly focused on the browser-laptop side of things, so I apologize for dropping the ball on merging those

[0joshuaolson1]

I think it would be a great idea to link to this issue in the readme, or even mention something in the repo description.