Using the Same Source Code for Online and Desktop Apps

ONLYOFFICE is an open source office suite for working with documents, spreadsheets, and presentations written in JavaScript. It has both online and desktop versions that basically share the same source code.

In this article, we will tell you how it is done and how abandoning native apps might actually help a project.

Desktop Version Differences

ONLYOFFICE started with online editors which were conceived as an open-source Microsoft Office alternative that:

• is based on OOXML formats (docx, xlsx, pptx), unlike LibreOffice that has ODF as native formats.
• works online and allows real-time collaboration, like Google Docs.
• can be deployed on own server or integrated with another app, unlike Google Docs.

But it turned out many of the users still craved a desktop app , because:

• desktop apps are more familiar.
• they work faster (can use the system resources, not only browser ones).
• it is possible to use local fonts.
• language is determined automatically (in online versions you need to set up the doc and paragraph language manually).
• it is more convenient work to with clipboard.
• printing is effortless (no need to save a doc as a PDF first).

At that moment, our resources were limited, so we had to weigh our decisions carefully.

Methodology

The Option We Declined: Native Apps

If we had chosen to create a native app, we would have to rewrite all the code we had as well as reconsider visualization. Apart from that, in the future, we would have to test and update web and desktop editors that actually do the same things separately.

What We Chose

So, we decided to use the same old JS code from the online version to facilitate both development and updating.

We needed:

1. Same code for communication between JS and C++ . This meant that we needed a cross-platform browser engine. Since we were familiar with V8 (which we use for building file versions), we were going to use some type of Chromium.
2. Cross-platform GUI . We decided to use the QT framework to achieve that.
3. Being able to switch to a native rendering scheme in the future . We are not going to change the editors’ JS code, but we may change the rendering mechanism to speed the app up.

Rendering

As we postponed implementing native rendering, we needed a cross-platform WebView. We have several ideas.

1. Out of the box solutions which we might have used given that we chose QT, namely QWebView or QWebEngineView. However, QWebView was abandoned by its developers. It is also slow and uses the same process as the app does. This was critical for us because ONLYOFFICE editors have tabbed interface which definitely means working with several documents in the same instance at the same time. So, if a problem occurred in one tab and in one document, it would affect other documents in other tabs. QWebEngineView is based on Chromium and is actively developed. It is faster and works in a separate process. But it can’t work properly with native code in the JS code process. The communication there is organized by means of web sockets which we found inconvenient. Also, rendering on 4K monitors was slow.

2. Pure Chromium. Pros — speed and complete functionality. Microsoft’s Visual Studio Code, which is based on Chromium, made us give it some serious thought.

3. Chromium Embedded Framework. It is regularly updated (cefbuilds.com), easier than pure Chromium, but lacks some of the functionality.

We rejected standard approaches (first and second variants) and went with Chromium Embedded Framework. So, eventually, we implemented CefWebView tailored to our needs.

The App Scheme

The resulting application works as follows:

While creating a V8 context we embed own object, thus accessing the native JS code. If we need to transfer data to another process, we use a built-in CEF messaging mechanism for interactions between processes. Likewise, we send messages from the other processes to the JS one.

XCode for Mac OS

Not everything went as planned. For example, the app for MacOS was created using XCode, not QT.

We use QTabWidget for tabs with editors, and it’s rather slow with MacOS. This is all just about dragging and dropping the editors’ tabs, which doesn’t look like a serious problem. But to make it work correctly it was necessary to implement this control from scratch. And it was convenient to use XCode for targeting MacOS.

So, we do have some native code for this OS.

Conclusion

So, you know the secret now. Our desktop app is some sort of browser that works with documents only. It puts some restrictions, of course, but, in the end, it was totally worth it because:

• we brought desktop editing capabilities to our users.
• the app can actually be used as an alternative to MS Office/LibreOffice or as a client for the online version (which means you can access docs stored in the cloud and collaborate on them right from the app).
• it works on all platforms (as it is a browser, actually, it is capable of running on anything that supports HTML).
• the development and update processes actually save us time and effort as they are made for the same source code.

The source code for ONLYOFFICE Desktop Editors (as well as the source code for the online version) is available on GitHub . You can also download the application from the official website .