Why is this release of Frogui called "alpha"?
The basic feature set is nearly in place, but it is not complete. Nor is the installation process is not polished.
Also, Frogui is dependent on Mono for WebAssembly, which has been improving steadily but still does not have Ahead-of-Time (AOT) compiling finished so an interpreter is used instead. The most noticeable evidence of this is performance; apps run much slower presently than they will once the Microsoft Xamarin team gets the compiler completed.
Which version of .NET is used with Frogui?
There are two builds that take place in a Frogui project, a client-side build which uses Mono for WebAssembly and a server-side build which uses .NET Core. Both are based on .NET Standard.
How is debugging achieved?
Eventually, the debugging experience will be identical to debugging any other .NET application within Visual Studio. Presently, the Microsoft Xamarin team is just starting to add debugging capability. As a work-around, each Frogui project generates two outputs, an ASP.NET Core Server-Side and Mono for WebAssembly. Each can be built for debug or release:
  • Server-Side debug: presently the only way to fully utilize Visual Studio debugging.
  • Server-Side release: serves no purpose (though gives best indication of future WebAssembly performance).
  • WebAssembly debug: presently not useful (will change in future).
  • WebAssembly release: this is what should be published.
How is Frogui's performance relative to JavaScript?
There are two factors to consider when thinking about performance: the UI layer and language execution.
With the UI layer, both Frogui / C# and CSS / HTML / JavaScript will be accessing the same browser API so performance should be virtually identical in an apples-to-apples comparison once Frogui has been mostly optimized. In more complex scenarios, such as those using data-binding, styling and code-behind, Frogui / C# will have the edge.
As for language execution, as the moment the Mono for WebAssembly compiler has not been completed, so JavaScript has about a 17% edge over interpreted Mono assemblies. Once the Microsoft Xamarin team completes the compiler, C# apps will be running natively so will be significantly faster than JavaScript.
To get a good idea about what to expect performance-wise, run your Frogui app server-side build from within Visual Studio (debug or release), and not the WebAssembly build. This will always show the current performance ability.
What if I need a control that is not in Frogui?
If it a control that would be a natural fit to add to Frogui then let is know and we will add it. Otherwise, there are multiple features that allow customization.
Does Frogui use Bootstrap or other popular web UI frameworks?
Presently, no, and ideally never. Web UI frameworks help with a variety of things such as element display and interaction, data-binding, responsive layouts, etc., that all basically build around the core philosophy of CSS or add non-native features that have become commonplace outside of web development.
Frogui is a holistically integrated API that checks many of the same boxes as CSS / HTML and these popular frameworks but goes about its business in a very different way. For instance, Frogui uses brushes (color, gradients, image presently) to render everything. CSS, while immensely capable, has no concept of brushes.
That said, if there is an opportunity to leverage something from any of the excellent web frameworks we will. For instance, jQuery is used internally for cross-browser compatibility.
How does Frogui data-binding compare to Angular or React?
Angular and React are notable examples of web frameworks with solid data-binding capabilities. From a semantic standpoint, Frogui's data-binding behaves in much the same way. But Frogui's syntax is much cleaner since it has the advantage of C# (strongly-typed, high performance), Visual Studio's debugging, and can also be written using XAML.
There are features web developers take for granted that aren't in Frogui, such as responsive layouts and in-page anchors. Can these still be accessed?
At some point it might make sense to open up the API to allow custom HTML/CSS/JavaScript injection. Our current approach is to extent the feature set so that developers do not have to think in terms of needed third party frameworks. Taking advantage of all the power browsers have to offer is important, as you can see here in our comparison to web development. For instance, the Flex element is completely based on HTML's flexbox, which is very useful in creating a responsive site.
How often will there be updates?
We will release versions as soon as a useful set of changes have been added, such as new features and bug fixes. In the past year there have been four releases. Ideally, it becomes more like once a month.
What is the price of Frogui?
Exact pricing plans have not been decided. Keep an eye on the pricing page. There will always be a free community edition.
What about licensing?
Frogui's licensing model has not been decided, though we are leaning towards a proprietary license with source guarantee.
Where is the documentation?
There is very little documentation now. Here are the best options:
  • Take advantage of Visual Studio's intellisense and code documentation in the Frogui assemblies.
  • Fork or download the demo solution from our GitHub repo.
  • Because Frogui strongly resembles WPF, the vast sea of documentation and articles on the web are very useful, though beginners may have a tough time differentiating between what content is and is not applicable.
  • Hit us up! Get in touch. We answer every question.
