Developing a Web app for use as a desktop app?

I’ve been working on a new UI experience for a few of my apps. In each case, I’ve been able to get to around 80% converted to a more modern look and feel, but without reinventing a large portion of the Xojo API and SDK for controls like popupmenus, checkboxes, radiobuttons, etc.

However, after working though a few Web app examples, it’s quite obvious that we have far greater control over the display of controls under the Web frameworks.

Has anyone looked at creating self-contained Xojo Web apps as desktop apps? I found the Electron platform recently and when it’s combined with JavaScript packages, it can be used to create some pretty powerful app (Atom, Visual Studio Code, etc.).

Smart kids say NO to Electron. (it is the worst.)

Why?

  • Uses a ton of RAM for no reason
  • Poor performance
  • Bundles an entire web browser rendering engine into every app
  • Creates huge “final products”
  • Non-native UI elements
  • Tons of extra work to get UI elements to play friendly with assistive devices

Need a list of slow, clunky, and bad Mac apps?
Atom, GitKraken, Spotify, Slack

It’s really just the worst framework. Myself included, there’s a community of people who trash an app before opening it if we find the Electron framework.

You have the power and advantage of native desktop apps with Xojo. I think you are focusing too much on creating an interface that doesn’t use standard controls. When you seriously consider Electron as a solution, you’re headed down a very bad path.

More on why Electron is a bad decision

I’m not focusing on Electron, it just gave me the thought that we should be able to do similar work with Xojo’s Web framework.

However, one comment about “Native” UI elements - I want it to “Look” right and that has recently been in disagreement being native on all three platforms. The dark look that we’re seeing in apps like DaVinci Resolve, Photoshop, and the like are definitely not native, but ARE becoming the accepted norm for professional tools and apps.

Hey Tim,

I’ve messed with this a bit. I made a Mac App with one Window and an HTMLViewer. On launch it would start the Web App using a shell and then load 127.0.0.1:xxx. When the Mac App quit, the Web App quit. The Web App was stored in the Mac App Resources folder.

So it just appeared to be a Mac App. I’ll try and find the source and post a link to the TurDuckEn here.

I am actually giving a presentation at XDC about this very topic. I have used the HTMLViewer class in Xojo to do just this for several consulting engagements. The end products have been very successful and there are many pros/cons to this approach.

I do not share Tim’s hatred for said approach. Whatever your feelings about Spotify and Slack you cannot dispute their market strengths. Also Visual Studio Code takes this approach which has become my favorite text editor because it functions exactly the same in all environments.

Native widgets are great and performance is excellent but sometimes with a cross platform approach you really want a unified user interface. Xojo can only get you so far with its lowest common denominator widgets and Windows flickering (non-existent with HTMLViewer). Also many advanced features like map visualization, charting, and the rest is MUCH easier with a plethora of options available in javascript.

The biggest challenge is bridging between javascript and Xojo. This is the kind of code and frameworks I will be demonstrating and sharing at XDC that have made me very successful at doing this. Also I should add that Xojo upgrading their WebKit implementation to CEF3 is a big boon in this area.

I tend to avoid electron based apps not because they are electron based but based on the quality.

[quote=354014:@Tim Parnell]Why?

Uses a ton of RAM for no reason
Poor performance
Bundles an entire web browser rendering engine into every app
Creates huge “final products”
Non-native UI elements
Tons of extra work to get UI elements to play friendly with assistive devices[/quote]

several of those are the same reasons I tend to avoid them too.

Now I use Atom editor all the time. it works well and gives me the functionality I need. Now I have to reboot the app daily (sometimes more often) as it goes stupid. And yes it takes a ton o memory. If there were a Xojo port of it, I would be a happy happy camper.

Unlike some here I wont delete an app just because it is electron based. I delete apps based on their performance/usability. hence why I tend to delete java based apps faster than anything else.

There are some great comments here. One of the issues I see and already have been beaten up about is that a lot of users are now getting used to HTLM5 interfaces and SaaS apps, whether internal or out there in web-land. They’re becoming accustomed to this. A recent thing I was involved was they wanted both a Windows and a Mac app but wanted the UI to look identical. The example shown came from a SaaS app so the message was abundantly clear.

