Is webview useful to use as an application UI?

Question

Context

I saw a Steve Sanderson’s article about an experimental project called Webwindow that uses a Webview component available on the operating system to use as the UI of an application.

This is all about the Blazor that allows you to use your model in different ways. I think I understand the advantages and disadvantages of each way to use:

_{Click on it to see better}

1	Servidor impõe penalidade. O WebAssembly é sempre inferior ao nativo para sua aplicação, mas o que mais importa é a UI			
2	Só por causa da UI. O ideal seria ter parâmetros mais precisos			
3	Carga inicial do *runtime*. Fora a aplicação em si. Dados bem aproximados. Server: fica maior que 0 se usar Angular, React, etc.			
4	Aqui é sobre a carga para uso e não o primeiro uso que depende de baixar algo. Server: as trocas de página são lentas. Tem tecnologia que não é tão baixo assim e pode ser maior que web em alguns casos			
5	Se precisa de alguma ação do usuário entre ele chegar onde tem a aplicação e começar usar (não é sobre precisar de um instalador)			
6	Se você decide quando o renderizador final (gráfico) muda a versão e possivelmente cria falhas na aplicação. O SO pode mudar algo, mas é raro quebrar compatibilidade, web não é assim, ainda que melhorou			
7	Problemas diferentes em cada um, pode faltar componente ou não ser na versão desejada e executar algum um pouco diferente do esperado, até falhar, em alguns casos por ação indevida do usuário			
8	Como se parece e interage? Fica como é a plataforma base que está rodando? Web já é meio padronizado, próprio não. Nativo é bom pra plataforma, mas não ajuda quem usa mais de uma			
9	Usa de forma simples e sem sobressaltos? Faz tudo o que deve fazer sem perceber nada esquisito, demoras, ou gerar algum mínimo desconforto comparando com outras opções (por exemplo poder cometer erros porque tem controle sobre o que não é bem sua aplicação, ex.: navegação do browser)			
10	Minha percepção da satisfação do usuário usando (não confio na opinião dele, ele se engana quando comenta sobre, é quase subliminar)			
11	O usuário tem que tomar algum cuidado? Ele pode causar problema na hora de começar usar ou depois fazer algo errado, precisa de esforço adicional para atualizar, por parte do usuário ou do programador? Tem facilidade de manter tudo protegido (um só arquivo)?			
12	Por busca ou canal próprio de divulgação sempre dá por padrão. Estou desconsiderando que a Play Store não serve pra divulgar nada e fora a App Store as outras quase não são usadas			
13	A UI roda no Windows, Android, iOS, Linux, MacOS sem grandes alterações?			
14	Dá muito trabalho para fazer o código se comportar bem em todas plataformas que ele roda? Nativo: Considerando que cada plataforma tem uma base de código e uma não atrapalha a outra			
15	Se usa HTML/CSS ou outra forma (XAML, código, etc.)			
16	Se tem acesso nativo ao OS roda direto na API do SO ou tem alguma camada entre ela			
17	Aqui vai além da UI, dá para acessar qualquer recurso da máquina? Fazer cache? Comunicar por protocolo mais eficiente que HTTP?			
18	É fácil modelar e estilizar a UI? Ou seja, tem que mexer com CSS? :) Ou como dizem "responsivo" argh. Lida bem com mudança de orientação (Isso vale mais pra mobile, mas em certa medida desktop também porque não é só sobre orientação, se ele se vira sozinho quando "o formato da tela" muda)			
19	Dentro do normal que se faz precisa atualizar a aplicação quando muda a composição da UI ou é possível trocar sem mexer na aplicação. Pode contornar dificuldades de atualização com Store. Claro que é possível dar dinamismo em qualquer caso, mas alguns não é comum e depende de esforço extra			
20	Depende de conexão de internet para funcionar? Desde que faça algum sentido a aplicação rodar isolada			
21	Para aplicação não costuma importar, mas não deixa de ser um critério a ser pesado se for necessário			
22	Como é estruturado e manipulado o DOM ou algo semelhante que controla o layout			
23	Isso tem a ver principalmente com tempo, mas também pode envolver outras variáveis como custo do profissional ou infra necessária			
24	Se é fácil mexer depois de pronto? Tem muito caso que depois vira um drama arrumar mesmo que seja "fácil" fazer. Se tem que arrumar coisas por culpa do modelo adotado na tecnologia escolhida			
25	Cada modelo impõe uma forma de debugar o código e tem melhores ou piores ferramentas			
26	Minha percepção do que a comunidade usa e sustenta, principalmente mantendo a tecnologia fresca. Não é só documentação, qualquer coisa que ajude o desenvolvimento			
27	Minha percepção da quantidade e qualidade dos profissionais trabalhando com isso (não estou olhando proporção)			
28				
			