How broad will browser support be?
The goal is to run in all major browsers, including those in devices such as mobile and televisions, but we have not done much testing yet.
How does Frogui compare to Silverlight?
  • Both Frogui and Silverlight are direct descendants of WPF
    • Silverlight is largely a subset of WPF
    • Frogui is a partial subset of WPF and strongly influenced by modern web features.
  • Runtime
    • Silverlight requires a browser plug-in, a mostly obsolete technology thanks to the web's evolution.
    • Frogui runs natively in the browser.
How does Frogui compare to WPF?
WPF serves a blueprint for Frogui since we believe WPF is the most robust UI framework ever designed. Here's an in-depth comparison to WPF.
How does Frogui compare to Blazor?
Check out our Compare to Blazor.
How does Frogui compare to server-side scripting like Ruby, PHP, Python, Node.js and ASP.NET Razor?
Server-side scripting primarily focuses on generating UI layout at the server level, resulting in HTML / JavaScript client pages. Usually such apps are thought of as multi-page apps (MPA), because they involve multiple pages that may be navigated within the browser.
Frogui is a true client-side web app running natively and completely in the browser. Frogui can be used to created multi-page apps or single-page apps (SPA). As an SPA, Frogui requires only the lightest of web servers for its one-time load.
Server-side scripting using any of the frameworks mentioned above could definitely be used to make Frogui MPAs since there's nothing magical about the files being served (.wasm and .dll files sit right next to .html, .css, .js files, etc.).
Is this C# compiled to JavaScript?
No. All compiling and building is done by tools being created by Microsoft, resulting in genuine IL assemblies.
It is easy to be confused given the variety of technologies that have attempted to provide developers a JavaScript alternative. For example, TypeScript. Ultimately, though, they all just turn into JavaScript.
Is this real C# or a variant?
100% real, latest C#.
Can C# ever really replace JavaScript for web apps?
JavaScript's grip as the web client language was dealt a serious blow when all the major browser players agreed and subsequently implemented WebAssembly in 2017. JavaScript no longer has an inherent advantage. For the foreseeable future our understanding is JS is required to do a bit of bootstrapping for WebAssembly but the performance hit will be negligible.
Developers are already using their preferred language for web development, including C#.
How does Frogui XAML differ from XAML?
Sort of like how English differs from country to country: clearly close relatives but enough differences exist that some learning is involved. Humbly, we feel our XAML is cleaner and offers more flexibility.
Note that even within Microsoft there are different variations of XAML, as well as a number of third party XAML variations. For that reason, we just call it XAML.
Does Frogui require a web server or will a file server work?
Frogui does require a web server. Projects are ASP.NET Core based. And typically within Visual Studio, IIS Express is used by default for debugging and running standard builds. For WebAssembly builds, a web server is required since Frogui and Mono for WebAssembly use the Fetch API.
Beyond a web server, no servers are required.
How does client-side scripting work?

It doesn't! The beauty of WebAssembly is that developers no longer are beholden to JavaScript for web development. Instead, WebAssembly allows true compiled apps to run, just like on the desktop and phones. (The ground underneath web developer's feet is shifting, regardless of whether they realize it or not.)
Frogui takes advantage of this. It's pure C# compiled to run in .NET natively on the web. Now, underneath Frogui does use HTML, CSS and SVG, and a tiny bit of JavaScript to "glue" a few things together but that's another story :)
How does this all work with Garbage Collection?

Ultimately (i.e. when MS Xamarin completes the compiler), GC will work just as it does with other .NET flavors.
I'm confused on the WebAssembly bit. Is this really WebAssembly or is this WebAssembly compiled to JavaScript?
This is true, 100% native compilation and Jitting of C# to IL that runs in the browser. Underneath there is tiny, tiny, tiny bit of bootstrapping JavaScript but that's it.
Yes, this is a very confusing concept given the years of transpiling other languages to JavaScript. Fortunately, those days are numbered!
Will this work with the MVVM library Prism?
MVVM libraries have shaped the Frogui API. In other words, features that required a third party framework such as Prism have been incorporated as first-class Frogui citizens. That said, we have not used Prism specifically but plan to explore either integrating it as we did with Reactive Extensions, or using it for design inspiration.

© 2020 Lesarde Inc.