3 ms·

The downside with using native web views was that if you wanted a cross platform application, you had to use IE11 web views on Windows. So that limitation alon

The downside with using native web views was that if you wanted a cross platform application, you had to use IE11 web views on Windows. So that limitation alone prevented many developers ever going down that route. The solution to that was Electron and bundling a modern web browser with the application. However... The latest versions of Windows 10 now use the newest Chromium based Edge as the native web view. So the need to use Electron is slowly going away.

devwastaken 6y ago
Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. You can't patch webviews nor change their behavior. Also windows webview2 is very alpha and currently not useful. No v8 access, very little configurability, and its not using any less memory. It will be years before it's ready. Chromium itself should have impliments webviews long ago.
- saagarjha 6y ago
  > Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. This doesn’t logically follow?
rollcat 6y ago
- So which one is the "native" web view on Linux / BSD? Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. - How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. - So at the time Electron was founded, it might have made more sense to ship Webkit on Windows. But the developers instead chose to plug in all the extras from Chrome (?). Might have been a better choice to build directly on raw Webkit. - Even if a Hello World app was 200mb shipped and took 500mb of ram to run, it's still on the developers to get it to a state where it's an order of magnitude worse once it gets to do something useful... I'm still torn on the issue. I firmly believe going full native is the most user-friendly option, but I appreciate the increased cost and complexity of development, testing, support. But using an embedded web view of any kind feels incredibly, incredibly cheap. Especially for companies with the scale and budgets of Github or Slack.
- saagarjha 6y ago
  > Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. The one on my system updates pretty frequently, probably more often than WebKit updates on my Mac. > How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. They’re already doing this for the website.
  - rollcat 6y ago
    > The one on my system updates pretty frequently, probably more often than WebKit updates on my Mac. Maybe. Your Linux distro of choice is a single data point in a sea of headaches. https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secu... > They’re already doing this for the website. Yes, but the effort testing the app on browser A, on platform X, doesn't directly benefit the testing of the desktop app on platform X. From QA standpoint they are separate entities, and while there will be shared bugs, there will also be unique bugs, which cascades back to development, design, perhaps even business decisions. But with separate browser engines for the desktop app on platforms X, Y, Z you will now have more variance in bugs between these platforms. Whether there's standalone web browsers involved as well is not as huge of a factor - they will have their own share of unique bugs.

devwastaken 6y ago

Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. You can't patch webviews nor change their behavior. Also windows webview2 is very alpha and currently not useful. No v8 access, very little configurability, and its not using any less memory. It will be years before it's ready. Chromium itself should have impliments webviews long ago.

saagarjha 6y ago
> Webviews are less efficient than electron because electron integrates node and the v8 engine together, along with a number of specific patches and improvements meant for singular desktop use. This doesn’t logically follow?

rollcat 6y ago

- So which one is the "native" web view on Linux / BSD? Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. - How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. - So at the time Electron was founded, it might have made more sense to ship Webkit on Windows. But the developers instead chose to plug in all the extras from Chrome (?). Might have been a better choice to build directly on raw Webkit. - Even if a Hello World app was 200mb shipped and took 500mb of ram to run, it's still on the developers to get it to a state where it's an order of magnitude worse once it gets to do something useful... I'm still torn on the issue. I firmly believe going full native is the most user-friendly option, but I appreciate the increased cost and complexity of development, testing, support. But using an embedded web view of any kind feels incredibly, incredibly cheap. Especially for companies with the scale and budgets of Github or Slack.

saagarjha 6y ago
> Use whatever version of Webkit is supplied by the distro? This is a security nightmare, as these are outdated and full of bugs more often than not. The one on my system updates pretty frequently, probably more often than WebKit updates on my Mac. > How does using 2 or 3 different rendering engines solve the problem for the developer? They have to now put in the extra effort and QA for each engine/platform. They’re already doing this for the website.
- rollcat 6y ago
  > The one on my system updates pretty frequently, probably more often than WebKit updates on my Mac. Maybe. Your Linux distro of choice is a single data point in a sea of headaches. https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secu... > They’re already doing this for the website. Yes, but the effort testing the app on browser A, on platform X, doesn't directly benefit the testing of the desktop app on platform X. From QA standpoint they are separate entities, and while there will be shared bugs, there will also be unique bugs, which cascades back to development, design, perhaps even business decisions. But with separate browser engines for the desktop app on platforms X, Y, Z you will now have more variance in bugs between these platforms. Whether there's standalone web browsers involved as well is not as huge of a factor - they will have their own share of unique bugs.