I want to continue this one in Xojo but haven’t spent anytime seeing if I can achieve the non-conformity of native controls!!! yet. Having looked at my Slack program running on my Mac, I have 6 Slack groups open, I’ve consumed 1G of memory!!! (I have to sometimes restart Slack in the afternoon too as it goes white on me!)

Oh well, it’s the future they keep telling me.

I can’t seem to find the project I mentioned… It didn’t do anything more than I stated. I’ll be interested to see Phillip’s presentation.

A while back we developed a Xojo Web App using the Web Framework that ran on a Windows box and was accessed by an Android app developed in ADK / Android Studio. The Android app handled talking to the hardware for flashing the flash, playing ringtones, playing recorded audio messages, and even recorded audio. Each of those would communicate with the Web App via the page title or javascript to get/set Xojo WebTextFields. It was neat and worked. If I had to do that now, I’d probably use HandleURL to communicate data for those tasks along with a timer on the Xojo Web Page.

We’ve noticed this trend for a couple of years now (especially when writing apps for bigger companies). They don’t care for native controls. They want it to look the same on whatever platform their employees work on. Much easier for there support team or when one is moved around.

It is still different for single user apps (commercial individuals). They want their ‘Mac’ app and their ‘Windows’ app, as most of the time they only have one platform. But even there it is gaining momentum.

UI and Performance are the most important parts for using an App.
My Experience with Xojo was:
If you design an App on a mac and compile it for both Windows and OSX it results in a very ugly Windows UI. That‘s the reason we decide not to migrate to Xojo. The Effort to have the same looking Apps in both worlds is not acceptable.

The Effort to have the same looking Apps in both worlds is not that difficult. (harder if you bring Linux into the mix)

But true, you shouldn’t develop on a Mac, compile for Windows and just ship it.
You do have to check what it looks like on Windows and make allowances.
But ‘not acceptable’ ?
The UI tweaking shouldn’t take more than 1% of your development time.

we‘re Talking about an erp-system with more than 500 dialogs and it‘s definitley not a 1% tweak.
For my opinion you cannot use the standard controls to achieve a good modern UI under Windows. So you have to develop your own.

@ Hans-Jürgen Müller But did you find a solution that lets you program on macOs and compile for both macOs and Windows and get decent results for windows without any extra work for the Windows version? If so, what?

We currently decided not to create a Mac version of our erp system.
We‘re using xojo only for iOS Apps.
We did some programming custom controls to check out the effort necessary for building a similiar UI as we provide actually. After that we move the project on hold since we‘ll have enough resources.

Not really much to do with the topic, then.

On the other hand:

This should be interesting.

i found the opposite view with them. the company itself doesnt care but the users of the apps do. the Windows peeps dont want a non-windows looking UI. the MacOSX peeps dont want a non-Mac looking UI. the Linux peeps dont want a non-UNIX/Linux looking UI. etc. i have had a few apps that the company accepted and less than 60 days later only 1-2 people are using (out of the 100s or 1000s that suppose to use it).

I am looking forward to the presentation. maybe html + xojo can produce an app that everyone likes.

They can describe what one looks like? :wink:

A terminal window :stuck_out_tongue:

j/k

yes they can. either KDE or GTK (depending on the person) look and feel.

the GUI is so we can open more terminal windows… :slight_smile:

I usually code on a Mac and deeply on Both Mac and Windows, but for the type of in-house apps I write “beauty” is secondary to functionality. For my needs for UI don’t have to do too much more than reverse button positions (which I handle with a container control).

That said, I would think if ones designs on Windows and sticks to the Xojo framework, there would need to be almost no UI tweeting for the Mac for most windows/dialog, and most what there is could easily be reusably abstracted with teh right UI design.

But if the Xojo framework controls on Windows are not modern enough for one 's needs, that would not make Xojo a good match.

I personally much prefer native controls over a web-like UI on the desktop. Regardless what matters most is functionality and ease of use. Most web apps I’ve used are not as easy to use as native apps and are more limited than there desktop counterparts.

  • karen