16 ms·

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming co

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app has a web version and you have to deal with it anyway , but thereare a fair amount of Electron only apps. Or even with a web version, the desktop app often has special features not present on the web. But webviews are as much a moving target as browsers and often behave differently from the regular browser version in a myriad of ways, so you need an even bigger testing matrix. Webviews are also hard to properly secure and don't provide the extensive APIs of Electron, which you often have to bake yourself in a wrapper written in, eg, Rust or C++. I say all this as someone who hates how resource hungry Electron apps are and groans each time about yet another one on my machine, but I understand why it is so popular.

brundolf 6y ago
> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked. I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.
- 908B64B197 6y ago
  > Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!) More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
  - brundolf 6y ago
    Chrome didn't even exist until 2008. Firefox existed and had a foothold, but it was very much a minority. IE was >50% until 2010 and remained the single most popular browser until 2012: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/media/File:BrowserUsageShare.png https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/m...
    - ahepp 6y ago
      what happened in 2018-07?
  - mumblemumble 6y ago
    Some corporations did that. Most didn't. The main reason IE dominated was that most people didn't care, and stuck with the default. The main reason old versions of browsers were more common than new ones was that self-updating browsers hadn't become a thing yet, and most people didn't care, and just stuck with the default. The reason most browsers stay up-to-date now is that modern browsers are all configured to self-update by default, and most people don't care, and stick with the default. I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
    - brundolf 6y ago
      My experience was that IE finally got bad enough (around version 8), and Chrome got good enough, that even "grandmothers" started having everyone telling them to use Chrome, and it was so incredibly superior that you didn't have to be technical to appreciate it. Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
