I'm considering moving a project from cef (CefSharp) to WebView2 WPF. My preliminary tests shows that WebView2 API have the interface I need for this port. I am afraid that I can miss something that can prevent me from switching to WebView2 and I'll figure this out at later stage of this transition. If anyone went through this process, please share if I need to be aware of something that can be a roadblock for this transition. Are there important APIs from cef that are missing in WebView2?
This issue in WebView2's Github answers your question in part. And I would like to add my take.
A summary:
WebView2 doesn't have an API for simulating user input, it's unsuitable for automation.
WebView2 can't render offscreen. No running in the console, as a service, on a server.
WebView2 runs in a separate process; CefSharp runs in the application's process.
WebView2 has a sandbox; CefSharp doesn't.
This answer is based on my personal experience and is not an exhaustive comparison.
Process Model
The Chromium process model has the main process and many auxiliary processes. It is, of course, a bald simplification, but it will do.
Both CefSharp and WebView2 follow this process model with one very significant difference. CefSharp starts Chromium in the application's process, and WebView2 starts it as a separate process.
The in-process model is common to all CEF-based browsers. Pros: the browser starts faster. Cons:
If CEF crashes, it takes the application down with it.
If there's a vulnerability in CEF or Chromium, it can also expose the application's memory.
The out-of-process model is popular among proprietary browsers. Not only WebView2 works this way, but also DotNetBrowser and EO.WebBrowser. Pros:
It's safer.
It doesn't bite off the application's RAM.
Cons:
It starts longer.
It may be slower because of inter-process communication.
Occasionally, there are issues with the focus and drag-and-drop because the browser window belongs to another process. Not applicable for the offscreen rendering, though.
CefSharp process model. WebView2 process model.
A score for WebView2.
Offscreen Rendering
There are two approaches to the rendering of embedded web content. One is to shake off the bells and whistles from an actual Chromium window and embed it into the application. We call this "windowed" or "heavyweight" mode. Another approach is to render web content in memory and draw it on an arbitrary surface. It's called "offscreen rendering."
WebView2 supports only windowed rendering. This mode has two significant drawbacks: it requires a window to function, and the browser always stays on top (aka the airspace issue).
CefSharp also has offscreen rendering. It allows the application to run in the console, overlay web content with other controls, render web content in Unity3D, etc.
A score for CefSharp.
Automation
The bread and butter of automation is simulating user input. CefSharp has an API for dispatching "real" mouse and keyboard events to the browser. The browser handles these events as user gestures, and JavaScript can't tell between them and real human input. Look at the SendMouse* and SendKey* methods in IBrowserHost.
There's no such API in WebView2, only workarounds based on Win API.
A score for CefSharp.
Sandbox
By default, all Chromium processes are sandboxed. It makes them more secure. The Chromium team explains the sandbox in great detail here.
WebView2 and other out-of-process libraries are sandboxed as well.
CefSharp doesn't support sandboxing and, it seems, never will (#697).
A score for WebView2.
See also
CefSharp supports only primary AppDomain.
CefSharp doesn't support commercial codes by default.
In addition to the other answer I'll add some additional points
License
CefSharp is open source, 3-BSD licensed. You can customise the code, fix bugs, submit pull requests, etc.
WebView2 is not currently open source. You need to wait for Microsoft to fix bugs. Currently WebView2 team releases updates every four weeks. Even if a bug is fixed quickly you can be waiting weeks before it's released.
Privacy
WebView2: Data collection privacy notice (at time of writing)
The software may collect information about you and your end users’ use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. There are also some features in the software that may enable you to collect data from users of your applications. If you use these features to enable data collection in your applications, you must comply with applicable law, including providing appropriate notices to users of your applications. You can learn more about data collection and use in the help documentation and the privacy statement at https://aka.ms/privacy. Your use of the software operates as your consent to these practices.
Microsoft has yet to disclose exactly what is captured. Users must opt-out of data collection.
A number of users have raised concerns regarding the data telemetry. There are a number of discussions regarding the privacy concerns here and here.
Distribution Model
Both CefSharp and WebView2 require a specialised version of Chromium to be installed/copied on your computer.
Fixed Version: A fixed version of Chromium is bundled with your application. You control which version.
Evergreen: Chromium is is installed then automatically updated via windows update. On some OS's it will be pre-installed. Currently limited/no control over if the runtime is updated.
CefSharp
WebView2
Fixed
[x]
[x]
Evergreen
[x]
Chromium is rapidly changing, there's a new major version every four weeks at time of writing. Each major release adds/removes features. Security policies are changed.
What worked flawlessly on a previous version of Chromium may no longer be allowed for security reasons. Deprecated features are frequently removed.
For complex applications it's important/imperative to tested against the specific version of Chromium your application uses. This applies to all Chromium based browser.
Evergreen WebView2 Runtime automatically updated via Windows Update sounds perfect? Get the latest version without having to do everything.
What happens when a bug makes it into a Stable Release? Did you test your application against the dev/beta channels to flag upcoming issues? No? You could be inundated with user complaints their application now crashes.
A quick look though the WebView2Feedback Issue Tracker and you can see examples of this happening.
M108 release was particularly problematic with many users reporting issues.
The following are just some examples
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3029
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3068
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3062
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3032
For those using an Evergreen model you must test your application on every dev/beta release to ensure your application works as expected.
WPF
CefSharp provides two WPF implementations, the first CefSharp.Wpf renders every frame to a bitmap, this allows for a native WPF experience. You can apply transforms, layer elements over the top, etc. There are no airspace issues. There are a few downsides the main being performance is lower (there are a few things you can do to squeeze some extra frames).
The second is CefSharp.Wpf.HwndHost, it's a HwndHost based implementation, it's like embedding the WinForms version in WPF with binding support, you get much better performance, no transforms, cannot layer over the top. Airspace issues apply.
WebView2 currently only provides a HwndHost implementation, airspace issues apply. There is talk of providing a more native WPF implementation
Related
I am interested in Kotlin GUI system and I found Tornado FX.
I noticed that we can transform javaFX app as a webapp, so my question is : Can we do the same with Tornado FX and if we can, How should we do that?
Anything you can do with JavaFX, you can do with TornadoFX, as it is basically a higher level API on top of JavaFX.
JavaFX itself has no rendering capability that targets the web, but JPro has rather geniously made that possible by "rendering" the JavaFX UI as SVG directly to the browser using WebSockets.
Infact, TornadoFX has special support to make it easier to create JPro based apps.
Your starting point would be https://www.jpro.one/
The TornadoFX guide contains information about how to use JPro as well:
https://github.com/edvin/tornadofx-guide/blob/master/part2/Scopes.md#using-tornadofx-with-jpro
JPro is a commercial offering, starting av 99 EURO per month for one server with 8GB memory at the time of writing (2018-11-20). Each user would get their own instance of the application, though still running within the same JVM.
While this system works remarkably well, it is best suited for situations where there is low latency and preferably high bandwidth between the client and the server, as every event will be transferred over the WebSocket connection. It would typically be a bad choice for a public facing web page, but it is doable. In fact, http://jpro.one is actually a JavaFX app!
Disclaimer: I am not affiliated with JPro, I'm merely telling you about the (only) way to make JavaFX apps available through the browser.
what does the relation between a Web frontend and a smartphone App with identical feature sets look like regarding the development effort? Are there any specific differences regarding the development effort between Apps of different smartphone platforms (iOS, symbian OS, Android, etc.) ignoring training time? A general estimation would completely satisfy me. ;)
Thanks in advance,
Flinsch.
I hesitate to call this an estimate, or even an informed guess, but perhaps by putting down some ideas I might help your thinking.
Ignoring any particular platform specifics I see the fundamental difference of Web v Native is that in the Web case you have some extra work to do:
a). You have presentation separated from the backend, with probably HTTP in between. So there are services to write and issues concerned with notifications and/or polling to deal with.
b). You're likely using a browser to do the presentation so you will be using some JavaScript kind of library, and these are still hard to drive.
So, if you are targeting a single device my guess is that writing native code is likely to be 50% quicker than web-based code - assuming that you really are targetting identical function.
What seems to happend is that we compromise Web Apps, reducing functionality somewhat and hence the overhead is reduced.
Also there's another factor, the UI portions of the Web App are in principle portable, hence in fact the Web App development may be a reasonable investment even if it does take more effort.
I suspect that portability may well end up being a dominant consideration.
specific differences? There are plenty, but each with their own tradeoff:
UI: Web applications have CSS, (HTML, XHTML, HTML5) specifications that is supported by major browsers (although have have their issues). For Smartphone apps, each UI has to be designed and implemented according to the language the apps can be built on. You can effectively create apps like Winamp (having skins). For web applications, this is relatively a quick effort compared to writing UI's for each different smartphone OS models out there.
Language of use/Portability: In Web applications, an application sits in a server, so every request is sent to the server and response is returned from it. This allows that 1) Web applications can be written in any language of choice, as the end user never sees the server nor needs to configure it, 2) It allows the developer to write in a language that he/she is comfortable in. In smartphone apps, for the developer to run his apps to all the smartphone OS'es, he/she has to learn the programming language for the OS, and learn to port their code to work there (if porting is possible). That never exists in Web applications.
Hardware limitations: For smartapps, the developer must be aware of the cellphone capabilities and limitations. Facebook (e.g.) can essentially grow their memory, and add new servers and cluster their environment as the demand grows. You can't do that with smartphone apps. You will have to limit your implementation to run in a capability that your desired smartphone can accommodate.
There are more (feel free to add) but all these are part of the development effort that a software developer has to look at if they want to go a a field of choice.
How good is a Flex app in handling large amount of data (say, for a reporting kind of application)
Are there any memory management issues that need to be kept in mind while developing for such an app
Are there any issues in running a Flex app on a Mac?
1) great as long as you're not transferring huge amounts of data at one time using HTTPService. A good AMF remoting like amfPHP runs super fast.
2) Flash player runs on the clients machine, you would need to make sure you aren't using more memory than they have available.
3) If I remember right flash player is kind of weak on the mac, much slower than PCs but I haven't bench-marked them in a while
Flex can use a lot of memory in a poorly written application. A well written application will manage it's assets well and will not use more memory than needed. Flex is wonderful for a reporting application since you can do data manipulation on the client and do a lot of client side analysis and re-presentation of data.
Profiling. Flex Builder has a decent memory profiler so make sure you use it and don't leave dangling references around. Event handlers can keep references you don't realize if you don't clean them up. States can also cause problems if they're used inappropriately--to manage the state of the whole application for example instead of in a small scale within individual application components.
Flex is slower on the mac. This is largely due to the limited api provided by browsers on the mac. On PC the Flash Player has access to GPU acceleration and other low level API's which can make it faster. This is going to get better when Flash Player 10.1 is released since it will take advantage of new core animation api's available in Safari 4 on OSX 10.6.
Currently i am working on developing one Warehouse solution from scratch, i am planning to build it in silverlight (as this solution will take around 8-10 months) and the programming will start from Feb 2010.
I need to develop this application for one organization. Certain parts needs to be accessed by public which we are planning to build in ASP .Net 3.5
Now i just wanted to start a thread here for pros and cons of using silverlight, some of them i have already analyzed
Pros :
Rich UI
Excellent user experience
Reduction of scalability concerns
New set of features like data binding, control template etc..
Speed of development (After initial learning curve..my experience says it is faster to develop it in silverlight)
Other rich set of features coming up with SL 4.0 (SL 4.0)
Cons :
Cross platform issues (moonlight is there but it may take some time)
Cross browser issues (Chrome or other browsers)
Learning curve
Any other unknown risk (As there are not many enterprise level application developed in silverlight...or may be i am not aware)
I have also got one link for Pros and cons of silverlight(here) some of the cons might not be relevant with SL 4.0
Also i am having one good link for comparison between ASP .Net Ajax with Silverlight (here)
EDIT :
I have also found Technical Article series in code project (Just Type # google "Adventures while building a Silverlight Enterprise application" and you will get it, i am trying to analyze this series as well)
Please add some pros and cons if you find as i am trying to analyze it from all the angles. It will be of great help if you find any whitepaper on it.
The Pros and Cons have to be weighed against your own requirements.
Rich UI
Compared to what? Its not really a Pro, other tools can deliver Rich UI, where does one draw the line that allows a UI to call itself Rich? A Pro can't be a Pro if can't be measured.
Excellent User Experience
That isn't a Pro either. I wish I could buy product that delvers such a thing out of the box. The reality is it's up to you to deliver the UX. E.g. Stackoverflow delivers an excellent user experience, it doesn't use a tool like SL and it's entirely down to good design not the tool (ASP.NET-MVC+various other tools).
Reduction of Scalability Concerns
Compared to what? Early ASP.NET Forms with extensive use of callbacks then yes. However plain old HTML with Javascript frameworks can deliver this same "Pro".
Speed of Development
Well that depends on how you measure speed and how you weigh the importance of the UX. Currently SL developement isn't any better at ticking off business function points than other tech like poor old ASP.NET Forms and is probably worse. However delivering those same function points with a slick, imaginative UI may tip the balance more in WPF/SL's way. In reality SL allows you deliver more UX with some (but importantly not prohibative) extra effort.
Other Rich Features in SL4
Only a Pro if they would actually add value to your requirement.
Cross Platform
Do you really have a Cross Platform requirement? Within a warehouse business how many Linux and Mac desktops are there? That should answer your cross platform question.
Cross Browser
Is this a Con? Does the company in question allow the use of a variety of browsers? If so which? You can compare that to the browsers SL4 supports and out pops your answer but its your answer not everyones answer. Isn't cross-browser a bigger concern for the Extranet-esq part of the app?
Learning Curve
In all of these factors what are you already versed in is by far and away the most important. I'm guessing its MS tools and in particular .NET, right?
If you're not familiar with WPF already there is some learning curve but its not very steep. However you should definitely make sure you take the time to perform some training projects before you even start designing your real product. That process should help you measure how long it will really take and whether it is really feasable.
Other Known Risks
SL is still very young and it won't sit still. Frustrating "issues" will eat time.
Other questions to ponder
What UX ideas do you have that can't be delivered by a browser?
Why deliver the app via a browser hosted app at all? A WPF application not an option?
Silverlight 4
Considering your timescales if you do choose Silverlight you should target SL4.
Since you are developing solution for the warehouse, you may need consider building a web service with wcf pollDuplex (basically push data from server to the client periodically), just a note on it: it is not (yet) a very scalable and reliable (prior to SL4). Default concurrent connection is 10 (if I remember well), and you have the option to overwrite this default number, however, I haven't find a way to dynamically change this number which turns out to be a scalability issue.
One cool feature I like about SL 4 is the added support of printing, now you have the built-in ability to print the content.
Anyone bulding an Enterprise LOB with a Silverlight client should take a look at John Papa's PDC video.
However, IMHO the initial release of RIA Services was too limited. Now that the next version is buit on top of WCF Services, and the endpoints can be switched out to make them more accessible by more UI clients RIA Service is probably a very sensible investment too.
I have been building enterprise software for the last 10 years. In this time we have seen enterprise applications move from client server to thin clients. We have also seen the move to hosted solutions, albeit under a few names (asp, SaaS, cloud computing). With all these changes the impetuous has been mainly from driven from the IT department not the end user. In the first rounds of these revolutions the user experience was reduced in the name of single point of management and reduced desktop footprint.
During this time there have been many attempts to give the user a rich experience while still satisfying the crotchety IT department. The first was by the industry leader Microsoft in the form of the ActiveX control. The guys from Sun then followed suit with the applet and then more recently java webstart. All of these solutions seemed to scratch the itch but never gained wide expectance by the more stringent IT departments.
Then flex came on the scene from Macromedia. What did they do differently? Is it sustainable? Does Microsoft’s emulation with Silverlight prove they have changed the rules of the game? Will Web programming be changed forever?
Adobe have succeeded because almost all users of the main browsers on the main platforms already have installed the only runtime component required for Flex; which is the Flash player. The Flash player has already demonstrated that it isn't a vector for Bad Stuff; it runs in its own sandbox in the browser, isolated from the hardware and the OS. So no new (and potentially dangerous) software is installed.
There exists a substantial developer community for Flash technology, and the addition of some new controls in Flash, and maturity in ActionScript for writing software, has tipped it over the threshold for being fully useful as a RUI.
(Activex is Windows-0nly; Anything in java is perceived as destabilizing and too heavy; and java hasn't managed to wangle its way into ubiquity, nor will it probably ever do so. So both generally get installed by edict, rather than user choice. This in spite of the fact that Adobe is probably the most disruptive source of unrequested "update-checkers" and other near-malware we deal with in our ecosystem.)
Microsoft started out with Silverlight pretty aggressively, requiring only the installation of the equivalent of the Flash runtime; but it's not ubiquitous even on Windows machines yet; penetration to other platforms is quite a way in the future; and MS hasn't proven to have the political smarts to appear harmless yet. But don't count it out. I think they've moved a step back by switching to .NET languages (with a limited CLR) for development; this seems to me to be the same strategy that has deoxygenated their WinCE strategy; but again we'll see. But at least they have made an obvious move away from language agnosticism to appearing to want to coerce developers into .NETland.
Web programming is changing forever one way or another; users will demand a better, more fine-grained UI; there's no perfect answer in sight yet, but at least there is competition for hearts and minds. I think the most encouraging signs come from Microsoft's strong move into platform-neutral stuff like MVC, Iron Stuff, and increasingly unpolluted code streams to the browser.
My take on Flex's success:
1- Adobe made the right move in opensourcing not only AIR, but Flex, the Flash VM, and the PDF standard now as well.
2- Flex's rich Flash heritage (it runs on any Flash enabled browser) means that the vast majority of browsers already support it and do not need to download a large plugin to access it.
3- Adobe embraced all the major server-side technologies and provided support for them so that a PHP. MS, or Java shop would all feel comfortable using Adobe's client side technology.
Previously, Flex was closed-source, expensive, and even relied on a server-side installation, which negated it's reach even though the Flash client was so widely available.
YouTube and the general ubiquity of
Flash video entrenched the Flash
player into over 95% of the browsers
that are accessing the public
Internet.
Incorporating Flex GUI for form
design with widgets and an extremely
well designed GUI SDK was a major
turning point for the Flash player.
Flex 2 and Flashplayer 9 were the
tipping points of when this
technology really jelled. Enterprise
developers began to quickly realize
that this technology was just the
right approach for doing their
applications. (At JavaOne in 2006,
Adobe Flex 2 was the most impressive
and pivatol technology that I saw
there.)
The Flash runtime has just enough
stuff to run RIA GUI well in a web
browser sandbox setting - Java
applets required the full JRE (about
16 MB). The Flash runtime was a much
leaner and smarter design for its
intended purpose. (Sun has only now
begun to remedy this for Java via
their JavaFX and redesigned JRE that
can download a few MB as sufficient
to run a web applet. They don't have
anything like YouTube Flash video to
drive their installations, though.)
Writing Flex RIA applications is a
very leveraged experience compared
to writing old-school web
HTML/JavaScript AJAX apps. Can
achieve a great deal more and have
less effort to accomplish such.
Adobe bolstered Flex with other
important pieces, such as BlazeDS
(and now they're cooperating with
SpringSource to make BlazeDS and
Spring-Framework a smoother
integration).
The single-thread GUI in combination
to async service calls (or
messaging), and ActionScript3
closures is great programming model:
Flex Async I/O vs Java and C#
Explicit Threading
Likewise, Adobe Flex has a great
implementation of properties,
events, and databinding.
A declarative language, ala MXML, is
indeed a better approach to
describing a form (what is
essentially the view in the MVC
pattern). It is more concise than
equivalent imperative ActionScript
code that would accomplish the same
thing, and thus clearer. The
hierarchical structure of MXML
script tends to naturally match well
to the panel/widget construction of
views as well.
With Flex RIA approach, the MVC
pattern can be implemented
completely on the client tier. Web
frameworks that implemented MVC in
the middle-tier - with the
presentation layer executing in the
remote client-tier, was a
fundamentally flawed approach to
MVC. MVC should be done right at the
tier that is directly user-facing.
(Once again, Adobe Flex does things
right architecturally.)
Despite that HTML/DOM/JavaScript is
considered the pervasive standard of
the Internet web, the Adobe Flash
player is actually a more ubiquitous
and consistent standard - spanning
different browsers and operating
system platforms. The
HTML/DOM/JavaScript standard is in
actuality a fragmented mess that
grows more fragmented everyday as
Google and Microsoft drive different
directions on things regarding the
web browser. Adobe Flash player ends
up being a wonderful end-run around
this dilemma. It's a great
programming experience for the
coders and has sufficient ubiquity
for the business suits.
Adobe is smartly well supporting the
major platforms of Windows, Mac OS
X, and Linux. They pay special
attention to the Linux platform.
This will pay off in the long term
as developers are already settling
on Linux to do their development
from, and it's used extensively for
servers hosting their middle-tier.
Adobe's recent 64-bit Flash player
for Linux is just a marvel. They
already have AIR 1.5 available on
Linux. They are doing a decent job
there of supporting the platform
that the developers care about.