It's really hard to beat an embedded browser if you're doing a desktop GUI app. Yeah, I know, I know, there are downsides, but the upsides are compelling: very mature technology, can be very performant for many types of apps, extremely customizable, great tooling is available, huge resource pool of proficient developers, and the UI itself is more or less automatically consistent across OS versions and platforms.
Building a desktop app with an embedded browser always feels dirty, but honestly the alternative has always ended up being worse for stuff I've worked on. Buggy frameworks, missing features, cross platform support that is only 90% there, dealing with requirements for custom widgets, cost of bringing devs up to speed on it, etc.
Interestingly, a compelling reason for a non-web approach used to be that having native look and feel was a big deal, but over the past decade it seems like many apps have eschewed this anyway. It seems like most programs built in GTK always looks dated, and on Windows things have morphed so far away from the win32 look and feel that nearly everything modern looks like it might be a web page anyway.
> It's really hard to beat an embedded browser if you're doing a desktop GUI app.
You could also just make it a website and stop there unless there is some native hook you absolutely cannot manage via HTML5.
We started our product as a mobile app because of concerns over being able to access native device capabilities, but we have since reached a point where native doesn't make much sense compared to the amount of pain and suffering it causes us. Just the codesign process for iOS alone is not really worth the price of admission. This isn't even scratching the surface of xcode and the nightmare that is that ecosystem.
The only "native" thing we really need is the camera, and we have discovered a few reasonable shims for this particular concern (i.e. upload photo as a file).
Is the idea in a case like this to go full website, or use something like React/Vue to build a site that's just JS+HTML front end and API calls, and then ship a shim of an app which has a webview and the JS+HTML locally, and makes the same network API calls? Then it seems like the build process for native could be just about completely automated or at least reduced to it's basest components, and it's just dealing with App stores.
Is this a normal thing that's already done? As is probably obvious, I'm not a front end or app developer.
Our long term goal is to go all-in on server-side rendered UI.
For reference, we use Blazor server-side today and still feel this is still not extreme enough for us.
What I would like to see is something where all browser events are piped to our server and we send basic WebGL draw commands back to the client. This would give us pixel-perfect control over how the application presents on any device without worrying about a particular vendor's quirks. Everyone's implementation of a web browser is a little different, but when you get down to the primitive behavior of basic WebGL/canvas usages, the consistency is very strong across all platforms.
In order to accomplish this, the server would need to know about each clients' viewport dimensions, etc., so its not like its a free lunch on system resources. This is more about total control and maximum security.
> Do you have a plan for also handling accessibility if you go in this direction?
It is something I would certainly consider after meeting the most urgent objectives. There is no reason I couldn't consider offering alternative views for certain users which contain things like high-contrast or screen-reader enhancements.
The initial scope of this work would be for a privately-used B2B application. Accessibility in this context would be driven by our business customers' specific requirements.
That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion.
So from where I sit, and mind you I'm not claiming to be perfect about accessibility but I spend a good bit of time thinking about it, this answer gives me shivers. 'Cause like:
> It is something I would certainly consider after meeting the most urgent objectives.
In practice, this is pronounced "no."
> That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion.
In practice, this is pronounced "I don't care".
An application cannot describe "a button with the caption of 'OK'" without a UI framework that can and does tell it that there is a button, that it has a caption, and what that caption is.
To be honest, accessibility is a team effort from everyone and things are already bad enough without actively making them worse.
I appreciate that you're taking a stand for accessibility, but IMO, that kind of statement just adds to the shrillness of so much of our online discourse. We can discuss the pros and cons of various approaches to UI, and what it takes to make accessibility practical, without venturing into the topic of whether a developer cares about accessibility, which is likely to just make them defensive.
I'm pretty okay with this as a stance, to be honest, because folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way.
> folks have been asking those of us who are fully abled, very nicely for a very long time, to stop making things harder for them. Blithe dismissal deserves to be received a certain way.
I'm one of those folks (see my profile). I still ask nicely, and try to be nice even when responding to what seems to be a blithe dismissal, because I want to focus on solving the problem, without making developers feel unnecessarily uncomfortable about honestly discussing a sensitive topic. I still struggle with this, and might not have gotten it right in my own response to bob1029 yesterday, since that response got downvoted.
Also I'm not sure bob1029's original response is a blithe dismissal; he may just be honestly stating the decision-making process that makes sense in a business world where disabled people are a tiny minority. That sucks for us, but maybe I just have to have the serenity to accept what we can't change, and focus on what is feasible, such as reconstructing UI content and semantics using OCR and other machine learning techniques (like Apple is doing as an option on iOS), rather than trying to convince every UI framework and application developer to put extra work into accessibility. I've been resisting that conclusion, but I'm getting closer to accepting it.
I know you are, and I follow your stuff. :) My post was off-the-cuff a little sharper (to you, not to him) than I wanted it, because "shrill" is coded usually on this forum in a way you didn't mean it. Sorry for that.
I respect where you're coming from, and at the same time I don't think pointing out that putting something as the fourth-most-important priority means it will stay the fourth-most-important priority forever is "shrill". Because if you shove something baseline like a11y down the ladder like that, it's never coming up, and if characterizing that as "I don't care" makes somebody upset then it's probably a "look inward" moment, yeah? I think it's reasonable to demand that we as a profession not act to be noninclusive by default. Not, at this point, ask. Demand is OK. I think more must be expected of us as people, not just as technologists. The business world might indeed say "oh, small minority, screw them"--we must be ethically loaded as humane craftspeople to fight back against that.
It's kind of a money-where-my-mouth-is thing for me, and I'm very happy that my employer cares a lot about this. It's a video company, so there definitely are limits to what we are able to do for folks with sight impairment, but right now we're in the middle of an initiative for the conference we run to better enable hearing-impaired folks to enjoy and participate. It's not why I came to work here, but I'm glad we're doing it.
"Just add accessibility later" is the UI world's equivalent of "just add multiplayer later." Design for it, or it'll never get done and what does get done will be done poorly.
> It is something I would certainly consider after meeting the most urgent objectives.
What urgent objectives are met by replacing HTML with a server-side UI implemented on top of WebGL?
> The initial scope of this work would be for a privately-used B2B application.
That doesn't make accessibility any less important. Consider: if one of your business customers is trying to fill a position that involves using your application, and one of the candidates is blind (or otherwise disabled), a reactive approach to accessibility means that they would likely have to pass over that candidate, even if that candidate is otherwise well qualified for the job. Or an existing employee may have an accident or illness that makes them disabled. So I don't think it's a good idea to ignore accessibility, let alone do something that is sure to make it much worse, until a customer reactively asks you to pay attention to it.
That said, providing accessibility is more of a business/application problem than a UI framework problem in my opinion.
I entirely agree with eropple's response to that. Also, our best hope of applications being more or less accessible is for the UI frameworks to automatically implement accessibility as much as they can.
I generally like using Qt apps, be it Linux, Windows or macOS. Development with Qt is also quite nice, with very well documented APIs. The only issue is that sometimes there is something really weird going on with fonts (on Linux at least). E.g. in Quassel sometimes text looks as if it went through a cheese grater. And even though I have all the necessary fonts, I don't see some Unicode characters properly (emojis mostly). In Gtk apps they are displayed perfectly. I've been told it has something to do with Qt limiting the number of fonts that it goes through, although I'm not really sure.
As for Electron, this is such a poor runtime. Chromium's C++ (not V8) garbage collector is so unsophisticated that it sometimes blocks for several seconds on lower-end devices. At $dayjob, I got reports about UI unresponsiveness[1] and after looking at the logs, sure enough, 2.5 pause times several times, and mostly revolving around 15ms, 50ms, 70ms, 110ms etc. - wtf. That's just bad press for garbage collectors. Add to that, that each release consumes more memory than the one before. After that you look at all the different garbage collectors for JVM and wonder who even makes the decision to go for Chromium and not JVM, not to mention the quality of languages that target those two platforms.
> And a downside for the user as the GUI will probably not be consistent with its OS
Depends on what kind of "user". Many professionals that spend their day in software like the Autodesk suite of applications, Music production, Animation or other creative endeavors expect consistent GUI across OSes when using the same tool, not consistent GUIs within the specific OS for all tools.
How many of them might be following directions from someone or giving directions to someone on a different OS?
How often we use something and what type of things we're doing on it (work, play, etc) probably greatly affect how we think about this. I expect my tools to work the same no matter where I use them. For things I don't rely on to get essential work done, I care less, on a sliding scale.
Sure, but there's a difference between web-based and built using web technologies. Whatever other faults electron apps have, they're fairly consistent across operating systems. For a tool (like a chat client) that's very appealing. It's all that other things that seem to be endemic to electron apps (high resource usage, large size) that are the problem. Theoretically if you make a webapp that works fine on Safari Edge and Chrome you could use the OS provided webviews on iOS, MacOS, Android and Windows (and Electron on other platforms I guess) to ship local equivalents that are less problematic at the expense of more engineering work (or maybe just a leaner meaner electron competitor).
>> consistent across OS versions and platforms.
> This is an upside for the developer only.
This is definitely not the case. For some apps/branding, a particular style is more desirable than making sure a checkbox looks 100% native on each platform. And even the things that benefit the developer are not upsides just for them (think lower initial design & dev costs, lower testing costs, lower costs of new features - all of which mean resources can be allocated elsewhere).
> the GUI will probably not be consistent with its OS.
Like I mentioned, there seems to be a trend away from this as a goal anyway (even within the set of OS-provided apps). Probably it's a combination of it not mattering as much as we originally thought it did, and because end-users now have a familiarity with a core set of UI concepts. There's a short list of things you do to make a button be "button-y", and users know to click on it. They just don't care if it looks different than the buttons in some unrelated app.
> There's a short list of things you do to make a button be "button-y", and users know to click on it.
Could someone please inform Microsoft of this, so maybe they could try that in "Skype for Business"?
I have to use the fucking thing at work, and it's even more afflicted by the fucking Flat Where Everything Looks The Same look than the rest of their apps and OSes. For instance, whenever I'm in a chat with someone and initiate an audio call by clicking on the round blue handset button, it pops up a helpful little tooltip/label in the form of a (squared-off, because Modern) speech bubble! to tell me that what I've just initiated is a "Skype Call". Then I sit there and wait for them to pick up for a while, before I remember that the fucking speech bubble IS A BUTTON, and that I need to click again to start a call.
Holy fucking goddamn shit! The absolute worst company at following Microsoft's UI guidelines is... Microsoft.
Another example: Just a few hours ago I was switching back and forth between Excel and my text editor, copying stuff from one to the other. Half the time when I though Excel had focus, it didn't -- because the fucking thing can't even de-highlight its bloody title bar! Their interfaces absolutely suck nowadays.
Strongly disagree. How is a consistent user experience enabling developers to support more platforms at a higher level of quality going to lead to worse end-user experience?
To me: it's not, this is just anti-browser sentiment dressing itself up as enlightenment
> ... higher level of quality going to lead to worse end-user experience
This is just a management speak where degradation in quality is called 'next generation'. It is worse because it is resource hog and slow even on high end machines.
As a technical user I understand at least what is happening. On other hand non-technical folks are unable to articulate their frustrations which slick developers seems to take as users are satisfied.
and more, then what does this matter? Each choice made in such a domain as this is picking a point in a high-dimensional tradespace, and to blatantly disregard this obvious perspective citing "management speak" and "slick developers" doesn't really inspire confidence you're arguing in good faith
That's just one factor and while it may be true, do you really think that is more important that dramatically higher overall developer velocity and superior developer workflow, both of which contribute to more feature refinement, fewer bugs, faster updates, better support, etc, etc? Definitely not IMO. The fact that you are ignoring those other factors in your comments makes me think you are also ignoring them in your assessment of the options.
> For the actual user, the experience is inconsistent with the rest of their system.
This point is moot. If your argument is that each system has its own GUI semantics, and the developer fails the user by not developing within those semantics for that platform, then you are proposing the developer must do 1 unit of work per platform where previously it was 1 unit of work for all platforms. Therefore exactly 1 platform will be supported, and users on the unlucky ones will have exactly no experiences with this tool.
Or you can use cross-platform solutions which are themselves good tools, and disregard platform-specific semantics in favor of globally good UI/UX and let your tool stand on its own with no need for unnecessary, repetitive, error-prone platform porting.
Can you make a supporting argument for this? You state it as fact. I do not see why globally strong UI/UX should be a bad thing for users just because it disregards some standards of unknown quality on an unknown platform. Most methods of interacting with applications today are standardized and have no platform reliance; it is unclear to me why a developer whose tool delivers value in and of itself would suddenly not be delivering value to users just because their UI implementation did not perfectly match said user's preferred OS' UI standards. Actually, it's perfectly clear to me that the opposite is true.
> I do not see why globally strong UI/UX should be a bad thing for users
Except "globally strong UI/UX" is usually just design wankery that totally ignores decades of usability studies.
> just because it disregards some standards of unknown quality on an unknown platform.
Yeah, because the bleeding Windows UI guidelines that were in force for decades and known by hundreds of millions -- or are we in billions territory? Probably -- of users are "some standards of unknown quality on an unknown platform" nowadays.
Maybe you shouldn't revert to facile claims which don't even support your point, such as implying that a single good platform with good standards justifies never building anything cross-platform ever in any context?
> For the actual user, the experience is inconsistent with the rest of their system
Hmm... is that actually true though? If so, in what way?
For example, right now I have open, among other things, Spotify, Visual Studio, Vim, Chrome, and the Windows 10 Settings app. It's a fairly big mishmash of UIs in terms of styling, but in terms of how I interact with them, there is very strong consistency.
Well, it depends. Some tools I want to be OS-consistent and unobtrusive. I don't care for the newish trend of everything having its own 'dark mode' (none of which match each other) or the way this is offered as some great innovation when it's only about few pages of code to implement. I would much prefer to have better theming options at the system/WM level.
On the other hand, I have many specialized tools where the UI is superior that of the OS and if anything I would like everything else to look more like those. Ableton Live was an early pioneer of the kind of flat minimalism that people associate most often with Material Design, for example. At the time it was launched most music software manufacturers were still obsessed with skeuomorphism, albeit for entirely justifiable reasons because musicians often fetishize and want to emulate the sound of particular pieces of studio equipment.
Eh, some apps have been around longer than mobile GUI paradigms, to the point they've seen a few. As a user that's been around for a few of those as well, at this point I could care less. If you're around long enough, everything changes anyway, so whether it's learning a specific app's navigation and conventions on install or re-learning many small changes in all your apps, you're stuck with stuff feeling confusing and inconsistent at some point no matter what.
Personally, at least for popular apps, I prefer being able to explain how to do something to someone else and it just working the same way, regardless of what phone they are on, or if I'm lucky, to some degree even if it's between mobile and web.
Users trade a consistent GUI for programs that a) wouldn’t exist on their platform or b) would have a smaller feature set. So both developers and users benefit
> This is an upside for the developer only. And a downside for the user as the GUI will probably not be consistent with its OS.
Depends on how you look at it. I'm building an app and if it was not for Electron and web technologies, no user would get to use that app because it would not be built in the first place.
This is all quite true because an app has changed from what we knew about "desktop applications" in the past.
nowadays:
1) it has to look good, and the web is a platfrom most ui/ux guys understand.
2) it has to provide a dead simple ui that conveniently solves a problem.
3) It doesn't have to support all of the features of the underlying desktop platform.
4) it probably must be have network connectivity, and therefore all of the quirks of network security.
The tens of millions of lines of c++ code called a browser are basically that infrastructure.
One of my favorite offline "classic" programs of all time is.. Microsoft WordPad.
It's by no means great, but it's so lightweight and gets off your way that it puts modern online Microsoft Word and Google Dpcs to shame with its mere 16MB memory usage for simple documents.
I wish more apps did that, even if they looked like a Windows app inside macOS or vice-versa
I wonder if releasing a new framework that doesnt try to look native but still tries to make flow for each OS optmized (e.g. allows to choose file picker between native and own) would be a resonable alternative to electron. Perhaps even with JS support so the gazilliins libraries out there arent totally lost.
Oh I love it. I use Libreoffice for Calc which is good-enough and still open source, but Write is a horrible word processing experience. For text alone it's just aesthetically dissatisfying but as soona s you need to include pictures it's an active barrier to productivity. More than once I've spent hours fuming over a Write document with a looming deadline, then thrown it away and started from scratch in Wordpad and finished with time to spare.
I somewhat suspect that WordPad is the only MS application that actually follows all the MS recommendations about usage of Win32 API and Windows HIG/UX.
Going a bit on the side track over here, due to MFC being mentioned.
Given the current state of C++/WinRT tooling, even the aging MFC is more productive for Windows applications.
It doesn't matter it isn't modern C++, is full of CWhaterver, it is still more than good enough for those use cases where .NET isn't an option for whatever reason and C++ must be used.
"The WordPad sample demonstrates how to implement an application that imitates the functionality of WordPad, including the user interface elements and some of the capabilities." per the readme
Strongly disagree. I am frequently using lower power hardware and Electron apps are always slow and consume way too much memory for what they are doing. Even something simple like burning an ISO file to a USB stick can drag a system down to its knees because someone just had to make it an Electron app.
It’s only better when you don’t have enough time and resources to do a great job.
Using an embedded browser is inherently a compromise, but few companies can realistically support every platform natively without compromise. Cross platform UI’s simply a different kind of compromise and that’s where using an embedded browser shines.
Hear, hear, but if we follow this route, can't we just agree that the browser is already present in the system and reuse it? "WebView apps" that is... If there is no - we can just show the prompt to install that single instance of the browser, akin to what Flash/Shockwave/Applets/Unity Web or any other similar tech were doing.
It's not that hard - all you need is for your app to support mutliple monitors (of different sizes, DPI, orientation). Then the whole based on "browser" platform idea collapses. Maybe you can tweak it, by spawning additional browser? Maybe... You need docking. Start with this as your requirement. Proper docking, not Qt built-in one.
Nodewebkit and CEF are some of the main alternatives. And really, Electron is "just" something that does a lot of housekeeping for you, but at the end of the day you could do it yourself - you ship Chromium (or WebKit or ...) libraries, then create a native container window and then hand its drawing context off to the browser instance, shuttle events back and forth, etc.
CEF is kinda clunky, but also has bindings for just about any language.
As far as I can tell, Tk is entirely inaccessible with a screen reader. And I wouldn't be surprised if it's missing some other things that the OP author covered.
Building a desktop app with an embedded browser always feels dirty, but honestly the alternative has always ended up being worse for stuff I've worked on. Buggy frameworks, missing features, cross platform support that is only 90% there, dealing with requirements for custom widgets, cost of bringing devs up to speed on it, etc.
Interestingly, a compelling reason for a non-web approach used to be that having native look and feel was a big deal, but over the past decade it seems like many apps have eschewed this anyway. It seems like most programs built in GTK always looks dated, and on Windows things have morphed so far away from the win32 look and feel that nearly everything modern looks like it might be a web page anyway.