- datalus 6y ago
  Make no mistake, it's still a dumpster fire. Just maybe less raging.
  - brundolf 6y ago
    I worked on a highly complex web app for ~3 years, and we made a point to support Firefox, so whenever somebody had a Firefox-specific bug we wouldn't tell them to just use Chrome, we'd fix it. We only had 2-3 Firefox-specific issues in that entire time. I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
    - mrec 6y ago
      Similar. Built a very complex app officially aimed at oldIE but made a point of ensuring it worked on other browsers too, largely on a skunkworks basis. A few years later (when we're no longer actively working on the app) everyone switched to Chrome and it Just Worked. Someone tried it on an iPad and it Just Worked (modulo some fat-finger challenges with small UI affordances). At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
- danudey 6y ago
  Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend. For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority. IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
  - Klonoar 6y ago
    Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.
    - deleted 6y ago
      [deleted]
    - brundolf 6y ago
      It also launched 8 years ago; the web has changed a lot since then. Edge wasn't even around until 2015, much less being used for webviews.
      - Klonoar 6y ago
        This sounds like you didn't look up and read the comment in question. Problems with cross-platform webviews stopped being the HTML/CSS/JS layer long ago; it's integration, availability, and rate-of-updates that are common blockers. Call me when Microsoft actually ships WebView2 with the OS.
        efwfwef 6y ago
        if you would link to that comment it would be helpful
- jlokier 6y ago
  I run three browsers on my desktop, because the number of things that don't work properly in anything except recent Chrome is enough that I keep encountering issues, I don't want to use Chrome for my regular browsing, and both Safari and Firefox have issues on some sites. On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill. My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things. I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS. This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken! Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory. I know, that feels wrong somehow, but it's true. Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
  - encom 6y ago
    One major benefit of running webapps in an actual browser like Firefox, instead of Electron, is that I can have uBlock and a handful of other defensive plugins, to prevent shady things happening behind my back.
- morpheuskafka 6y ago
  That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.
  - briandear 6y ago
    > Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps. I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one. What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
    - ZephyrBlu 6y ago
      > I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app The point is that its effectively a web app. > What value does electron add to the user? They have a desktop app faster than if it was being built natively.
      - simonh 6y ago
        Or at all, how many Electron apps would bother with native Linux clients for example. Some maybe but certainly not all and probably not most either.
- oxymoron 6y ago
  In 2008, when IE7 came out, I cried of joy. I turned 22 that year, so the 7 years with only IE6 and Firefox was a significant chunk of my life. Firefox showed us that the web wasn't finished and could still be improved, and then came Firebug which made Firefox first web dev the obvious choice. But the vast majority still used IE6, so there was always a miserable step in the project of fixing all the IE bugs. After doing it for years and knowing your foe, it was by then a relatively quick and manageable experience. The real pain was in knowing all the CSS2 features and other goodies that could never be used. Seeing Microsoft recognizing that, yes indeed, the web wasn't finished in 2001 was actually an emotional moment at that point. So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
  - mattmanser 6y ago
    I've had to say this a fair few times here, but I'll keep saying it. IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember. So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
    - oxymoron 6y ago
      I was young and dogmatic, so I did admittedly despise Microsoft back then. I can't recall I ever heard of IEDevToolbar, though. Did it really feature the DOM tree view where you could do CSS manipulation? I always had the impression that it was a Firebug invention, but I could be wrong about that.
      - treve 6y ago
        The DOM inspector view in Firefox predates Firebug by years. My memory might be a bit shaky, but it may even have existed in Mozilla Web Browser? It really looked like a 'DOM tree/tree of Javascript classes' though, not really like the inspector we have today.
- Tijdreiziger 6y ago
  Anecdotally I wrote some JavaScript just today (I'm not a frontend dev but I write some simple stuff for fun sometimes). It seemed to me that every modern feature you'd care about is now widely supported. I used the JS fetch API and template strings and these things just work in modern browsers. I even encoded my web fonts in WOFF2 only, because it's so widely supported that I didn't see the point in bothering with WOFF1 too.
- Xevi 6y ago
  Tauri also uses MSHTML (Internet Explorer) on Windows. And there's no way I'm going back to developing for that.
  - nicklarsennz 6y ago
    Isn't IE just using Chrome now? Or do you mean support for old IE?
    - nicoburns 6y ago
      Their browser is. But Windows' webview is still the IE11 engine.
    - Xevi 6y ago
      No, IE is still the same. But Edge has moved to Chromium.
- smt1 6y ago
  There is also servo, which may not be as complete as Chromium, but is definitely interesting architecture wise, especially with the number of virtual machines and compilers written in Rust these days.
deleted 6y ago
[deleted]
modeless 6y ago
I question how major that benefit is. I think strict Electron-only apps are not really that common. All the ones I use have a web version.
munificent 6y ago
> Webviews are also a moving target so you need a big testing matrix. Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it. At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.
- deleted 6y ago
  [deleted]
- brundolf 6y ago
  It's not hard to silently auto-update an Electron app's internals; I assume the same is true for Tauri
  - timerol 6y ago
    The issue would occur if the auto-updater itself broke as a result of an OS upgrade
    - brundolf 6y ago
      Seeing as the auto-updater wouldn't have anything to do with the webview, I don't see how that's any more likely to happen in this case than it would be in Electron, or any other desktop application for that matter
- snemvalts 6y ago
  Need a docker for electron
908B64B197 6y ago
I have to post it here because it's on top: On Windows the new WebView is Chromium. https://developer.microsoft.com/en-us/microsoft-edge/webview2/ https://developer.microsoft.com/en-us/microsoft-edge/webview... Old one is, of course, kept for compatibility reasons.
- the_duke 6y ago
  Yes, but it is not installed by default. You have to install it separately, at least for now,which makes things a lot more complicated if you want your app to rely on it.
  - encom 6y ago
    I'm moderately certain that Chromium is installed by default on new installs of Windows now.
    - Klonoar 6y ago
      WebView2 does not use that Chromium, however. It's slightly absurd, and you should direct the "WTF?" to Microsoft for this.
  - oldmanhorton 6y ago
    Edge is pushed to the vast majority of PCs, and on those machines, I believe it provides a system-level webview2 component. You can choose to package your own webview2 into your app if you want the extra compatability that offers at expense of app size and ram usage
pjmlp 6y ago
A major benefit of Electron to Google is the amount of FOSS developers helping to turn what is left of the Web into ChromeOS.
runarberg 6y ago
> don't have to deal with all the small but time consuming compatibility quirks. Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser). An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.
- hobofan 6y ago
  This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers. On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
  - danudey 6y ago
    Because then you'll get a more efficient app that people don't constantly complain about? Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
    - hobofan 6y ago
      Apart from the install size which is still not optimal, it is very much possible to write an efficient Electron app, as evidenced by Discord and Element. That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.
      - plorkyeran 6y ago
        Discord is efficient now? I have to restart it on a regular basis because it starts using 5+ GB of ram.
ASalazarMX 6y ago
> A major benefit of Electron is that you can develop against a single browser version and don't have to deal with all the small but time consuming compatibility quirks. Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.
- brundolf 6y ago
  Nearly every successful technology is a prototype that went out of control :) That doesn't mean we shouldn't try and improve on things given the opportunity, but it's not an indictment either
- babypuncher 6y ago
  I think they're overstating the browser compatibility problem too. It was really bad 15 years ago, but today it is almost a non-issue. Between significantly improved standardization of web technologies, and new tricks like polyfills, I think it has become pretty uncommon for apps to not just work on multiple browsers without any tinkering.
  - jlokier 6y ago
    I use Chrome, Safari and Firefox on a Mac. In my experience, unfortunately it isn't true that apps work with very high reliability. This is why I use multiple browsers. I don't want to use Chrome, and I encounter new websites with functionality that don't work properly in Safari or Firefox quite regularly. Some of this is even quite basic functionality. From things like shopping carts where the final payment button doesn't work in Firefox (nothing happens), to video conferencing that sort-of works in Safari but then the audio breaks while it is reliable in Chrome. Even GitHub doesn't render properly in Safari occasionally (the page is full of weird size text and giant rectangles). But that's almost certainly a Safari bug.
    - babypuncher 6y ago
      I think this is more a problem with developers working in Chrome and using Blink-specific features. I stopped having compatibility issues with my apps when I moved to Firefox years ago.
albertzeyer 6y ago
But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max). Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save. The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.
- OskarS 6y ago
  Dynamically loaded system libraries use shared memory. You can load it once for the entire system.
  - albertzeyer 6y ago
    That's what I mean by executable code. But that is only really minor (<100MB or so) compared to the remaining resource usage.
    - OskarS 6y ago
      Ah, sorry, I missed that in your comment.
