Well now, the reason why I’m redoing it in Xojo is I was finding that more recent browser versions were starting to forbid things I needed and which therefore required work-arounds. My original version was, by and large, fast enough, but although the Xojo version is also fast, there were some areas that required me to use various tricks such as keeping text as an array of characters rather than in a text variable, in order to obtain adequate speed. Having two frameworks doesn’t help, either.
The original version won’t get updated any more; it was largely done as a proof of concept for my own amusement. I keep working on the Xojo version, however.
It’s still not an ‘either or’ issue. You can use Xojo with html + js + css to create a very nice app. That’s what Xojo Web Apps are behind the scenes…
Daniel listed some nice reasons why to use Desktop Apps over a Web App, but that results in the creation of a Desktop App + iOS App + Android App + Public Facing Web App. A single responsive Web App solves that problem very nicely without the mess of 4 separate apps.
I love the css ability to change the visual part without the need of touch anything else (js or html)
inherently there is a separation between the visual and the logical part. that’s awesome.
[quote=377815:@Hal Gumbert]It’s still not an ‘either or’ issue. You can use Xojo with html + js + css to create a very nice app. That’s what Xojo Web Apps are behind the scenes…
Daniel listed some nice reasons why to use Desktop Apps over a Web App, but that results in the creation of a Desktop App + iOS App + Android App + Public Facing Web App. A single responsive Web App solves that problem very nicely without the mess of 4 separate apps. :)[/quote]
I agree, but the OP was about a desktop use, apparently.
OK. So I read too quickly. At any rate, I still think using web technology in a desktop app is not the best way to produce elegant programs that provide a great user experience.
Certainly not the best way. But it’s an easy way to create rich user-interfaces without being a design expert. The developers of Xojo make a big deal to point out that desktop controls are all native OS controls, which certainly has its advantages, but most of the projects I work on these days need to look more modern than what native controls are capable of.
Animation, transitions, themed skins on controls are all things that I can do in WPF that are not possible in Xojo without a heck of a lot of work. I would love a way to create these interfaces in HTML/CSS/JS, drop them onto a xojo desktop app window and be able to access the control events for the meat of the software. I understand there is some software bloat and resource penalty with this approach, but realistically very few users care about that. They care that they have an interface that’s easy to navigate and “feels” good. This is Apple’s approach - Design comes first, performance second, and they’re the most valuable company in the world for a reason.
I realize this is a little different from what the OP was talking about, just something that has been crossing my mind lately.
I am extremely familiar with web development, so not only do I understand the engineering part of such a project, but also the potential design advantages.
Indeed, It is possible to do extraordinary feasts of graphic design with CSS/HTML/JS. BUT, and that is a bit one, it does not comply to Apple’s Human Interface Guidelines, which means it will look very odd on Mac, where using native controls is extremely important.
I don’t know about Linux, which somehow is much too fragmented to have strong general design guidelines as the other platforms, but I suspect it may be more welcoming of a Windows look.
In all, the notion of cross development using web technologies seems quite fine for Windows and perhaps Linux, even iOS and Android, but it will look much too odd on Mac to constitute a good solution to produce the great user experience that platform is famous for. I feel Xojo is way preferable for Mac.
The problem is there’s an obscene amount of software bloat and resource penalty. And it’s not something that can be worked around. It can only be mitigated, sometimes at great expense in terms of dev time. If it was just RAM use it would be…tolerable. But it’s not. The web stack is fundamentally flawed in how it organizes and renders visual elements (the DOM) leading to a heavy CPU penalty for even simple 2D changes. This problem is amplified in any scenario where there’s constant interaction and a constantly changing screen.
I just got off an audio meeting in MS Teams (Electron based). There’s something curious about Teams. If you are in an audio meeting, no screen sharing, it will consume 40-80% of a dual core i5 or i7. If you minimize the app…5-10%. The actual audio streaming is not the issue. The issue is that Teams provides a ‘heartbeat’ animation around the selfie of the person speaking. This animation spikes the CPU with just one person talking (40%). With two people talking it consumes virtually the entire CPU.
This is not a one off incident, nor is it a mere curiosity. Discord, for example, spikes hard with even a slightly busy chat. No fancy animations or movies or even audio, just text appearing on the screen. VS Code became a meme when it was discovered that it burned 13% of CPU time at idle. All it was doing was trying to animate a blinking cursor at 60 fps. Understand that a Mac Plus from 1986 could animate a text cursor at 60 fps, if it was asked to, and not consume 13% of its 8 MHz CPU.
I have been in more than one professional meeting (Teams) or chat (Discord) where a key participant had to drop out due to battery exhaustion on a notebook that’s supposed to last all day. I’ve also ditched HTML-desktop productivity apps for native equivalents…even if I lost features…because I got tired of hearing my fan or wanted to work remotely without a power outlet.
Users absolutely care about this. They hate it. The problem is that the average user doesn’t know who or what to blame. They’re not opening Activity Monitor or Task Manager and identifying the culprit. Their general response is “why is my bleeping computer running so slow?”, “I must have a virus”, or “I need a new computer.” So the frustration they feel is almost never translated into lost revenue for businesses who would then adjust their priorities.
I say “almost” because there are niches where it is properly conveyed. Gaming is a big one since low fps = unplayable = lost sales. High end media creation (photos; audio; video) is another one because the tasks are inherently demanding and those people will pay for something that saves them time.
“Feels good” can be done without the weight of HTML/CSS. As for navigation, that is best done in accordance with the HIG for the platform. Ignoring those guidelines and the general look/feel of a platform often results in slower navigation and lower productivity. I’ve cursed out loud before while trying to find something because I expected it to be in location A, like every other program, but it was in location B because some “UX engineer” wanted to be creative. Consistency may be boring at times, but it’s easily remembered, fast, and less likely to frustrate the heck out of some poor user.
Apple puts a huge emphasis on performance and their software is generally near the top in those terms.
I don’t mean to turn this thread into a blog or make you feel like I’m attacking your position. I just have a hard time expressing my frustration when a modern application consumes billions of instructions per second for a simple task, or leaves me scratching my head as to where a feature is located, all because it’s using HTML. We are stuck with the web stack for the web. We don’t have to be for productivity applications.
Not all Electron apps are automatically bad actors or memory offenders. Visual Studio Code I leave it running for days and use it for everything and it hovers below 200mb. It has more to do with how those apps are built then anything else.
An Electron app at its core is not dissimilar to keeping a tab open in your browser. It just like a poorly written Xojo app can be reckless and perhaps it is a tad easier to be reckless but nonetheless programmer skill and type of application account for a lot.
I seem to have failed in communicating the key point.
The web stack itself is a bad actor in terms of performance. The web stack on the desktop is also a bad actor in terms of HIG and OS integration. Saying that an Electron app “only” uses X memory or Y processor time does not absolve it. What would a native app use? The answer to that question is often shocking.
I don’t want to side track onto VS Code specifically, but it has a number of issues beyond the famous 13% fiasco. No doubt people use it because it brings some things to the table. I (have to) use Teams and Discord for the same reason. That doesn’t make the initial decision to use the web stack on the desktop a good one. Lots of people are noticing that it’s a bad one regardless of the quality of work on top of that stack.
@Daniel Taylor
I can see your point. Still it leaves Xojo internal with an effort to harmonise between GUI objects for the several platforms. I try to think with them. More from a functional cross platform point of view. Harmonizing the GUI objects, classes or controls based on the web-reality seems to be a good idea.
You are right in that the ‘all web stack based approach’ is not optimal. But Xojo’s history is clearly Mac based. Maybe it is time to start from a web-controls set and derive all other platform controls from there?
+100. If this isn’t an exact use-case for Xojo web I’m not sure what is. I suggested that a long time ago and the answer was they didn’t have time or resources to do it. I’d sub it out as a project to one of their power user customers so it does not detract from development on new products.
Xojo web is intriguing, but it’s difficult to get answers on how many concurrent users it can handle, how does it scale, etc. etc. The answer is always “it depends”. If you want to introduce a new technology and expect people to adopt it and invest time in it then it’s critical you demonstrate its true capabilities. Especially when there are deep rooted industry standard technologies which you are trying to displace. I do think having feedback deployed on Xojo Web would be a testimony of the product capabilities - it would sell more product.
+100 to this. 100% of my development is now with Xojo Web, and I would love to see them use it internally as an everyday technology. Having said this…I’m really looking forward to their 2.0 release.
[quote=395954:@Joseph Evert]
Xojo web is intriguing, but it’s difficult to get answers on how many concurrent users it can handle, how does it scale, etc. etc. The answer is always “it depends”.[/quote]
But that is the answer! XOJO is not going to cause the problem in scaling up to manage say 50k+ concurrent users if necessary. It is going to come down to the skills, knowledge and experience of the developer and the architecture chosen.
If you build one monolithic application, stick it on a server in cloud it might bomb with five or ten concurrent users. If on the other hand you break it down into micro services, use a container management tool to deploy it on AWS or Azure and set it up to take full advantage of the available scaling capabilities offered you could easily handle 10ks of users.
How well something scales these days depends on the architecture choose and the technology you chose to deploy on not the language chosen.
