14 ms·

WebWindow, a cross-platform webview library for .NET Core

235 points by johns 7y ago

lightdot 7y ago
This looks interesting, I'm looking forward to trying it out.
mscasts 7y ago
Looks very cool!
wayneftw 7y ago
Fabulous! Standalone app sizes look to be less than half that of Electron. Wish I had more C++/Obj-C skills to help out...
yodon 7y ago
This looks amazing - can you please add a license file so others can actually use it? (Hoping for MIT or if not then Apache 2.0 or BSD or whatever reflects your intent and preferences)
- resoluteteeth 7y ago
  For anyone else who didn't see your github issue, it's apache 2 as of 3 hours ago.
jcmontx 7y ago
This is fantastic. Another step in the right direction!
throwGuardian 7y ago
Alternatives: 1. Webview: https://github.com/zserge/webview https://github.com/zserge/webview 2. Lorca (Chrome): https://github.com/zserge/lorca https://github.com/zserge/lorca 3. Carlo (js/Chrome): https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
- patr0nus 7y ago
  And my shameless plug: https://github.com/patr0nus/DeskGap https://github.com/patr0nus/DeskGap
  - Benjamin_Dobell 7y ago
    This is the first I've heard of it. So I can't say much about the project itself. However, by the look of it DeskGap is at least taking the right approach, where as most these other projects (there seems to be a new one every week) miss the mark. Electron Pros: 1. Consistent JS runtime/API Electron Cons: 2. Huge distributions (bundling a full browser) 3. No re-use of components (every app is huge) Electron Pro?/Con?: 4. Consistent rendering / WebKit monoculture By the look of it DeskGap keeps Electron's biggest pro and solves its two biggest cons. The only "issue" is that there may be rendering inconsistencies. However, given we want to avoid a WebKit monoculture, I see this as a pro more-so than a con. With that being said Microsoft have themselves migrated to WebKit; so the WebKit monoculture looks likely regardless. For consistency I guess that's even another tick in DeskGap's corner, although it'd be nice if on Linux (for example) it could use Firefox when present. Carlo is interesting for a similar reason, but perpetuates the WebKit monoculture.
- xmichael999 7y ago
  none of these support .net natively
- erlend_sh 7y ago
  zserge’s webview has been adopted by a bunch of maintainers who made Rust bindings for it. They have forked webview to continue maintaining it, and are now gradually rewriting it in Rust. https://github.com/Boscop/web-view https://github.com/Boscop/web-view Made on top of that is Tauri, a cross-platform webview-based app just like WebWindow. The key differentiator being that they are actually committed to continuous development as they’re trying to get established as an open source company. https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri
thdrdt 7y ago
Has anyone experience with Blazor in production? I would like to jump into it but it still feels a little immature to me.
- justinmchase 7y ago
  No but I agree, it seems a little risky. I would wait for the next generation of web assembly changes to come down the pipe before investing in this too heavily. Very interesting experiment though.
  - sbaldwin621 7y ago
    The blog specifically states "this does not involve WebAssembly", so it seems like this uses Blazor Server and not Blazor WebAssembly, meaning that it doesn't run any .NET code in the browser space at all. While this is also very new, it's an officially supported part of ASP.NET Core 3.0. I'd probably not use Blazor Server in a web app just yet since it requires an active connection to the web server, but this is all local so I'm pretty interested in trying it out. Of course this is still an experiment so it's very risky to use it, but it's cool and shows promise. Edit: Looks like maybe this thread is talking about using Blazor at all instead of within the context of the post, but I what I said still applies so I'll leave it up.
  - ryanthedev 7y ago
    There is no reason it couldn't run a wasm file? As long as the OS browser supports it. I feel like this is the UI abstraction layer. If you want to run chromium, there is no reason you couldn't extend it. Code is prime for extending and enhancing.
- ComputerGuru 7y ago
  It does not require Blazor. As the article says, you can use anything you want and the demo has vue.js
  - thdrdt 7y ago
    Currently I'm also using VueJs, but there are benefits of having one language for both the front and backend. With Blazor you can also share your models and other code if needed.
gfodor 7y ago
this is really interesting! i'm wondering if there's a variant of this project out there that still uses node/javascript, but similarly avoids the chromium packaging and leans on the OS's rendering engine.
- 91edec 7y ago
  There was Electrino a couple of years ago but it looks dead. https://github.com/pojala/electrino https://github.com/pojala/electrino
