FreeConferenceCall and Sciter.JS – project development notes

FCC, what is it?

FreeConferenceCall is an online conferencing/meeting platform with the following characteristics:

• Online conferences with several presenters and up to 1000 participants/attendees.
• Participants can attend the conference from desktop computer, mobile, web browser, and just by phone.
• Video meeting supports up to 25 simultaneous video/audio streams running. It can be more participants with transmitting video/audio, it is just the ones that are talking now are presented on connected devices.
• Any connected user can be allowed to be a presenter (by meeting organizer). Presenter can share their screens, particular applications and use whiteboard (free drawing tool).
• The platform supports textual chat and file sending/sharing.

Desktop version of FCC is a portable (monolithic) executable of size ~ 20 Mb. Supports hot updates.

Technology of desktop client

• Sciter Engine running UI frontend – HTML/CSS/JavaScript;
• Native C++ code, WebRTC, VoIP, etc. at UI backend;

UI Architecture

• Reactor based UI frontend:
  • Reactor is a native implementation of ReactJS and JSX embedded in JavaScript (ES2017) that Sciter provides out of the box.
• Native UI backend:
  • Manages UI state storage by issuing so called global events that interested components are subscribed on;
  • Provides implementation of native objects (SOM – Sciter native Object Model interfaces).
  • Supplies frame streams to <video> slots.
• Reactor’s entity views (class EntityView extends Element {}) receive events and consume data from those native objects.

Development timeline and workforce

Overall desktop client project duration: ~9 months:

• Architectural phase, ~4 months, four people:
  1. UI/Frontend architect/developer (that’s me as an invited contractor) – designed Reactor and overall class/modules project layout;
  2. UI/Backend architect/developer – designed front/backend integration principles – events, state sharing/persistence and core of SOM architecture – native objects tree for JS;
  3. UI (Frontend/Backend) developer (joined later);
  4. UI (Backend/Frontend) developer (joined later);

At this initial phase we’ve established structure of the project and provided proof of concept to stakeholders. Main goal was to demonstrate UI responsiveness and overall speed with the focus on minimizing CPU/GPU and power consumption on Windows (7% CPU showing 25 streams, sic!) and on Mac.

• Final implementation phase – 5 months:
  • More developers: the team was extended by 5 more UI (front/backend) developers – that are JS and C++ people;
  • 4 QA developers: gradually joined according to project progress;
  • 2 product Owners/Managers to manage the process and feature set implementation;
  • 1 UI/UX developer;

Development technologies

• Visual Studio and XCode for native development;
• SublimeText and VSCode for UI (HTML/CSS/JS) development; Babel plugin worked surprisingly well for development of Reactor code – modern JS + JSX;
• Git, private installation, as codebase storage. TortoiseGit and SourceTree as its clients. Some masochists gurus used Git command line tools;
• Team communication (fully remote: US, Canada, Russia, Ukraine, Poland) initially occurred in Skype. After first 5 months we have started using FCC itself for meetings. That helped to discover bugs and usability issues early.
• Bug tracking: Jira and Backtrace;
• Project management: plain old Excel sheets;

Afterwords

That was second major version of the client application. First version was using AngularJS alike architecture (developed 4 years ago) and was quite slow on complex screen updates involving tons of DOM elements, many of which were just hidden.

In contrast, React[or] is designed to render only those DOM elements that user can see, it really improves situation quite a lot. Also Reactor’s natural componentization / modularization schema is very beneficial.

And about code reuse …

Initially we were hoping to [re]use many of existing JS libraries. After all NPM has 1.3 millions of packages, at least something there should be useful for UI development, right? Nope!

To our surprise we’ve found just couple of them (literally) useful for this application: Remarkable (Markdown parser) and the one for Emojis handling (and even that is a subject for removal).

It appeared as all existing UI frameworks that were designed strictly for in-browser use are not suitable for UI of desktop applications (subject of separate article).