Why is there a chromium subprocess running in WeBuilder 2018

[chromium_subprocess]

Hello,

I just installed WeBuilder 2018 in order to test it and the first thing I saw in the task manager were the two extra chromium_subprocess.exe apps running.
Why are they here and how can I disable them (skimmed through the options but couldn't find anything useful)?

The reason I'm asking is because the new version is kinda sluggish compared to the old one and knowing how chrome is a heavy app I'm thinking this might be the problem.
And the second reason is that I simply don't like google and deliberately don't have any of their software installed on the PC and WeBuilder just installed it without asking me (not that I like M$ either but I doubt you'll ever release a linux version).


//EDIT:
I read in the what's new page that it's used by the plugins, so I removed the Emmet plugin that came with it (or it got it from the 2016 install) and restarted but they're still there.
Also after removing the Emmet plugin it's menu entry in the Plugins menu is still there with an empty submenu.

[pmk65]

Chromium is NOT Google Chrome. It's an Open Source project based on the same code as Google Chrome, but doesn't have any of Google's "Spy ware" functions. (You can compile the source code yourself.)
https://en.wikipedia.org/wiki/Chromium_(web_browser)

I use a Chromium based browser (SW Iron) myself, as I like you don't trust Google. But I still need a "Chrome" browser for testing.
https://www.srware.net/en/software_srware_iron.php

[chromium_subprocess]

@pmk65 - Chromium being a huge project I somehow doubt that someone has audited the whole code... but even if it has been, I still don't want it running on my old and slow machine.

Don't know about the others but I use WeBuilder mostly as a text editor (I've completely disabled the preview options and PHP parsing) and I need it to consume as less resources as possible (and the chrome browser (or in this case chromium) is the exact opposite of that)...

Right now the 2 sub-processes started with WeBuilder use around 70MB RAM which is 70MB more RAM than with the old version (and while it might not seem that much, it's a lot for a machine with only 8 gigs of RAM, no SSD and a bunch of other open apps)...

I'm not asking that they're completely removed but if they're indeed used only for the plugins system I see no reason why they can't be disabled from starting if there are no plugins installed or enabled. As much as I like emmet I can work without it, especially since I can't expand the abbreviations via the TAB key as it's the standard in other editors...

[Will Fastie]

That does sound like a lot of overhead just for plugins.

[pmk65]

That does sound like a lot of overhead just for plugins.

It's only loaded for plugin that uses the Chromium engine. You use that if your plugin is written in JavaScript and not the native FastScript language used for plugins.

[Will Fastie]

Which is more desirable for plugins, FastScript or JavaScript?

[pmk65]

Which is more desirable for plugins, FastScript or JavaScript?

You can't really avoid FastScript, as you need that for plugin initialization, document access and for starting the Chromium/JavaScript process.
But if you are implementing existing code (JQuery plugins etc,), then you use the Chromium/JavaScript option.
The new 2018 version also supports writing plugins in PHP in a similar fashion. So you can do all the dirty work in PHP/JavaScript and return the result back to WeBuilder. (That's what the Emmet plugin does.)

My image2CSS plugin uses the Chromium/JavaScript feature to display JavaScript code and then return the result back to the current document.

[Aivars]

Ok, let my try to clear some misconceptions.
We are using Chromium Embedded Framework since WeBuilder 2014, so it's not a new feature by any means. The difference is that before version 2018 webuilder.exe handled the multi-process nature of Chromium framework, but for this version we created a special chromium_subprocess.exe (that is our file, not Google's) that only initializes the framework and does nothing else because our benchmarks showed that this made all chromium-related stuff (integrated Chrome preview etc) much faster.
The reason why the framework always initializes whether any Chromium related features are used or not is due to the nature of CEF. It's the only way for us to have integrated Chrome preview. It has been that way as long as the integrated Chrome preview has existed in WeBuilder, you just never noticed. It is not related to plugins, at least not directly, except when plugins use Chromium for various tasks. Emmet plugin won't initialize/use Chromium unless any of it's actions is called once, but of course you can disable/remove it completely.

[midipixel]

Hey Aivars,

On this same topic, I always wanted to ask a question. Is there a way to update the Chromium engine? In the last version of Webuilder, we were stuck with an old Chromium for long time, which ultimately made me stop using the integrated preview, since I couldn't even code with ES6 or use CSS variables without resorting to a third party transpiler.

Will we be able to update the Chromium engine now, or is this problem going to happen again?

Thanks!

[Aivars]

Unfortunately, no, because CEF always changes the library API headers and mechanics, and not only internals with each update and it's pretty tightly coupled with the executable. It's a major annoyance for us, too, because sometimes big changes are required to support newer CEF versions.
If you're coding on the very edge of what's supported in Chrome then the integrated preview might not be for you, since we are always trying to keep a balance between what's new and what's implemented in browsers that people are using by percentage, but you can use live refreshers and such.

[midipixel]

Thanks, Aivars. I understand. No problem, I've been using live refreshers for a while! I just happen to like the integrated preview better!