Carlo, is this the future of Electron ?

Alireza A
4 min readNov 5, 2018

--

If you want to create a desktop app in a small amount of time using your web developing knowledge, then probably Electron is your first choice. In recent years, many companies tend to release their desktop app using Electron like Twitch, Discord, Skype, VS Code, … because it is a very fast (but not so efficient) way of developing a desktop app in the beginning and they don’t need new developers to create these apps.

There are many developers against Electron because of it’s performance, bundle size, etc. The disadvantages of Electron is discussed in many places like hackernews and medium. Some tried to provide solutions to these disadvantages e.g. electrino tried to give electron apps a diet to reduce their size. But most of the provided solutions are not bug free and not suitable for production.

Google recently decided that it needs to get inside the competition of hybrid desktop apps as well (Probably trying to help it’s Chrome OS to gain more market share in future) and released Carlo. They define Carlo as :

Carlo provides Node applications with Google Chrome rendering capabilities. Carlo communicates with the locally-installed browser instance using the Puppeteer project. Carlo also provides remote call infrastructure for communication between Node and the browser.

So what is the difference between Carlo and Electron ? Their github also mentions :

One of the motivations is to demonstrate how browser installed locally can be used with Node out of the box.

Unlike with Electron, Node v8 and Chrome v8 engines are decoupled in Carlo, providing a maintainable model with the ability of the independent updates of the underlying components.

So while Electron bundles it’s own version of Chromium, Carlo tries to use users local Chrome and this can reduce the bundle size greatly. As it also uses the locally installed Chrome, so all the apps can benefit from regular updates for their browser part as the locally installed browser gets updated. So it can be considered as a great competitor for Electron, but first let’s answer some questions you might have already.

Will Carlo work with chromium as well ?

As you saw, google has mentioned Google Chrome in their announcement, so are we able to use chromium too (Electron bundles chromium) ? It seems so, by looking at the Carlo codes we can find :

Browser executables that Carlo will look for

So for becoming 100% sure, I just installed it in my Linux box with chromium 70 on it to test and the systeminfo example ran without any problem. So for those who do not want to install Google Chrome on their OS, chromium is working as well too.

Is it really smaller ?

Yes ! the node_module directory of only installed Electron takes around 130MB while for Carlo it is around 2MB. After packaging and installing the app, at least 100MB of difference can be seen.

Is developer console accessible in Carlo ?

Again yes, the developer console is just there and pressing ctrl+shift+i will reveal it. I wasn’t able to find the docking mode to have both developer console and the app in one window, it seems to be removed.

So the first advantage is guaranteed, Carlo produces smaller packages by using the locally installed chrom(e/ium) browser. So what about performance ? Will using the local browser affect performance too ? So I write a little example to load speedometer 2.0 in both Carlo and Electron. The results were just like what I was expecting :

Carlo (left) and Electron (right) running Speedometer 2.0

The difference is not that much and that little difference could be from different versions of chromium (Electron uses v66 while the one locally installed and used by Carlo is v70). So performance wise there might be no difference in using any of these two. While both frameworks have same CPU usage, the Carlo was using 25% more memory while doing the same test. The memory usage of Electron was 320MB and that of Carlo was around 400MB.

It is very early to conclude anything about Carlo and the current version is not providing much for developers. While the performance seems to be same for both Electron and Carlo, the decoupling of chrom(e/ium) is a good move which results in less wasted space specially on precious SSD drives.

The security advantage of locally installed Chrome getting updates that is mentioned in some articles needs to be investigated more because it is not clear that how the apps will behave after an update.

For now the option that many wanted in Electron, is available using another framework from Google itself. The future of Carlo is depending on how well puppeteer will be able to manage different versions of Chrome.

--

--