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

Hey all,

Just to chime in here, loving this discussion, thanks David and
Clifford. Some really interesting gems in this.

My only two cents (one cent maybe) here is that I kinda underline Davids
opinion here.

Yes a lot of apps are just wrappers for HTML5/CSS/JS solutions and they
are only interested in the deployment method as many people still prefer
an app on their phone instead of having to browse to a webpage (yes I
know you can add icons that open up the webpage, but its still, most
people find that difficult or unintuitive).

Also whether justified or not, a lot of users have come to equate web
with slow or resource hungry. This is often not true and pure perception
for many modern solutions, but once tainted its hard to get rid of that
stigma. The only truth here that I do believe in is that performance has
a lot to do with experience, when you are used to making desktop
applications with the full resources of the desktop available to you it
is very easy to program in a style that is incredibly detrimental for a
web based solution.

For me however the thing that sways me most is those companies that have
developed HTML5/CSS/JS applications and are moving in the opposite
direction because they hit roadblocks especially as their application
gets far more complex then a chat client or music app (lets be honest,
Slack and Spotify are not examples of complex enterprise solutions and
not very representative in this discussion).
They start with a web based solution, package it, and then slowly start
replacing the internals where they are having problems.

Facebook springs to mind as one of those, where their earlier mobile app
was originally a full HTML5/CSS/JS based solution in a wrapper and
everyone hated the experience. They swapped out more and more core bits
for native code to deal with the issues they ran into.

Cheers,

Bas

On 8/10/17 2:11 am, David McKeone wrote:
> Hey Clifford,
>
> Yup, I’m aware that both Spotify and Slack have web components bundled up as native apps — it’s actually why I cited them. Even PgAdmin 4 has a pretty big web component now too, although they built their own Qt shell.
>
> My point was that they are delivered as native apps, not just web apps, which means there is still a space in the consumer mind that native apps have a role to play. Also, with oBrowser we can do that kind of thing for all or part of ours apps, just like they do. That was more my central point: the browser, as sole app delivery mechanism, has not won.
>
> Regarding Slack specifically, the actual operation of their web app makes me wish it was more native. Electron randomly hogs a lot of resources, and it’s not an awesome experience. Spotify has more of a Qt (C++) base, and it’s experience is much better, and different, from the web experience.
>
> To go further, here are all native apps that I do appreciate: Sublime Text, Capture One (photo editing), and Daylite.
>
> I appreciate native apps even more when I have to run on battery power. It’s not to say that web apps can’t also be efficient, it’s just that they aren’t usually, and some of the casual animation effects can take a way more CPU than you think. VSCodes famous 13% CPU blinking cursor is a good example: github.com/Microsoft/vscode/issues/22900
>
> __________________________________
> David McKeone
> Arts Management Systems Ltd.
> mailto:david@artsman.com <mailto:support@artsman.com>
> www.artsman.com <www.artsman.com/>

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com