Server: SSR, a renderização do layout é no servidor e o gráfico visível é no cliente			
Browser: WebAssembly com .NET			
PWA: O mesmo com alguns detalhes extras para habilitar esta tecnologia			
Desktop: Electron			
Webview: Novo WebWindow (link do Sanderson)			
Nativo: Blazor experimental que abstrai a UI nativa do OS (provavelmente)			
OS Nativo: WinForms, WPF, WinUI, GTK, Xamarin, etc.			
Abstração do nativo: Eto Forms, Xamarin Forms, Uno, etc.			
Renderização própria: Avalonia...			
			
O que tem "talvez" é que depende de algum esforço próprio ou dependência.

"varia" depende de onde está rodando. Alguns casos talvez fosse melhor separar por tecnologia ou modelo específico, mas ficaria uma tabela muito grande e o foco é Blazor.

O "?" é que não se tem informação suficiente.
			
Não tome a tabela como correta.
			
Só considere a UI e a capacidade de ir além, mas não como vai além, especialmente em pontos como performance (não importa o resto do processamento.
			
Não considerei o fato de algumas formas destas não estarem prontas e até podem não se tornar produtos viáveis, minha visão é para longo prazo. Considerei tecnologias base disponíveis para o sistema operacional para uso com C#.
			
Note que usar C# (quando o Blazor pronto) no lugar de JS é teme muito mais performance, mas não sei bem o quanto. Poderia ter comparado com outras tecnologias, mas meu foco é este.
			
Não estou considerando o uso para aplicações muito complexas e de alta necessidade, só para uso mais normal de aplicativos comuns.

Sorry for the abuse of snippet, but I thought it best this way.

For those who do not know Blazor is just the programming model and he does not take care of the final rendering. It can structure how the screens will be mounted but does not do this job which is always done by the same component as the browser or operating system component.

The question

My question is regarding the Webview that has been around for some time (it’s not about Blazor, just about the decision to use it in it), I’ve seen criticism and praise, and from everything I’ve read it seems to be one of those technologies that people love or hate.

It seems that this technique is proliferating (it is no longer a use only in mobile and mainly it seems that it is no longer punctual).

I even saw in android documentation, who seems to have popularized the technique, saying that it is not so recommended:

In Most cases, we recommend using a standard web browser, like Chrome, to Deliver content to the user

Not only that, I have seen many debates on the subject, but some admit that in the past it was worse and improved.

I’m not talking about using Webview for something punctual when it would be difficult or impossible to do differently, I’m talking about using as the main and even unique UI of your application. I also don’t talk about the general issue that I think I’ve helped with the table above. So the question is for those who have experience using Webview in this way and can say something grounded in this experience about the specific use.

Webview itself has a problem being used as an application UI?

And yet, sees some problem in the approach that the article linked above shows that will be used?

It’s not fundamental to the question but is there any point about table Webview that deserves a better specification within the context of the question? For example about performance, it may be true, but it’s a significant difference?

Is there anything in the table regarding Webview that isn’t true, even if it was one day? (only if it helps the context of the question).

A balanced response without tending to one side, if possible, has more value. In general technologies do not have only advantages or only disadvantages.

Disclaimer: I think it is wrong to use web as UI of anything that is not casual or punctual, I just want to understand better, even to soften my position, if applicable.

Answer 1

I’m going to focus on two things, because it seems to me that the whole problem is about this:

• How are the webViews in general
• Webwindow and platforms and where "it is"

---

How are the webViews in general

I had experience with Webkit2, with Macos (Cocoa), with Webkitgtk, with Chromium and even with a certain "deceased" Java package that allowed you to have a "Mozilla browser" in your application (this I will not talk about, because this does not even fit here and I really believe that nobody else uses it for a long time) and let you know that I’ve all had some sort of problem, not with rendering (in some cases yes), but also not so serious as to say that they wouldn’t be interesting to use.

The point that the Webkit (GTK also) and Chromium arrived I must say that to generate visual things in general I had no problems, but I admit a thing or two, that were minimal I had some problems, but I believe that all these were Bugs that have passed, other problems were incredibly misuse of HTML+css by certain people who worked (when they shouldn’t) and failed in Webkit (and macOS generally), at the time it was easier to accuse the operating system than to admit that something was on the thighs next to the dev responsible for a "page X".

I want to say that this "idea" is not something so original, of course I am "looking over the top" and I may be confusing something, but the concept itself seems that it is not something new, an example javafx.scene.web.WebView, of course I’m only quoting as an example.

What it seems that Webwindow will require a certain operating system support, ie only operating systems very current will have support on the application and just as the IE had support is likely to be similar to this that the Edge-Chromium in Windows10 (in the repository I saw no reasonable detail on this, I believe it depends on this yet https://www.microsoftedgeinsider.com/en-us/) will be something like the Web View (Macos 10.3 to 10.14, obsolete) and WKWebView (Macos 10.10+) and most popular Linux will probably install the WebkitGTK and of course this will have to exist in the repositories of the chosen distro.

Possible "problems" in the article "Steve Sanderson"

I’m not claiming that there are problems in the article, it addresses what is needed, but it even states a possible problem:

Caution: This library is super-pre-alpha quality. If you’re thinking of building Something real with this, see the Notes at the end of this post. So far, this is just Another prototype.

There was a "super-pre-alpha" exaggeration to justify the quality and I must say that the experiments on this are still "obscure", of course I admit that the repository has reached more than 800 stars in 33 days of existence on Github (I understand that the version already existed 0.0.1 before, but it’s a bit obscure) is a good sign for tests and notes Bugs and although the author has made clear:

Currently I’m not making any Promises! It’s best to think of it as yet Another experiment for now. It’s possible that if enough other people want to get involved, it would be possible to create a Proper open-source community project.

This is just an experiment and I even think that community support can help, but a lot of things come and go, but I think it’s too early to be sure how far this can go, of course "relative advantage" of being able to "carry" (in parts) among other "hybrids".

Problems beyond the UI

The biggest problem I see in webViews is not even the rendering, because I imagine that most of the concern of these new Apis and frameworks or methodologies is always to meet the newer systems and people will use these "new" things thinking that they will perform miracles and come up against barriers such as framework, api, methodology, etc.:

• Lack of support for interacting (communicating) with external functions directly within the API
• Do not work on previous systems (either UI or interact with external functions)

Of course you can always say that the goal is to work in the most modern and will always have someone saying "fuck the old systems" or saying "no one else uses such a system", even catch a customer or a number of users complaining that it is not possible to install or because something does not work as expected.

There is also the problem of Cors and even certain levels of security, it is clear that if one knows the basics of this in "web" will not need to "control" this, but back and forth the lack of knowledge makes many pseudos-programmers fall into a series of problems related to safety, even "injection" of something.

Another problem that goes beyond all this (that is includes everything that was said and goes beyond) are the mobiles, in my experience with Android mainly, something always fails, for example, I usually use SVG for all my hybrid apps, mainly as background, but in this even mobile phones that eventually seemed modern run a limited webView system, of which SVG works with <img> and <object>, but it doesn’t work for the background, and of course the developer probably won’t even notice it until it’s time to go into production.

I’m citing only one problem, but if you start remembering even on Android 4.4, that people consider the minimum necessary for if working I came across one or other failed behavior.

And remember that adding to all this on mobiles there is a big problem, eventually web and webviews are "optimized" for behaviors needed in mobile, examples of situations in iOS:

• "Highlights" that only exist in this system
• the scroll continues to scroll beyond the limit above or below (and horizontally too) in the "body"
• Some propagations of events that work on Android eventually do not work on iOS, such as applying document.addEventListener("input", () => {}) and note that it does not trigger inputs and textareas, however keyup yes (this is not the only example of problem)

I’m not saying they’re problems, but if the behavior is expected in an environment and dev understands it is ok, but most people get annoyed with it in their hybrids, of course most "frameworks" solve this in CSS, but I’m not talking about frameworks, I’m just talking about what to expect if you’re gonna do something about "zero"

---

Conclusion on webViews and Webwindow

I agree that in every development area we end up facing "challenges", but the problem with webViews, whether mobile or desktop, is that there will always be variations of unexpected behavior, in fact it was rare when I didn’t come across something like this, so decide on this "personally" I think is a bit risky.

I am also of the thought that hybrids seem easier and that people are adhering to this and that this has become a fashion (a fashion that may never pass) and that the very people responsible for influencing us to adopt this also did not imagine all the problems that they would face and even so they kept trying to patch up what they did.

But I also blame the "desktop" environments for "failing", I’ll take Qt as an example only. Even by far I find Qt the best of the "market", however it is so full of little problems, the team of responsible back and forth brought old problems back and the most used platform in the world is Windows (and I’m not talking about devs, I’m talking about normal/end users) where I came across more problems like this, a lot of things I ended up having to write on hand to solve, printer problems were common and incredible as it seems, even Qt4 was more limited, but it worked very well, already in Qt5, implemented new things and a correction process in the bug-report that past some updates an old bug already fixed came back to exist, so if the most "popular" failed so much (I’m not saying not to use, I learned to work around the problems) imagine the other simpler solutions.

The problem is that for something to popularize it seems to me that it has to be a "Swiss Army knife", thing that Qt almost was, but its competitors did not come close to this.

I’m not blaming Qt, I just took it as an example, I could cite a number of other problems elsewhere, but I don’t want to lose focus, in this desktop development environment and "zero" compatibility between mobile development is that things like:

• Electron
• Hybrids

They dominated where so many developers wanted to participate (with or without knowledge of the basics), but they didn’t want to have work/difficulty, they wanted easy things and that’s where things like Webwindow started to come up and around and around (as I have already mentioned, it does not seem the first case of attempt), to try to "improve" what works "more or less", if it will "avenge" I do not know say, but for sure it still has much ground ahead.