- sophiebits 6y ago
  They’re not inherently more efficient (other than the reduced application size), but Safari and Edge are both more resource-efficient than Chrome.
- deleted 6y ago
  [deleted]
- cozzyd 6y ago
  100 MB / app is significant, especially on laptops. Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.
e_y_ 6y ago
I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated or otherwise problematic for your application? With the idea that you could eventually migrate to system webviews. That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you don't have that choice.
- themihai 6y ago
  >> I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.
nix0n 6y ago
> WebView2 has to be installed separately Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?
hawk_ 6y ago
any idea when windows webview will switch over to Chromium?
lcnmrn 6y ago
An alternative to Electron should be built using Servo and Deno, both written in Rust.
- willwinger 6y ago
  I agree, however last time I checked Servo was not that stable.
  - lcnmrn 6y ago
    Yes, it doesn't yet render pages as good as other browsers, but we can tweak our code for it. 10x better performance and 100x less memory usage is a win.
veidr 6y ago
One approach that you can take to deal with this is to mentally back way the fuck off the 1990s on what your UI expectations are. Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages. There isn't any browser with even 0.1% share that can't render those things. You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4. There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are). But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.

brundolf 6y ago

> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked. I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.

908B64B197 6y ago
> Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!) More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
- brundolf 6y ago
  Chrome didn't even exist until 2008. Firefox existed and had a foothold, but it was very much a minority. IE was >50% until 2010 and remained the single most popular browser until 2012: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/media/File:BrowserUsageShare.png https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/m...
  - ahepp 6y ago
    what happened in 2018-07?
- mumblemumble 6y ago
  Some corporations did that. Most didn't. The main reason IE dominated was that most people didn't care, and stuck with the default. The main reason old versions of browsers were more common than new ones was that self-updating browsers hadn't become a thing yet, and most people didn't care, and just stuck with the default. The reason most browsers stay up-to-date now is that modern browsers are all configured to self-update by default, and most people don't care, and stick with the default. I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
  - brundolf 6y ago
    My experience was that IE finally got bad enough (around version 8), and Chrome got good enough, that even "grandmothers" started having everyone telling them to use Chrome, and it was so incredibly superior that you didn't have to be technical to appreciate it. Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
