Thank you for providing Xojo. It enables me to follow changing customer functional requirements quicker than ever before.
Question:
Given the fact that more and more UI is via mobile devices, I wonder if it would be a good idea to make all Xojo-App GUI (Web,Mac,Windows,Unix) HTML5/CSS3. The console apps excluded obviously.
Reason:
It would limit your development efforts to 1 GUI environment, gives the app users a more consistent and nowadays expected behavior. And for App-developers it would limit the number of UI particularities to take into consideration while developing.
Overall that way the app quality (e.i. user expectation) can improve.
How:
Architectural it will require all desktop (Mac,Windows,Unix) apps to run an internal web-server, browser and api to handle local call’s.
Limitations:
Probably I overlook major disadvantages of this approach. Still I hope this is the way you can and will go.
Thanks again,
Boudi.
For my latest iOS app, major parts of the UI are HTML/CSS/Javascript inside iOSHTMLViewer. Simply because the controls don’t exist, like a decent grid (listbox).
This means you can already develop entire UIs based on Xojo’s HTMLViewer. So is the case for Tim Parnel’s HTMLEdit on desktop.
I do not think it would be Xojo’s philosophy, though, to go all out HTML/CSS/JavaScript. The main advantage of Xojo is precisely that it uses mostly native controls on each platform, so it looks native.
Thanks Michel,
I know and do the same in fact. I made the remark because some times I find myself programming around unexpected behavior in the Web Apps. Or making JavaScript controls myself. And I think the quality could become better if more Xojo focus goes into the Web UI. And since more and more user interfacing is via iOS or Android, more focus on HTML/CSS UI makes sense I think.
Xojo’s unique selling point is that it uses native controls regardless of the platform. I wouldn’t have used it since 1998 if that wasn’t the case.
I want them to properly finish Xojo iOS but, for me, that doesn’t mean that I want some sort of generic mobile UI that works across both Android and iOS. I want native controls on each platform. I’m just one guy but this is non-negotiable for me 
To be frank, I don’t have the impression that Xojo completely grasps the implications of a market where Android represents more than 50% of all OSes combined, including macOS and Windows 10. Where iOS itself is around 25% or so.
To me, it means the bulk of the market is Android and iOS. Yet, what do we have ? An iOS product that is way substandard, and an obvious total disregard for customer input. The smallest feature request like exposing background color, events or features that one would expect in Desktop, are met with blatant disdain.
If Xojo iOS was up to par with Desktop, we would not have to use HTML so heavily. I concur with Gavin : native controls are preferable, when they exist, and when they are implemented fully, not in a toyish and botched way.
I sincerely hope eventually Xojo sees the light and seriously starts beefing up its quite insufficient iOS product. Likewise, I hope they don’t plan on being ridiculous with a substandard Android product that barely does more than Hello World.
That said, the example of a listbox is evident : it simply does not exist as a native control. Then HTML is the way.
Good point Gavin.
To clarify my question, I did not mean to change the platform feel. Just the internal architecture.
iOS should feel iOS, Mac/Mac, Windows/Windows and so on.
Michel,
I don’t know. They very well could be working with the RaspberryPi as an intermediate towards Android.
In fact what i’m suggesting is very much in-line with industry tendencies. And also my arguments are the reason why Google and nowadays even Microsoft work this way more and more.
Also other development platforms that exist to build for iOs and Android in parallel in all cases I know of work this way.
My point was that you can already conceive today an entire UI in HTML/CSS/JavaScript, through the HTMLViewer in Desktop Windows, Mac and Linux. And of course Web, with some extra doing to manage sessions.
iOSHTMLViewer is notoriously indigent, but fortunately, Jason King created an extension that provides the necessary EvaluateJavaScript function and CancelLoad that should have been there from the start (another example of botched implementation).
I agree that there is a trend toward HtML/CSS/Javascript. Already back in 2013 when I started developing new API (now UWP) Windows apps, I noted that JavaScript was one of the development language for universal apps.
Today, it is quite possible to create entire applications for Android in HTML/CSS/JavaScript, and even distribute them in the Play Store.
BTW, since HTMLViewer is native, it does provide a lot of native controls. So indeed, using HTML/CSS/JavaScript is not the same as other development tools which have their own controls.
True.
My point was not about what we (developers) do with the Xojo platform. But thinking with Xojo to use their resources more efficiently. What will benefit us developers also in the end.
Look at this for example: https://electronjs.org/
There are tools which do this already.
If I wanted to do that, I’d use them instead of asking Xojo to be something different.
That’s like cursing a hammer because it isn’t a screwdriver.
[quote=376712:@Tim Parnell]Here are some articles and professionals talking about why this is a really bad idea:
Electron is Cancer - Casper Beyer
Electron is Flash for the Desktop - Joseph Gentle
Electron considered harmful - Drew DeVault
“You should have higher standards” - Bryan Jones
My favorite is the quote “Electron enables lazy developers to write garbage”[/quote]
I can’t say it enough, Electron is a resource hogging pile of garbage.
[quote=324585:@E J M van Vlijmen]Question:
Given the fact that more and more UI is via mobile devices, I wonder if it would be a good idea to make all Xojo-App GUI (Web,Mac,Windows,Unix) HTML5/CSS3. The console apps excluded obviously.[/quote]
ISTM that the difficulty here is then one of Xojo providing HTML rendering engines across all platforms that behave the same way. Already they do that with the HTMLViewer, and it works reasonably well, but do you want Xojo to have to write their own? If not, then they are at the mercy of whatever engines are provided by others, And there are some things that you are specifically not allowed to do (such as access the local file system) in the name of security. How would that work.
First version of my app was written as a mixture of PHP and javascript. The js ran in a browser and provided the GUI. If it needed to write to a socket or read an arbitrary disk file, or use SQLite, then it sent a request using AJAX to PHP scripts on the same machine to do the work (using an instance of apache). All this worked reasonably well.
Now: because the browser in use on the Mac version (Safari) started being more restrictive in what was allowed (e.g. you can no longer close a popup window from code), I’ve just spent 3 years migrating the whole app to Xojo, and only use an HTML Viewer for things that actually need an HTML renderer (in my case: I have received some arbitrary HTML I need to display).
I think moving away from the Xojo model would be a bad move.
At least now you can get an Apple laptop with 32GB of RAM, so you can run more than one Electron application at once 