- chabad360 7y ago
  it seems that this could support node, just not directly like electron (i.e. you'd have to start a separate node server and point webwindow to that).
- tracker1 7y ago
  Also mentioned in another thread: https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
deleted 7y ago
[deleted]
FlorianRappl 7y ago
I'm potentially the only one being skeptical. Don't get me wrong, it's nicely done (for an experiment), but we also did similar experiments several years ago. At the fundamental level such an approach works, but it brings several issues that are not addressed with it (in contrast to, e.g., Electron). The most pressing one being "I don't want any browser - I want a browser that I know is capable of doing what I want".
- saurik 7y ago
  So most of these techniques used to have the problem that on Windows "any browser" was always "Internet Explorer"; but while I don't disagree that this is still an issue, it is much much much less of an issue now that Internet Explorer is Edge and Edge is Chromium (which I am not saying is a good state of affairs for the web as a whole, but makes this use case not fall as easily to this complaint).
  - zamadatix 7y ago
    But I don't think Edgium is replacing Edge/IE as the system web component. It's no different than having Chrome installed except it replaced the Edge icon in the start menu instead of making a new one.
    - chrismorgan 7y ago
      In each case, the new thing is added with a new interface, and the old remains. In this case, the new thing is https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2 https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv....
- snagglegaggle 7y ago
  I'm skeptical for a similar reason. This isn't really "crossplatform" it is "capable of running on a very small list of platforms which bundle a web browsing component."
fbelzile 7y ago
This looks like a nice solution to save some time for cross-platform developers on .NET Core. I'm sure we're going to see a lot more of this once the new Chromium version of Edge is released mid Jan 2020 (which will include the new webview2 component). If you don't want to add an external library to do this, or your source is already platform dependent, just use the default web view component of each operating system (WebBrowser for Windows, WKWebView for macOS and WebKitGTK+2 for Linux) like this library does. To work around some of the ugliness of the old IE rendering engine used in the current WebBrowser control on Windows, just add this meta tag to the HTML file to ensure it uses the new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge"> You can disable most non-native app behavior in JS (like scrolling or the default right click context menu using javascript). You're then free to use whatever front end framework you want and pass data between the web-app and native code using JSON.
- Lord_Zero 7y ago
  Yes this is still a very alpha package, fallback support for non chromium-based edge has not yet been implemented.
- mappu 7y ago
  I think setting x-ua-compatible ie=edge doesn't mean use the Edge EdgeHTML engine - it means enabling "Edge mode" in IE, which means "the latest available version of IE" and you end up with IE10 or IE11. EdgeHTML can be embedded, but only using the WinRT API, not the ActiveX WebBrowser control.
  - chrismorgan 7y ago
    Welcome to the web, where browsers are named after existing browser concepts in as confusing a way as they can come up with. “You know how browsers have chrome around the web content, and how that’s the accepted term of art? Let’s call our browser Chrome!” “You know how we can tell IE to run in edge mode? Let’s call our replacement browser, which IE compatibility mode won’t be able to use, Edge!”
The_rationalist 7y ago
This is mostly obscoleted by https://github.com/sentialx/electron-global https://github.com/sentialx/electron-global
- yodon 7y ago
  Both projects can be of interest without one obsoleting the other.
slowenough 7y ago
This is very exciting, thanks for creating this! I've been hoping for a way to build native apps via web technologies without the bloat. Please let this be it. .NET is such a good runtime.
- pjmlp 7y ago
  Web is only native on browser OSes.
  - Phillips126 7y ago
    Which on Windows is basically IE11 (not an environment I really want to develop in).
    - pjmlp 7y ago
      Which isn't what I said, rather OSes that jungle browsers as the only userspace processes available, e.g. FireOS, ChromeOS, KaiOS .... As for IE11, I don't know of any Window 10 user that still uses it instead of Edge.
      - Phillips126 7y ago
        Apologies, I meant to state that Windows WebView uses MSHTML which is IE10/11. I see in BETA right now is a Win32 API for WebView2 which uses Edge(Chromium)[0]. Not sure if you edited your comment for clarification or if I replied to the wrong post as my initial comment no longer makes sense. [0] https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2 https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...
- m_fayer 7y ago
  We're doing it. It's (misleadingly) called server side Blazor. The UI is seamlessly and naturally web, while 95% of the logic is plain old C# running on the plain old core CLR.
- deleted 7y ago
  [deleted]
catchmeifyoucan 7y ago
My biggest problem is that WKWebview on Mac just seems so slow compared to Chrome. I have a canvas in my application and it just doesn't seem to render as efficiently as it should or with ease as it does in Chrome. Does anyone experience similar issues?
- eerikkivistik 7y ago
  It might have to do with the retina settings that rescale after rendering. I had this issue when we were testing 3DC.io on some Macbooks. Play around with the scale and css a bit, there is some information on Stack Overflow if you search for canvas+retina. Edit: Also check out devicePixelRatio, that might be causing the issue as well.
  - catchmeifyoucan 7y ago
    Ohh! That actually was it. My canvas was a very large size - like 1900x1200 and Safari drastically slowed down - I readjusted for it to only take page height and width and it works nicely again. Thanks!!
    - eerikkivistik 7y ago
      No problem. I think of it as collectively saving the mankind another 10 hours of debugging.
- brainfreezy 7y ago
  I've never experienced this. It sounds like you are hitting a bug, but more investigation would be needed to substantiate whether there is a real difference. Have you tried to make a test case? Please file a bug at feedbackassistant.apple.com with repro steps!
xmichael999 7y ago
Very cool, I am hoping the project is in fact supported and maintained!
ryanthedev 7y ago
Beautiful MVP. I really love this idea. I have been tinkering around with some enterprise solutions for delivering desktop native experience for web based apps.
pjmlp 7y ago
Nice work, although WebViews shouldn't be used for anything beyond displaying HTML documents. Either go native or go Web, hybrid apps always always feel worse than middleware frameworks.
josteink 7y ago
While this definitely sounds like a good alternative to everything bundling its own Electron, I do have some questions. To make sure I understand how viable this solution is... > On Windows, WebWindow uses the new Chromium-based Edge via webview2, assuming you have that browser installed (it could fall back on older Edge if you don’t, but I haven’t implemented that) So this will currently only work for those running the absolutely newest version of Windows 10? (But if the user does, you get a reasonably up to date and capable web-engine, which sounds good) > On Mac, it uses the OS’s built-in WKWebView, which is the same technology behind Safari Sounds decent, I guess? > On Linux, it uses WebKitGTK+2, which is yet again a WebKit-based technology Isn't WebKitGTK horribly outdated, or have things improved recently? Couldn't that be a source of issues down the road?

235 points by johns 7y ago

lightdot 7y ago

This looks interesting, I'm looking forward to trying it out.

mscasts 7y ago

Looks very cool!

wayneftw 7y ago

Fabulous! Standalone app sizes look to be less than half that of Electron. Wish I had more C++/Obj-C skills to help out...

yodon 7y ago

This looks amazing - can you please add a license file so others can actually use it? (Hoping for MIT or if not then Apache 2.0 or BSD or whatever reflects your intent and preferences)

resoluteteeth 7y ago
For anyone else who didn't see your github issue, it's apache 2 as of 3 hours ago.

jcmontx 7y ago

This is fantastic. Another step in the right direction!

throwGuardian 7y ago

Alternatives: 1. Webview: https://github.com/zserge/webview https://github.com/zserge/webview 2. Lorca (Chrome): https://github.com/zserge/lorca https://github.com/zserge/lorca 3. Carlo (js/Chrome): https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo

patr0nus 7y ago
And my shameless plug: https://github.com/patr0nus/DeskGap https://github.com/patr0nus/DeskGap
- Benjamin_Dobell 7y ago
  This is the first I've heard of it. So I can't say much about the project itself. However, by the look of it DeskGap is at least taking the right approach, where as most these other projects (there seems to be a new one every week) miss the mark. Electron Pros: 1. Consistent JS runtime/API Electron Cons: 2. Huge distributions (bundling a full browser) 3. No re-use of components (every app is huge) Electron Pro?/Con?: 4. Consistent rendering / WebKit monoculture By the look of it DeskGap keeps Electron's biggest pro and solves its two biggest cons. The only "issue" is that there may be rendering inconsistencies. However, given we want to avoid a WebKit monoculture, I see this as a pro more-so than a con. With that being said Microsoft have themselves migrated to WebKit; so the WebKit monoculture looks likely regardless. For consistency I guess that's even another tick in DeskGap's corner, although it'd be nice if on Linux (for example) it could use Firefox when present. Carlo is interesting for a similar reason, but perpetuates the WebKit monoculture.
xmichael999 7y ago
none of these support .net natively
erlend_sh 7y ago
zserge’s webview has been adopted by a bunch of maintainers who made Rust bindings for it. They have forked webview to continue maintaining it, and are now gradually rewriting it in Rust. https://github.com/Boscop/web-view https://github.com/Boscop/web-view Made on top of that is Tauri, a cross-platform webview-based app just like WebWindow. The key differentiator being that they are actually committed to continuous development as they’re trying to get established as an open source company. https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri

thdrdt 7y ago

Has anyone experience with Blazor in production? I would like to jump into it but it still feels a little immature to me.

justinmchase 7y ago
No but I agree, it seems a little risky. I would wait for the next generation of web assembly changes to come down the pipe before investing in this too heavily. Very interesting experiment though.
- sbaldwin621 7y ago
  The blog specifically states "this does not involve WebAssembly", so it seems like this uses Blazor Server and not Blazor WebAssembly, meaning that it doesn't run any .NET code in the browser space at all. While this is also very new, it's an officially supported part of ASP.NET Core 3.0. I'd probably not use Blazor Server in a web app just yet since it requires an active connection to the web server, but this is all local so I'm pretty interested in trying it out. Of course this is still an experiment so it's very risky to use it, but it's cool and shows promise. Edit: Looks like maybe this thread is talking about using Blazor at all instead of within the context of the post, but I what I said still applies so I'll leave it up.
- ryanthedev 7y ago
  There is no reason it couldn't run a wasm file? As long as the OS browser supports it. I feel like this is the UI abstraction layer. If you want to run chromium, there is no reason you couldn't extend it. Code is prime for extending and enhancing.
ComputerGuru 7y ago
It does not require Blazor. As the article says, you can use anything you want and the demo has vue.js
- thdrdt 7y ago
  Currently I'm also using VueJs, but there are benefits of having one language for both the front and backend. With Blazor you can also share your models and other code if needed.

gfodor 7y ago

this is really interesting! i'm wondering if there's a variant of this project out there that still uses node/javascript, but similarly avoids the chromium packaging and leans on the OS's rendering engine.

91edec 7y ago
There was Electrino a couple of years ago but it looks dead. https://github.com/pojala/electrino https://github.com/pojala/electrino
chabad360 7y ago
it seems that this could support node, just not directly like electron (i.e. you'd have to start a separate node server and point webwindow to that).
tracker1 7y ago
Also mentioned in another thread: https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo

deleted 7y ago

[deleted]

FlorianRappl 7y ago

I'm potentially the only one being skeptical. Don't get me wrong, it's nicely done (for an experiment), but we also did similar experiments several years ago. At the fundamental level such an approach works, but it brings several issues that are not addressed with it (in contrast to, e.g., Electron). The most pressing one being "I don't want any browser - I want a browser that I know is capable of doing what I want".

saurik 7y ago
So most of these techniques used to have the problem that on Windows "any browser" was always "Internet Explorer"; but while I don't disagree that this is still an issue, it is much much much less of an issue now that Internet Explorer is Edge and Edge is Chromium (which I am not saying is a good state of affairs for the web as a whole, but makes this use case not fall as easily to this complaint).
- zamadatix 7y ago
  But I don't think Edgium is replacing Edge/IE as the system web component. It's no different than having Chrome installed except it replaced the Edge icon in the start menu instead of making a new one.
  - chrismorgan 7y ago
    In each case, the new thing is added with a new interface, and the old remains. In this case, the new thing is https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2 https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv....
snagglegaggle 7y ago
I'm skeptical for a similar reason. This isn't really "crossplatform" it is "capable of running on a very small list of platforms which bundle a web browsing component."

fbelzile 7y ago

This looks like a nice solution to save some time for cross-platform developers on .NET Core. I'm sure we're going to see a lot more of this once the new Chromium version of Edge is released mid Jan 2020 (which will include the new webview2 component). If you don't want to add an external library to do this, or your source is already platform dependent, just use the default web view component of each operating system (WebBrowser for Windows, WKWebView for macOS and WebKitGTK+2 for Linux) like this library does. To work around some of the ugliness of the old IE rendering engine used in the current WebBrowser control on Windows, just add this meta tag to the HTML file to ensure it uses the new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge"> You can disable most non-native app behavior in JS (like scrolling or the default right click context menu using javascript). You're then free to use whatever front end framework you want and pass data between the web-app and native code using JSON.

Lord_Zero 7y ago
Yes this is still a very alpha package, fallback support for non chromium-based edge has not yet been implemented.
mappu 7y ago
I think setting x-ua-compatible ie=edge doesn't mean use the Edge EdgeHTML engine - it means enabling "Edge mode" in IE, which means "the latest available version of IE" and you end up with IE10 or IE11. EdgeHTML can be embedded, but only using the WinRT API, not the ActiveX WebBrowser control.
- chrismorgan 7y ago
  Welcome to the web, where browsers are named after existing browser concepts in as confusing a way as they can come up with. “You know how browsers have chrome around the web content, and how that’s the accepted term of art? Let’s call our browser Chrome!” “You know how we can tell IE to run in edge mode? Let’s call our replacement browser, which IE compatibility mode won’t be able to use, Edge!”

The_rationalist 7y ago

This is mostly obscoleted by https://github.com/sentialx/electron-global https://github.com/sentialx/electron-global

yodon 7y ago
Both projects can be of interest without one obsoleting the other.

slowenough 7y ago

This is very exciting, thanks for creating this! I've been hoping for a way to build native apps via web technologies without the bloat. Please let this be it. .NET is such a good runtime.

pjmlp 7y ago
Web is only native on browser OSes.
- Phillips126 7y ago
  Which on Windows is basically IE11 (not an environment I really want to develop in).
  - pjmlp 7y ago
    Which isn't what I said, rather OSes that jungle browsers as the only userspace processes available, e.g. FireOS, ChromeOS, KaiOS .... As for IE11, I don't know of any Window 10 user that still uses it instead of Edge.
    - Phillips126 7y ago
      Apologies, I meant to state that Windows WebView uses MSHTML which is IE10/11. I see in BETA right now is a Win32 API for WebView2 which uses Edge(Chromium)[0]. Not sure if you edited your comment for clarification or if I replied to the wrong post as my initial comment no longer makes sense. [0] https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2 https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...
m_fayer 7y ago
We're doing it. It's (misleadingly) called server side Blazor. The UI is seamlessly and naturally web, while 95% of the logic is plain old C# running on the plain old core CLR.
deleted 7y ago
[deleted]

catchmeifyoucan 7y ago

My biggest problem is that WKWebview on Mac just seems so slow compared to Chrome. I have a canvas in my application and it just doesn't seem to render as efficiently as it should or with ease as it does in Chrome. Does anyone experience similar issues?

eerikkivistik 7y ago
It might have to do with the retina settings that rescale after rendering. I had this issue when we were testing 3DC.io on some Macbooks. Play around with the scale and css a bit, there is some information on Stack Overflow if you search for canvas+retina. Edit: Also check out devicePixelRatio, that might be causing the issue as well.
- catchmeifyoucan 7y ago
  Ohh! That actually was it. My canvas was a very large size - like 1900x1200 and Safari drastically slowed down - I readjusted for it to only take page height and width and it works nicely again. Thanks!!
  - eerikkivistik 7y ago
    No problem. I think of it as collectively saving the mankind another 10 hours of debugging.
brainfreezy 7y ago
I've never experienced this. It sounds like you are hitting a bug, but more investigation would be needed to substantiate whether there is a real difference. Have you tried to make a test case? Please file a bug at feedbackassistant.apple.com with repro steps!

xmichael999 7y ago

Very cool, I am hoping the project is in fact supported and maintained!

ryanthedev 7y ago

Beautiful MVP. I really love this idea. I have been tinkering around with some enterprise solutions for delivering desktop native experience for web based apps.

pjmlp 7y ago

Nice work, although WebViews shouldn't be used for anything beyond displaying HTML documents. Either go native or go Web, hybrid apps always always feel worse than middleware frameworks.

josteink 7y ago

While this definitely sounds like a good alternative to everything bundling its own Electron, I do have some questions. To make sure I understand how viable this solution is... > On Windows, WebWindow uses the new Chromium-based Edge via webview2, assuming you have that browser installed (it could fall back on older Edge if you don’t, but I haven’t implemented that) So this will currently only work for those running the absolutely newest version of Windows 10? (But if the user does, you get a reasonably up to date and capable web-engine, which sounds good) > On Mac, it uses the OS’s built-in WKWebView, which is the same technology behind Safari Sounds decent, I guess? > On Linux, it uses WebKitGTK+2, which is yet again a WebKit-based technology Isn't WebKitGTK horribly outdated, or have things improved recently? Couldn't that be a source of issues down the road?