datalus 6y ago
Make no mistake, it's still a dumpster fire. Just maybe less raging.
- brundolf 6y ago
  I worked on a highly complex web app for ~3 years, and we made a point to support Firefox, so whenever somebody had a Firefox-specific bug we wouldn't tell them to just use Chrome, we'd fix it. We only had 2-3 Firefox-specific issues in that entire time. I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
  - mrec 6y ago
    Similar. Built a very complex app officially aimed at oldIE but made a point of ensuring it worked on other browsers too, largely on a skunkworks basis. A few years later (when we're no longer actively working on the app) everyone switched to Chrome and it Just Worked. Someone tried it on an iPad and it Just Worked (modulo some fat-finger challenges with small UI affordances). At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
danudey 6y ago
Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend. For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority. IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
- Klonoar 6y ago
  Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.
  - deleted 6y ago
    [deleted]
  - brundolf 6y ago
    It also launched 8 years ago; the web has changed a lot since then. Edge wasn't even around until 2015, much less being used for webviews.
    - Klonoar 6y ago
      This sounds like you didn't look up and read the comment in question. Problems with cross-platform webviews stopped being the HTML/CSS/JS layer long ago; it's integration, availability, and rate-of-updates that are common blockers. Call me when Microsoft actually ships WebView2 with the OS.
      - efwfwef 6y ago
        if you would link to that comment it would be helpful
jlokier 6y ago
I run three browsers on my desktop, because the number of things that don't work properly in anything except recent Chrome is enough that I keep encountering issues, I don't want to use Chrome for my regular browsing, and both Safari and Firefox have issues on some sites. On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill. My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things. I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS. This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken! Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory. I know, that feels wrong somehow, but it's true. Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
- encom 6y ago
  One major benefit of running webapps in an actual browser like Firefox, instead of Electron, is that I can have uBlock and a handful of other defensive plugins, to prevent shady things happening behind my back.
morpheuskafka 6y ago
That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.
- briandear 6y ago
  > Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps. I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one. What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
  - ZephyrBlu 6y ago
    > I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app The point is that its effectively a web app. > What value does electron add to the user? They have a desktop app faster than if it was being built natively.
    - simonh 6y ago
      Or at all, how many Electron apps would bother with native Linux clients for example. Some maybe but certainly not all and probably not most either.
oxymoron 6y ago
In 2008, when IE7 came out, I cried of joy. I turned 22 that year, so the 7 years with only IE6 and Firefox was a significant chunk of my life. Firefox showed us that the web wasn't finished and could still be improved, and then came Firebug which made Firefox first web dev the obvious choice. But the vast majority still used IE6, so there was always a miserable step in the project of fixing all the IE bugs. After doing it for years and knowing your foe, it was by then a relatively quick and manageable experience. The real pain was in knowing all the CSS2 features and other goodies that could never be used. Seeing Microsoft recognizing that, yes indeed, the web wasn't finished in 2001 was actually an emotional moment at that point. So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
- mattmanser 6y ago
  I've had to say this a fair few times here, but I'll keep saying it. IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember. So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
  - oxymoron 6y ago
    I was young and dogmatic, so I did admittedly despise Microsoft back then. I can't recall I ever heard of IEDevToolbar, though. Did it really feature the DOM tree view where you could do CSS manipulation? I always had the impression that it was a Firebug invention, but I could be wrong about that.
    - treve 6y ago
      The DOM inspector view in Firefox predates Firebug by years. My memory might be a bit shaky, but it may even have existed in Mozilla Web Browser? It really looked like a 'DOM tree/tree of Javascript classes' though, not really like the inspector we have today.
Tijdreiziger 6y ago
Anecdotally I wrote some JavaScript just today (I'm not a frontend dev but I write some simple stuff for fun sometimes). It seemed to me that every modern feature you'd care about is now widely supported. I used the JS fetch API and template strings and these things just work in modern browsers. I even encoded my web fonts in WOFF2 only, because it's so widely supported that I didn't see the point in bothering with WOFF1 too.
Xevi 6y ago
Tauri also uses MSHTML (Internet Explorer) on Windows. And there's no way I'm going back to developing for that.
- nicklarsennz 6y ago
  Isn't IE just using Chrome now? Or do you mean support for old IE?
  - nicoburns 6y ago
    Their browser is. But Windows' webview is still the IE11 engine.
  - Xevi 6y ago
    No, IE is still the same. But Edge has moved to Chromium.
smt1 6y ago
There is also servo, which may not be as complete as Chromium, but is definitely interesting architecture wise, especially with the number of virtual machines and compilers written in Rust these days.

deleted 6y ago

[deleted]

modeless 6y ago

I question how major that benefit is. I think strict Electron-only apps are not really that common. All the ones I use have a web version.

munificent 6y ago

> Webviews are also a moving target so you need a big testing matrix. Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it. At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.

deleted 6y ago
[deleted]
brundolf 6y ago
It's not hard to silently auto-update an Electron app's internals; I assume the same is true for Tauri
- timerol 6y ago
  The issue would occur if the auto-updater itself broke as a result of an OS upgrade
  - brundolf 6y ago
    Seeing as the auto-updater wouldn't have anything to do with the webview, I don't see how that's any more likely to happen in this case than it would be in Electron, or any other desktop application for that matter
snemvalts 6y ago
Need a docker for electron

908B64B197 6y ago

I have to post it here because it's on top: On Windows the new WebView is Chromium. https://developer.microsoft.com/en-us/microsoft-edge/webview2/ https://developer.microsoft.com/en-us/microsoft-edge/webview... Old one is, of course, kept for compatibility reasons.

the_duke 6y ago
Yes, but it is not installed by default. You have to install it separately, at least for now,which makes things a lot more complicated if you want your app to rely on it.
- encom 6y ago
  I'm moderately certain that Chromium is installed by default on new installs of Windows now.
  - Klonoar 6y ago
    WebView2 does not use that Chromium, however. It's slightly absurd, and you should direct the "WTF?" to Microsoft for this.
- oldmanhorton 6y ago
  Edge is pushed to the vast majority of PCs, and on those machines, I believe it provides a system-level webview2 component. You can choose to package your own webview2 into your app if you want the extra compatability that offers at expense of app size and ram usage

pjmlp 6y ago

A major benefit of Electron to Google is the amount of FOSS developers helping to turn what is left of the Web into ChromeOS.

runarberg 6y ago

> don't have to deal with all the small but time consuming compatibility quirks. Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser). An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.

hobofan 6y ago
This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers. On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
- danudey 6y ago
  Because then you'll get a more efficient app that people don't constantly complain about? Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
  - hobofan 6y ago
    Apart from the install size which is still not optimal, it is very much possible to write an efficient Electron app, as evidenced by Discord and Element. That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.
    - plorkyeran 6y ago
      Discord is efficient now? I have to restart it on a regular basis because it starts using 5+ GB of ram.

ASalazarMX 6y ago

> A major benefit of Electron is that you can develop against a single browser version and don't have to deal with all the small but time consuming compatibility quirks. Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.

brundolf 6y ago
Nearly every successful technology is a prototype that went out of control :) That doesn't mean we shouldn't try and improve on things given the opportunity, but it's not an indictment either
babypuncher 6y ago
I think they're overstating the browser compatibility problem too. It was really bad 15 years ago, but today it is almost a non-issue. Between significantly improved standardization of web technologies, and new tricks like polyfills, I think it has become pretty uncommon for apps to not just work on multiple browsers without any tinkering.
- jlokier 6y ago
  I use Chrome, Safari and Firefox on a Mac. In my experience, unfortunately it isn't true that apps work with very high reliability. This is why I use multiple browsers. I don't want to use Chrome, and I encounter new websites with functionality that don't work properly in Safari or Firefox quite regularly. Some of this is even quite basic functionality. From things like shopping carts where the final payment button doesn't work in Firefox (nothing happens), to video conferencing that sort-of works in Safari but then the audio breaks while it is reliable in Chrome. Even GitHub doesn't render properly in Safari occasionally (the page is full of weird size text and giant rectangles). But that's almost certainly a Safari bug.
  - babypuncher 6y ago
    I think this is more a problem with developers working in Chrome and using Blink-specific features. I stopped having compatibility issues with my apps when I moved to Firefox years ago.

albertzeyer 6y ago

But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max). Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save. The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.

