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.
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.
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.
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)
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".
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).
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."
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.
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.
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?
I would recommend starting with the server-side variant of Blazor on a non-production test app to familiarize yourself. You can easily move to client-side WASM mode once you need to (or feel comfortable doing so) without any major changes to your codebase.
Our long term plans (aka by end of 2020) are to rewrite all of our internal tooling from SPA (RiotJS) w/ JSON APIs to server-side Blazor. The principal motivations here are productivity gains. It is a LOT faster to write a razor view in C# with direct invocation of your business logic from view logic, than it is to determine what a clean JSON API contract looks like, write all the boilerplate for controllers, and then play the back-and-forth game between chrome devtools and visual studio with 2 separate debugging contexts. After you write your first LINQ .Where().Select() to populate a table in Blazor, you will truly understand what I am getting at in terms of productivity if you have ever tried to do the same sort of filter->map stuff in JS.
With Blazor, I only need to know C#, HTML, CSS and just enough JS to write a blazorhelper.js interop which reads and writes my session cookies. I set 1 breakpoint in visual studio and it gets hit when I press some button in the browser.
With SPA, I have to be at the top of my JS game, and also pull some SPA framework into my mental context which must then be shared with all of the other C# business logic in scope. I have to manage breakpoints in the browser as well as in visual studio. I have to deal with 10-100x the amount of JS code.
Additionally, we don't even want to move to client-side variants of Blazor for our use case. First request latency and security are the 2 largest motivators for us here. Server-side exposes precisely zero things to the client you didn't want to, as opposed to SPA which makes even unauthenticated clients download your entire application. Also, "the server" is substantially faster these days (even more so going into 2020 on AMD's warpath). For the number of concurrent clients we are anticipating, server-side Blazor is actually our best option in terms of UX.
I would be curious what aspect of Blazor feels immature to you. It is certainly a new(ish) thing, but the fundamental aspects of it (especially server-side mode) have been around for decades and microsoft has leveraged a lot of existing or otherwise proven ideas here. I would agree on the client-side aspect being "immature" relative to server-side, mostly due to WASM and the need to push a very large payload to the client upon first request.
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.
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?
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.
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!
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.
[+] [-] throwGuardian|6 years ago|reply
1. Webview: https://github.com/zserge/webview
2. Lorca (Chrome): https://github.com/zserge/lorca
3. Carlo (js/Chrome): https://github.com/GoogleChromeLabs/carlo
[+] [-] branchseer|6 years ago|reply
[+] [-] erlend_sh|6 years ago|reply
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
[+] [-] xmichael999|6 years ago|reply
[+] [-] slowenough|6 years ago|reply
Please let this be it.
.NET is such a good runtime.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] m_fayer|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
[+] [-] yodon|6 years ago|reply
[+] [-] resoluteteeth|6 years ago|reply
[+] [-] FlorianRappl|6 years ago|reply
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|6 years ago|reply
[+] [-] snagglegaggle|6 years ago|reply
[+] [-] fbelzile|6 years ago|reply
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.
[+] [-] mappu|6 years ago|reply
EdgeHTML can be embedded, but only using the WinRT API, not the ActiveX WebBrowser control.
[+] [-] Lord_Zero|6 years ago|reply
[+] [-] wayneftw|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
Either go native or go Web, hybrid apps always always feel worse than middleware frameworks.
[+] [-] josteink|6 years ago|reply
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?
[+] [-] thdrdt|6 years ago|reply
[+] [-] bob1029|6 years ago|reply
Our long term plans (aka by end of 2020) are to rewrite all of our internal tooling from SPA (RiotJS) w/ JSON APIs to server-side Blazor. The principal motivations here are productivity gains. It is a LOT faster to write a razor view in C# with direct invocation of your business logic from view logic, than it is to determine what a clean JSON API contract looks like, write all the boilerplate for controllers, and then play the back-and-forth game between chrome devtools and visual studio with 2 separate debugging contexts. After you write your first LINQ .Where().Select() to populate a table in Blazor, you will truly understand what I am getting at in terms of productivity if you have ever tried to do the same sort of filter->map stuff in JS.
With Blazor, I only need to know C#, HTML, CSS and just enough JS to write a blazorhelper.js interop which reads and writes my session cookies. I set 1 breakpoint in visual studio and it gets hit when I press some button in the browser.
With SPA, I have to be at the top of my JS game, and also pull some SPA framework into my mental context which must then be shared with all of the other C# business logic in scope. I have to manage breakpoints in the browser as well as in visual studio. I have to deal with 10-100x the amount of JS code.
Additionally, we don't even want to move to client-side variants of Blazor for our use case. First request latency and security are the 2 largest motivators for us here. Server-side exposes precisely zero things to the client you didn't want to, as opposed to SPA which makes even unauthenticated clients download your entire application. Also, "the server" is substantially faster these days (even more so going into 2020 on AMD's warpath). For the number of concurrent clients we are anticipating, server-side Blazor is actually our best option in terms of UX.
I would be curious what aspect of Blazor feels immature to you. It is certainly a new(ish) thing, but the fundamental aspects of it (especially server-side mode) have been around for decades and microsoft has leveraged a lot of existing or otherwise proven ideas here. I would agree on the client-side aspect being "immature" relative to server-side, mostly due to WASM and the need to push a very large payload to the client upon first request.
[+] [-] justinmchase|6 years ago|reply
Very interesting experiment though.
[+] [-] ComputerGuru|6 years ago|reply
[+] [-] catchmeifyoucan|6 years ago|reply
[+] [-] eerikkivistik|6 years ago|reply
Edit: Also check out devicePixelRatio, that might be causing the issue as well.
[+] [-] brainfreezy|6 years ago|reply
[+] [-] gfodor|6 years ago|reply
[+] [-] 91edec|6 years ago|reply
[+] [-] tracker1|6 years ago|reply
https://github.com/GoogleChromeLabs/carlo
[+] [-] chabad360|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] lightdot|6 years ago|reply
[+] [-] ryanthedev|6 years ago|reply
I have been tinkering around with some enterprise solutions for delivering desktop native experience for web based apps.
[+] [-] xmichael999|6 years ago|reply
[+] [-] jcmontx|6 years ago|reply
[+] [-] The_rationalist|6 years ago|reply
[+] [-] yodon|6 years ago|reply
[+] [-] mscasts|6 years ago|reply