“Easier to get out of Omnis” (Formerly Studio – Github)

Hi David,

I consider those apps web apps even though they’re packaged to look as if
they’re native apps. They still use a browser to render
HTML/CSS/JavaScript. The way these applications are packaged has more to do
with ease of updates and having a predictable runtime environment than the
browser as an app delivery mechanism not winning. In fact, the browser has
already won because in every single one of those Electron wrapped web
applications, in oBrowser, and the Chromium Embedded Framework XCOMP we
built two years ago for Studio 4 that we have been using in production,
there is a browser.

The easiest way to distinguish between web apps and native apps is on
mobile platforms. A good example is Mattermost, which is an open source
Slack alternative. I’ve been using it for more than a year and I prefer
many things about Mattermost over Slack. One thing that absolutely sucked
about Mattermost was their mobile app. It was slow and all too often, I’d
have to wait for a while it re-rendered the message history. They recently
released a native mobile app and the difference is night and day. In the
old app, they were using Chrome’s WebView on Android. In the new native
app, they use the native renderer.

On iOS, the Mattermost app apparently feels and behaves like any other iOS
native app. On Android, it feels and behaves like any other Android app.
The desktop client is, again, an Electron app. Mattermost does not have
three separate code bases, one for iOS in Swift or Objective C, another for
Android in Java or Kotlin, and yet another for the desktop in
HTML/CSS/JavaScript, or whatever other technology they could have used.
They have one code base for the client – ReactJS. React Native < facebook.github.io/react-native/> handles the mobile app < github.com/mattermost/mattermost-mobile>. They have a different
code base that uses ReactJS for the desktop <github.com/
mattermost/desktop> only because the desktop app predated the native mobile
apps. Eventually, the two will be merged.

We’re going to have to deal with these issues once we’ve finished migrating
out of Omnis to a pure web application. I know our current web application
can run on mobile devices but it’s not feasible to do so because the
application consists of a hybrid fat-client Omnis library and the web
application. Our customers only use the web application by interacting with
an Omnis window that happens to contain the CEF XCOMP browser component.
The day we have migrated completely out of Omnis, the web application can
“break out” of that Omnis window and be used in a browser.

Whether that browser is actually a browser like Chrome or one that is
running within an Electron application is immaterial. It will still be
running in a browser. I know the current web application would be a horrid
user experience on mobile because it models the legacy application’s user
interface, which assumes a user with a keyboard and mouse. We will have to
deal with that issue as we get closer to the end of the migration. To me,
dealing with that right now would be premature optimization. By the time
we’re finished our migration out of Omnis, there will be even better ways
of maximizing code reuse between a desktop web app and mobile web apps,
e.g. <www.nativescript.org/blog/sharing-code-between-web-
and-native-apps-with-angular-2-and-nativescript> and < developer.telerik.com/featured/building-angular-
2-web-native-apps-single-codebase/>. Similar initiatives exist for ReactJS.

As for your comments about resource consumption of web apps, that can be an
issue and I am not concerned at all about it because if it is a big enough
problem, a solution will be found. I have noticed random CPU or RAM spikes
with VSCode but it’s updated frequently enough that those sorts of issues
get handled pretty quickly. The next wave of web applications will be
targeting WebAssembly <webassembly.org/> so we’ll be able to target
a much lower level runtime with the same high-level languages we’re
currently using. Modern browsers support WebAssembly already. See this: < webassembly.org/demo/Tanks/>. If you don’t see a Unity WebGL game in
your browser as I’m seeing in Chrome 61 on Linux, try a newer browser. Web
applications are not just the future. They’re the present, too.

Regards,

Clifford Ilkay

+ 1 647-778-8696 <(647)%20778-8696>
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com