title: What's the most reliable way to programmatically control a Chromium instance?
body: <p>I'm researching reliable ways to programmatically control instances of Chrome/Chromium to leverage its capabilities of rendering web pages in Node.js/C#/Java application. In short, things I want to do are as follows:</p>
  
  <ul>
  <li>Open/close a browser window.</li>
  <li>Minimize, maximize browser window.</li>
  <li>Navigate to a certain URL.</li>
  <li>Set cookies.</li>
  </ul>
  
  <p>To make it more clear: I need a headful browser to display web pages to the end users. It can be either embedded to my app or can be a standalone browser (separately shipped instance of Chromium for example).</p>
  
  <p>I was not able to find information about any public APIs in Chrome/Chromium that I can use from the Node.js/C#/Java environment. The ones available for Chrome Extensions are not applicable to my project, as I want to control the browser from the outside, like Selenium WebDriver does for example. So far I found the following ways to control the browser the way I need:</p>
  
  <ol>
  <li>To use Puppeteer/WebDriver APIs.</li>
  <li>Use chrome-remote-interface NodeJS library.</li>
  <li>Rely on Chrome Embedded Framework capabilities.</li>
  <li>Rely on Electron.js capabilities.</li>
  <li>Build my own library that somehow includes the Chromium modules as dependencies (similar to what Electron team implemented for example).</li>
  </ol>
  
  <p>First two options are similar from the perspective of all the mentioned libraries eventually leveraging Chrome Devtools Protocol. The risk of CDP being retired/deprecated is quite substantial for our project. The other concern is that the intention of CDP is debugging and test automation and not application development. Moreover, having an open debugging port in Chrome open on user's machine seems vulnerable.</p>
  
  <p>CEF and Electron paths concern me due to dependency on the embedded Chromium updates cadence. Although Electron team is targeting to update with every other release of Chromium it still can be a security concern due to inability to update the Chromium version right after a new version released with a security patch, for example. Moreover, in case when I need the real browser experience (and that's the case) I won't have it out of the box and I'll have to implement browser features like buttons, tabs address bar etc. myself.</p>
  
  <p>Option #5 seems to be extremely complex in implementation as it seems to require team's competency on Chromium internals, C++ development and C++ build tooling.</p>
  
  <p>Anything I missed in the options list? Anything I missed in my assumptions? Any tips, thoughts, suggestions will be greatly appreciated! </p>