OskarS 6y ago
Dynamically loaded system libraries use shared memory. You can load it once for the entire system.
- albertzeyer 6y ago
  That's what I mean by executable code. But that is only really minor (<100MB or so) compared to the remaining resource usage.
  - OskarS 6y ago
    Ah, sorry, I missed that in your comment.
sophiebits 6y ago
They’re not inherently more efficient (other than the reduced application size), but Safari and Edge are both more resource-efficient than Chrome.
deleted 6y ago
[deleted]
cozzyd 6y ago
100 MB / app is significant, especially on laptops. Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.

e_y_ 6y ago

I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated or otherwise problematic for your application? With the idea that you could eventually migrate to system webviews. That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you don't have that choice.

themihai 6y ago
>> I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.

nix0n 6y ago

> WebView2 has to be installed separately Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?

hawk_ 6y ago

any idea when windows webview will switch over to Chromium?

lcnmrn 6y ago

An alternative to Electron should be built using Servo and Deno, both written in Rust.

willwinger 6y ago
I agree, however last time I checked Servo was not that stable.
- lcnmrn 6y ago
  Yes, it doesn't yet render pages as good as other browsers, but we can tweak our code for it. 10x better performance and 100x less memory usage is a win.

veidr 6y ago

One approach that you can take to deal with this is to mentally back way the fuck off the 1990s on what your UI expectations are. Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages. There isn't any browser with even 0.1% share that can't render those things. You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4. There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are). But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.