10 ms·

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

• guggle 5y ago
  > consistent across OS versions and platforms. 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. > over the past decade it seems like many apps have eschewed this anyway And I regret it.
  • nawgz 5y ago
    > > consistent across OS versions and platforms. > This is an upside for the developer only. 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
    • geodel 5y ago
      > ... 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.
      • nawgz 5y ago
        > It is worse because it is resource hog and slow even on high end machines And what of other factors? If it is worse in the dimensions you list but superior in: * accessibility * cross-platform capability * debuggability * library availability * user familiarity 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
    • user-the-name 5y ago
      Because it is not a consistent user experience, it is a consistent developer experience. For the actual user, the experience is inconsistent with the rest of their system.
      • anigbrowl 5y ago
        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.
      • nawgz 5y ago
        > 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.
        • user-the-name 5y ago
          Sure, if you're strapped for resources and are content with making sub-par tools, that's what happens. If you actually care about what you make and want to make it good, there are no shortcuts. You need to put in the work.
          • 5y ago
  • twobitshifter 5y ago
    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
  • dbrueck 5y ago
    >> 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.
    • robertoandred 5y ago
      There’s more to being a native app than the look of a checkbox.
    • CRConrad 5y ago
      > 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.
  • capableweb 5y ago
    > 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.
    • AnIdiotOnTheNet 5y ago
      How many of those users ever use more than one OS?
      • kbenson 5y ago
        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.
        • AnIdiotOnTheNet 5y ago
          I expect my tools to work well too, that's why they're almost never web-based.
          • kbenson 5y ago
            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).
  • kbenson 5y ago
    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.
  • journey_16162 5y ago
    > 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.
• Retric 5y ago
  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.
• bob1029 5y ago
  > 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).
  • kbenson 5y ago
    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.
    • bob1029 5y ago
      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.
• swiley 5y ago
  IMO: TCL/TK definitely beats it, no one talks about it though for some reason.
  • mwcampbell 5y ago
    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.
  • spacechild1 5y ago
    Tk is very limited. It's nice for very simple apps, but basically unusable for anything else.
• feikname 5y ago
  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.
  • anigbrowl 5y ago
    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.
  • dfox 5y ago
    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.
    • happyweasel 5y ago
      It's written in MFC, and the sourcecode is on github (https://github.com/microsoft/VCSamples/tree/master/VC2010Samples/MFC/Visual%20C%2B%2B%202008%20Feature%20Pack/WordPad https://github.com/microsoft/VCSamples/tree/master/VC2010Sam...)
      • homarp 5y ago
        "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
• malkia 5y ago
  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.
• happyweasel 5y ago
  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.
• zerr 5y ago
  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.
• jandrese 5y ago
  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.
  • hsbauauvhabzb 5y ago
    I’ve consistently heard this. Is electron actually at fault or is it poor coding?
• hsbauauvhabzb 5y ago
  Other than electron what options are there? I’ve heard electron has poor performance but it’s all anecdotal, I’m curious about opinions to the contrary
  • dbrueck 5y ago
    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.
• yakubin 5y ago
  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. [1]: Not our app, but for us to debug. :|