...10.1 MBytes compressed, 53.8 MBytes uncompressed. Needs a splashscreen and 10 seconds to start (on a 50 MBit connection)
It's one thing to "simply" port some cross-platform-code to WASM and make it run in the browser, but making it a proper web application takes some actual effort. I feel that "efforts" like this just give WASM a bad reputation. Sorry to be blunt.
I agree. IMHO Microsoft made a rather poor choice earlier by pushing Mono-based Ahead-of-time (AOT) compilation - when they should have thrown their weight behind CoreRT (now called native AOT). It looks like it's moving in the right direction now with native AOT [1]. Ability to target native code and WASM (without the baggage you mentioned above) with C# can give Go a run for its money.
I get why they did it to some extent, although I agree with the sentiment they didn't put enough weight behind CoreRT (Honestly I blame their cloud-centric view; the result is ASPNETCORE has been swarmed with developers while CoreRT has a few that also tend to have to work on the main runtime.)
BUT, putting Mono out there let everyone else in the community start developing tooling (that Microsoft will take the best ideas from before politely acting like the community didn't keep the whole idea afloat.)
+1 Trying to quickly build something based on Mono will probably result in a subpar solution, that they won't be able to really fix later on, because it would break backwards compatibility. End result will be half-fixed solution with some great technology, but with just enough underlying issues that will remain there forever. Classic Microsoft.
The strengths or weaknesses of CoreRT aside, it's a simple fact that Mono was ready and CoreRT was not. No number of strategic or tactical decisions will change whether a piece of software is ready to ship. Uno going all-in on CoreRT would have meant they shipped a working product later.
For context, the Blazor team started with their own interpreter compiled to WASM (via emscripten) instead of using either Mono or CoreRT - because shipping and getting user feedback is really important, and you can't do that while waiting for the ideal tech to be ready. It was swapped out later.
CoreRT is pretty cool tech but I rarely encounter anyone using it. Hopefully that will change in the future. The only CoreRT-based production app I know of is Streets of Rage 4 and it's a very recent release.
To be fair, CoreRT was an experimental project that was never officially released. So, it's not surprising you rarely encounter anyone using it. Issue is that it seemed like it's development never got allocated a serious amount of resources.
I agree that getting early user feedback is really important, but IMO it would be better if a limited version of Blazor WebAssembly (that would support only subset of .NET features, but have usable runtime size) was released on CoreRT tech and then slowly add more features. Blazor WebAssembly at it's current state, even though it supports all features, is too big to be really usable.
Spreading development resources thin between old tech like Mono and future tech just means future tech will be delayed even more. And when they figure out that in order to get the size down to a competitive levels, it would be better, if some features were kept out of the WebAssembly runtime (eg dropping reflection and relying on code generation instead), it will be too late, because it'll break compatibility with released Blazor WebAssembly projects.
Note that .NET for WebAssembly is still in its early stages and the .NET team is likely to continue working on AOT compilation in the coming months, and the Uno team is going to help. This will be improving the payload size and performance that is currently very much lacking in that mode. Interpreted IL mode (the UADO app) is used where the AOT engine is not yet working properly, providing a base to get the framework itself progressing, while the infrastructure rest is improving.
Many of the .NET constructs are expecting exception handling (https://github.com/WebAssembly/exception-handling), which has to be emulated as it is not yet available in WebAssembly, adding significant code to the payload. Same for other features like null reference checking or indirect invocations (some may know more on that last one). Other features like lazy WebAssembly loading (for more than 4KB at least) and Interface Types to remove any Javascript (https://github.com/WebAssembly/interface-types/blob/master/p...) will also improve the actual and perceived performance significantly.
The immediate goal of the project is to provide the ability for new and existing C# apps (and not Web sites, not yet at least) to be available for non-walled garden environments. We expect the field to progress significantly in the coming years on many fronts, making this kind of apps more useful and viable.
Finally, you'll find that the Windows Calculator port to Uno is actually stretching thin the browsers resources because of the size of the Wasm payload (browser's memory and CPU is going really high because of the internal WebAssembly management). Yet, once the tiered compiler has cached the result, the load time goes down significantly.
That would be a question for the Edge and .NET team, but unfortunately that does not seem to be an option. The IL Linker (tree shaking) is removing unused parts of the binaries for the purpose of removing very large portions of code in the final binary. If binaries were to be bundled, or CDN hosted, we'd end up downloading extremely large unnecessary portions of code.
Yet, this simple fact that a WebAssembly app needs to download everything its needing to run puts it at disadvantage with Javascript (you download a browser with all the base libraries only once, and that's not lightweight).
For now, WebAssembly apps (in general and not just .NET ones) are more similar to mobile apps than websites, just because of this significant difference.
Just call into the browser to do any of those APIs and the problem is solved. The problem is you're taking your C# / .NET libraries for which solution already exist in the browser instead of building APIs around what already exists in the browser.
To put it another way, instead of starting with wrapped native apis and doing wasm last. Start with browser apis and make native ports of those, then you'll get something that works well in the browser and (95% of the time IMO) will work fine in your native version as well.
Why don’t we push for first class wasm precaching in browsers? Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard? Then app makers could target a .wasm standard release and if the browser didn’t support it, polyfill in at app start the missing features?
> Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard?
There's already a plan to give WebAssembly direct access to DOM, and to any other API JavaScript would have access to, without needing a JavaScript shim. (This requires integration between WebAssembly and the JavaScript garbage collector, which is part of why it's taking time to develop.)
For various reasons, doing anything like that in any browser is nearly impossible. One major obstacle is that CDN content cannot be cached cross-site anymore (by design, for security reasons) in any browser, and it would be a hard sell to compromise that anti-fingerprinting measure just to optimize load time for specific first-party WebAssembly code.
While I definitely can't see this being useful for general websites/web applications, I guess I could see it being useful for "line of business" internal web apps for businesses?
But then, I don't understand why you wouldnt just make it with web tech to begin with and 'port' it to native platforms with Electron.
haven't found a universally good option yet; delphi was close 15 years ago, but the world forgot about it mostly. hoping for WASM+compiled language framework somewhat like this one to fit the bill so I don't have to worry about supporting multiple browsers, multiple browser versions, cross platform support, css...
WASM (language independence) on electron (fixed, controlled browser version) with delphi-like UI designer could work, maybe.
btw. one can also use blazor server-side for business line of applications, which is way more smooth and only needs websockets.
so I have no idea which target c# client-side wasm (uno/blazor/whatever) has at the moment, because it simply is too big.
Historically, the companies with large line of business apps that were interested in using JSIL to run C# in the browser were interested specifically because rewriting their software from scratch in Electron was an expensive and time-consuming undertaking. This made it worthwhile to invest in alternatives that would let them reuse existing code. We're talking massive WPF or Silverlight codebases with decades worth of developer time invested that would all go out the window.
The same logic applies now and it's even more compelling since the tooling and performance are better now with the full LLVM WASM toolchain and more robust C# AOT compilation available, vs the dark ages when people had JSIL, Saltarelle and Bridge to choose from.
I'll also note that every major company I'm aware of that made a C# -> Browser move for their tooling eventually regretted it and started shifting away to something better, partly due to platform churn and partly due to how much was outside of their control. Electron may change the equation there enough to be good enough, we'll see - I don't know of any companies that have taken that route yet.
So admittedly it's not as fast and compact as a 'native' web application (ironically), but zooming out a bit, how do you feel about it as a write once, run anywhere framework? I mean the webapp is a fallback for when you don't want to or cannot install one of the 'native' apps, which probably weigh in at similar sizes all things considered.
I don't think this is intended for public facing, low bandwidth/mobile websites.
These are also "write once, run anywhere" but with more focus on keeping the binary size small (both in WASM and for the native versions).
These demos start at 23 KBytes compressed and go to 537 KBytes compressed for the biggest UI sample (over half of those 537 KB is embedded TTF font data though).
At the same time, if I'd be using Qt instead of Dear ImGui to create the UI, the resulting WASM size probably would be similar to the UNO samples,
Writing cross-platform code that also works well on WASM really needs a different mindset from the ground up IMHO.
for some reason the text looks quite a bit more blurry and less readable than the same thing rendered with Qt on my machine. You should really consider using Freetype, Harfbuzz and friends, right now it looks like there is no hinting or something like that - see e.g. https://i.imgur.com/YgKFcd0.png
(yours top, Qt version bottom - I tried to match the font sizes visually but did not manage to decipher your code to find out exactly what they should be x) )
Yeah, that's one downside of focusing on size alone, you'll have to make many compromises what to include and what to leave out. I'd love if browsers would have font- and text-rendering APIs that are low-level enough to integrate with WebGL/WebGPU.
I have been planning to write one based around 2D canvas that uses pixel scanning and alignment properties to compute the metrics information that has been missing from the native APIs. Would allow a basic glyph atlas and layout, but I do wish had access to a glyph shaper directly....
Further, going though gallery and clicking the stuff on the left column, each one takes 1/2 second to 2 seconds to respond. Maybe it's loading something over the net (too lazy to check) but it's not a good impression.
You're right that this is not optimized for the Web, but I also think there is a use case for this.
Sometimes you just want for code to be able to run at all, even with a sizable download, if it means you don't need to do any porting work. For example if you have many years of work on a codebase, and you can run it on the web with almost no effort, that can be really useful.
I agree that we want most things on the web to be optimized for the web. But sometimes business or other reasons matter more than code size.
I'm genuinely struggling to think of a situation where users would be happy to sit through loading a _fifty megabyte_ web page but unwilling to just download a damn desktop app and be done with it.
Maybe many users would prefer a desktop app if they use it repeatedly, I agree. But if it's a website you just visit once, it's simpler and safer to just download 10MB of compressed data than to install an app.
Many people can't install an app. Period. "Can solve my problem after a 2 minute load time" vs "can't solve my problem" is a pretty easy decision to make.
I've been playing with compiling Go into WASM for the last year. The size of the "binaries" created is entirely based on which libraries you include. Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code. Once you include the relatively few libraries you need, you can write a ton of code and the size of the code effectively stops growing.
> Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code.
Part of including unicode package itself (transitively or otherwise) has a ton of package-level vars that bloat the WASM. Also, they slow down init because a bunch of code has to be run to initialize them. Also, due to the fact that WASM doesn't have arbitrary jumping, in order to support coroutine yielding and resumption, Go's WASM support puts big br_tables[0] at the top.
A while back, I brought up some efficiency concerns w/ data size and init instruction count[1] but they were dismissed as WASM concerns not Go ones and there weren't any easy/obvious wins. Also a while back, I used an interpreter to run the Go WASM up until actual main, then bake in the data that was initialized and remove init for packages where I didn't need their values[2]. I kinda gave up on using Go and WASM after all of that, but there is real room for improvement there.
That's some great insight! I just learned to avoid certain packages altogether and I've been living with the results. Precomputing init() is an interesting idea and I could see it both increasing or decreasing the resulting binary depending on what's in it (similar to how running LZW compression on an already compressed value will often create a larger result). Of course, you also need to consider the init() execution time and I've generally built my "main" application to load really fast and then load sub-applications as libraries in the background. Note that these are experiments and I don't have a major WASM-based UI in production.
Dependencies are the killer for webapps as a whole, and the general deficiency of web platform APIs is a big part of the problem. Want internationalization? Better compile ICU and ship 5+mb worth of code and data with every app, because the web platform is an absolute disaster for anyone who doesn't speak English. Want cryptography? Well, you can get it as long as you rewrite all your code to call out to JS and use async APIs for a synchronous operation. Want to decompress GZIP or Brotli? Time to compile those too and ship big blobs because the browser won't let you access its compression codecs either.
This first example just gives me a pop-up saying "Download the application for a better experience" and sends me to the play store, and the second shows a distorted icon and never loads. Touché.
I think thats because WASM were not meant to serve those cases.
I see WASM more as an "accelerator". The big chunk of code continues to be Javascript that can consume WASM modules.
I dont think this case of whole complex applications in WASM will fly. It looks like ActiveX 2.0 all over again.
Of course some things will happen as full apps in WASM, but they are mostly tools people already use outside of the Web, so that particular crowd just want to reach the tool, it doesnt matter the medium.
It's a terrible calculator, quite apart from the ludicrous launch time.
Just try driving it from the keyboard, which is how most people use calculators. Doesn't respond to enter, return is not mapped to equals, no key is mapped to CE or Clear. Did they even try using it?
The CLR and BLC provided a lot of services, of course this code taking some space. It’s totally a WASM problem since there is not other way to ship the C# runtime and libraries than downloading them each time. Exactly what plugins (Flash, Silverlight) were avoid...
IMHO the main problem is choosing a language which needs a big runtime in the first place. UNO seems to be at a point where the Unity game engine was about 5 years ago in their asm.js/WASM efforts. In the end they realized that it's impossible to get the .NET runtime small enough for the web (at least for typical C# code which uses common standard library features).
The way Unity solves this is by creating their own C# dialect, compiler and minimal runtime (without GC etc). Sort of a brute-force approach, but until the standard .NET ecosystem solves the bloat problem it would have been better to build on a different language ecosystem.
While you're correct that Unity "solved" the problem, you can't generalize their solution to things other than games. You end up needing a bunch of custom ecosystems for specific problems and when we're talking about enterprise, education, etc apps they often end up needing everything because sometimes you just end up with a massive Our Company's App that has 20 different responsibilities.
To put it another way: Adobe can ship Photoshop using Emscripten, and big companies can probably eventually ship their internal C# business apps using Uno or Blazor, but you're not going to ship either of those using Unity's stock approach without building out all of the platform APIs they stripped out and adding back runtime features that were removed. The decisions they made were perfect for games, but people building general-purpose platforms can't cut all those corners.
I mean the new "DOTS" stuff: Burst compiler, the HPC# language dialect, new ECS, and "Project Tiny". All except Project Tiny is being built mainly to improve performance, but it also benefits the web as target platform.
This is basically the same thing that Android did with Java. I think it’s probably best to pick a productive language and solve the problem from there. Low level languages are rough to work with when compared to what you get from unity.
Is this a "WASM" problem or is a "hey we decided to ship all of C# to the browser" problem?
I think this is a fine tradeoff for certain contexts and usages, but I don't think the general usecase for WASM is to build general web applications in C# and ship all of the CLR for things like gmail.
There's some inherent overhead in a .NET runtime which will be hard to get rid of, like the garbage collector. In the end it probably comes down to .NET being "too dynamic", making it hard to identify and eliminate dead code. Also typical high-level C# code tends to use a lot of 'standard library' features, basically the opposite of the 'embedded coding mindset' needed for small WASM apps.
If anything, the BCL or common libraries are too "static", where some pieces of code reference statically all features available.
One great example is JSON.NET: That library has basically one big method that type-checks all possible inputs, making unconditionally reachable every dependency for all features of the library. In this case, JSON.NET pulls the XML reader, DataSets, and many huge libraries that are generally not needed. In Uno, we generally don't AOT those libraries and use the interpreter for that (otherwise the payload would explode).
Such libraries need to be changed to be configurable, and dynamically enable dependencies as per the user's needs.
Conversely, many pieces of code are excluded by configuration because of reflection uses, but the .NET team is improving that scenario (https://devblogs.microsoft.com/dotnet/performance-improvemen...) with attributes to tag dependencies and hint the linker.
A similar problem exists in the C/C++ world: designing a library in a way that supports good dead-code-elimination isn't something that many library authors think about.
Interestingly plain C libraries often do this better than C++ libraries (e.g. too generous use of virtual-method-interfaces in C++ libraries, or making heavy use of C++ stdlib containers when simple C-style arrays would do as well).
The Unity engine also suffered from a similar problem: If you used a simple physics feature like a stabbing collision check somewhere in your code, the entire physics module was pulled in, even though the code needed for stabbing checks is only a few percent of that physics module.
This is why I'm a bit sceptical that improvements in the .NET "machinery" alone can solve this problem. You also need to restrict language features and select the right dependencies. This is a general problem, not just web-specific, it's just that reducing the output binary size typically isn't a high-priority problem outside the web.
Yeah, as you point out C++ libraries are especially hard to do DCE on. If you want to ship ICU in the browser right now it is a very big blob that it's hard to perform DCE on because the vtables retain lots of unused code and every API depends on every other API. A lot of this stuff was designed in an era before anyone could have anticipated the size constraints that would apply in 2020.
There are some big improvements in .net 5 that allow more granular linking and should help reduce solitary binary size, and that may trickle down to Mono and Wasm soon.
The Safari Support for large WebAssembly binaries is not particularly great at this point. We hope that the Safari team will improve the performance aspects of WebAssembly, but it does not seem to be a priority at this point (see the Wasm feature map here: https://webassembly.org/roadmap).
Unfortunately it looks like the output, at least on the web, is completely inaccessible. The DOM of the Simple Calculator example (https://calculator.platform.uno/) and the gallery (https://gallery.platform.uno/) is a div soup with no use of HTML-native widgets for buttons, radios, checkboxes etc. Nothing is keyboard-focusable and there's no screen reader support at all. I'm not sure how it fares on desktop but I would strongly urge people not to use this in its current state for web applications
Then somewhere in your <head> you point it at the pages data representation.
I'm going to bet something like this will happen and be a stepping stone towards the future.
It will have a million or so problems to solve such as accessibility, but I'm convinced all we do in programming is reinvent wheels but reduce the friction to speed as we go.
Wouldn't separating the indexable content from the actual DOM representation be a huge opportunity for abuse? It seems like it would make it much easier to game SEO or mislead users for even more malicious reasons.
I think it's already happening in a little different form with Structured Data [1] and schema.org and it's using for example JSON-LD [2].
But a separate endpoint might also be an evolution. Right now this could be the sitemaps and robots.txt as an entrypoint for spiders.
Although the one drawback that comes to my mind with a separate endpoint is that it'd have to be kept in sync with the normal page and that might vastly enlarge the costs for maintaining it. So keeping it close to the DOM seems to be reasonable
Given that they promise pixel-perfect cross-platform control, I don't see how it's reasonable for them to use DOM elements. Unless they have an embedded browser in all the other platforms, and even then I doubt they'd get to pixel-perfect control.
Everything else aside, as a frontend developer I picked up C# and XAML to build a Windows application and while I really enjoyed C# (so familiar to Typescript, funny that), I was really disapointed by XAML.
At first XAML feels really nice because you've got the nice GridView and other UI components, but the moment you want to start customising these everything falls down. I was really disapointed by it's lack of more flexible layout semantics (like flexbox or display: grid), and instead offloading that all into writing custom C# code to lay things out at pixel locations.
What was just a single line in css - grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)) - ended up being many lines of custom layout code to achieve something much less performant.
I find the codegen/bindings situation to be really weird and XAML as well. Making custom XAML components/reusing code is trickier than it should be. React really got it right with JSX being just a thin layer of syntactic sugar on regular JS (I'm unsure how this would work for a static language like C#)
The inconsistency of the web platform is a nightmare compared to my pain-free experience with XAML.
XAML and C# allows a single developer to get a functional modern application going quickly.
I had zero problems with extensibility as long as I followed the patterns. Using MVVM, convertors, triggers, events, and behaviors where needed. The Blend tool is ridiculously cool, but I'm not artistic enough to make great use of it. But it reminds me of how Flash made me feel early on. As a kid I could make cartoons without issue in Flash.
Almost everything is open source or has an open source replacement available.
Making new UserControls is trivial. Much easier than any Web Components nonsense.
idk, maybe its just because I'm so inexperienced and I was learning this as I go, but it all seemed great to begin with, but quickly fell out once i got into the reality of actually developing and designing.
I still don't know how you're supposed to properly update data for a grouped List/GridView without causing the entire view to rerender. I'm so used to React's functional approach to building UIs that mutating collections seemed extremley alien and cumbersome to me.
I still never found a good way to achieve this a in in XAML, a grid layout where the cells will expand to fill remaining space on the row, and then wrap. Multiple components got kind of close, but always lacked 1 aspect https://codepen.io/joshhunt/full/qBOdYjj
> how you're supposed to properly update data for a grouped List/GridView without causing the entire view to rerender
By telling your views what was updated.
For updating sets of items, see INotifyCollectionChanged interface, implemented by ObservableCollection<T> from the framework.
For updating properties, see INotifyPropertyChanged.
> Multiple components got kind of close, but always lacked 1 aspect
Find a panel that does it best, then either copy-paste and patch, or inherit and override.
The entire layout model is implemented in just 2 methods, MeasureOverride and ArrangeOverride. They are virtual, i.e. designed to be user-replaceable as you inherit from framework classes.
The original complaint was mostly around layout patterns. I'm not super familiar with XAML, but "offloading that all into writing custom C# code to lay things out at pixel locations" certainly doesn't sound like a great dev experience, and definitely doesn't sound very responsive. Does XAML have anything comparable to flexbox/grid for building responsive layouts?
> Does XAML have anything comparable to flexbox/grid
WrapPanel
> for building responsive layouts?
There're two kinds of them. On the web it means arranging stuff to only have vertical scrolling but not horizontal. On desktop you often don't want any scrolling, no amount of auto-wrapping is going to do that regardless on the GUI framework.
Consider using straight up Blazor which lets you take advantage of HTML/CSS but use C# in the browser.
I find Blazor to be incredibly productive. I built a rough[1] implementation of the board game “Aquire” to play with friends in about 3 weeks of part time development in the evenings using Blazor and am sold on its potential.
[1] http://acquiregame.azurewebsites.net/
I still wear scars from a XAML on Windows Phone project (which was a weirdly disfunctional subset of the "real" XAML). I've programmed a lot of weird things in my life, but that one takes a lot of cakes..
One of the best cross-platform open source projects I've seen so far is https://makepad.nl.
- wasm source takes around 2 MB
- loads up quickly and it is fast even in mobile browsers
- great codebase!
- compiles in under a minute (41s on my laptop) inspite being written in Rust
Still needs a lot of work to be usable:
- missing UI features like proper layouting, configurability etc.
- imo font rendering still needs a lot of work; but there are already project in rust which do font rendering right, for instance: (git clone github.com/linebender/druid && cd druid && cargo run --release --example=text)
- no animated transitions of UI components
Makepad doesn't strive to be UI toolkit, but judging by the way it works already and dedication of the founders it looks really promising.
I'm working with a team that makes a web based word-processor (google docs alternative) [1]. One of my long term goal is to rewrite the document rendering code in a stack that allows me to render for multiple platforms (android, iOS, MacOS, Windows, Linux) using a single codebase.
Right now I'm studying how Flutter has achieved this using Skia. I'm also following JetBrains Compose, but as of the moment it only seems to support desktop native apps. How is this one different from Flutter/JetBrains Compose?
Microsoft has been porting React Native to Windows and macOS, so it can cover all of your required platforms, except linux. Hopefully a complete RN for gtk/qt happens soon.
The value proposition for winforms and WPF for me is that they have been around forever and will continue to be around forever.
Under normal circumstances I dismiss any new Microsoft UI framework like uwp or winui3 out of hand because I know in two years or so, some other product manager will take over and will need to make their own stamp on the organization, so they will introduce yet another UI framework and Winui3 will be stagnated just like silverlight was.
I use F# Fable right now for web applications with intentions to learn Avalonia and eventually trim down my use of good old winforms when I'm writing desktop only applications.
Having said all that, I do like the idea of being able to write code in one code base and have it be compiled via xamarin to other runtimes.
Does this platform deliver on that promise?
Is anyone who has a few battle scars using this tool able to give a small review?
> Under normal circumstances I dismiss any new Microsoft UI framework like uwp or winui3 out of hand because [...]
You do realize that the 3 implies it is the 3rd version of a project? WinUI 3 is just the "third version" of the UI component library used inside UWP originally, but now with bonus compatibility with WinForms and WPF.
To me that's the opposite of "stagnated" or "deprecated every two years". The UI parts of UWP and WinUI3 are more the same thing, just versions over time, than they are different. It just continues to evolve with each new versions that include new features (such as the new "Now with much better WPF and WinForms support" features for people in brownfield applications).
You should be excited about WinUI3 because it lets you dip your toes in what UWP added to the UI framework from your WinForms and WPF development. You'll probably find it feels a lot more like WPF than you'd think given how demonized UWP's UI framework has been. (It's not WPF, of course, and there are compatibility breaks to learn/deal with, but it's still XAML-based UI design with a lot of very similar controls and tools in the toolkits.)
When I started at my current C# job in 2009, I decided to choose (being the sole dev) WPF for the UI because it was the future. The future is now, I'm still coding in WPF!
Uno is a really interesting approach to writing cross-platform UIs. It's interesting that they basically have a native implementation of say Button for every platform.
This might lead to a unified style across platforms but as it does not use the same rendering logic/code on every platform I'd doubt that it's pixel perfect. Building a text editor would probably expose a lot of these close but not similar scenarios.
On the other hand this adds the benefit of getting native behaviour of text boxes maybe ?
Avalonia on the other hand does custom rendering using Skia and therefore really has pixel perfect rendering across platforms. This also means that it does not use the native controls and behaviour differs.
If I had to write a cross platform app (and had the budget) I would probably use Xamarin and just write platform specific UIs. If there are heavy UI components these could still be shared.
If on a budget something like this seems fine. Would probably go with avalonia UI tho tbh.
- Uno uses the UWP API and XAML, whereas Avalonia uses a derivative of WPF
- Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think)
- Uno is based on WinUI, so in theory WinUI components should be usable in Uno apps
- Uno supports WebAssembly, but not Linux and MacOS natively
> - Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think)
This line remembers a constant pitch i see here on HN, where people ask for native controls to be rendered for multi-platform UI sdk's that i think go on the "faster horse"(Ford) sort of misdirection.
The problem with the 'faster horse' paradox is that the only way to make people forget about wanting a faster horse is by showing them the car.
I think a platform like Flutter get this right, as do HTML/CSS/JS, because theres no way to get really consistent if you have to use the platform native controls. It will also be messy for the developers, requiring a lot of effort and money to make things partially right.
I bet with you that most of these people asking for this use a Mac, and while Apple is more or less half of the market of US, in the rest of the world Apple have much smaller deploy base.
So sometimes, you need to be careful because even HN can suffer from a bubble social effect, that will misguide people that actually listen what they are asking for.
In the long term there's already a multi-platform UI paradigm there is set to win, and its called HTML..
Native UI platforms had a sort of comeback because of the iphone revolution, but in the long term, they will not be the winners, because Apple is doing the same mistakes they did in the eighties.
The only cross platform frameworks that provide excellent experience are HTML and JS.
All those cross-platform app frameworks fail at the same point: Meeting the user expectations since they are different on different platforms. It always feels off if the platform specific experience is not fine tuned to the platform and at that point why just don't go native and have all the shiny things that the platform has to offer.
HTML is not a UI platform. It is a language that provides structure and meaning to otherwise static content.
The web browser is the equivalent of a WinForms or WPF application that interprets the HTML content and turns it into a visual presentation. CSS and JavaScript basically came along to help web browsers better present HTML content in fancier ways. But at the end of the day, it isn't a framework and HTML is still just structured content, if not bastardized to force a certain UI presentation.
You can't have fancy web applications without a web browser, just like you can't have a native desktop application without a GUI chrome framework. When you speak to the overall footprint of a web application, the web browser and the functionality it provides has to be taken into consideration, when comparing to native desktop applications.
It really comes down to the classic client/server problem - How much functionality is the client going to handle vs. the server? There is always going to be a compromise of size/complexity/performance when off-loading to the client, among other concerns. It really doesn't matter what the client technology is, Flash, SilverLight, WebAssembly, Java, etc., they all will run into that same basic structural design issue.
Well, you have a web browser that runs JS everywhere and it happens that the browser handles the platform specific parts very well so every experience on the browser + HTML + JS feels native. It only fails if you try to be clever and do things like scrolljacking.
Awesome. Now show me an Antivirus that will have Firewall / Live scanning / Live protection that is made using HTML and JS. Or you make one using HTML and JS.
I hate Java. I really do. But when it comes to absolute same experience on cross-platform is the only programming language so far. None else is in the same league as Java. A distant second would be Free Pascal/Lazarus but their richness of libraries is like 10% of Java's. And please do not come with Xamarin, that monstrosity must be killed.
I kinda like Xamarin and use it mainly to create internal business apps for multiple platforms. I also write a lot of native code for iOS and Android and feel comfortable writing Objective-C, Swift, Java and C#.
In case of Android-only I would actually rather use C# and Xamarin than Java.
Why do you feel Xamarin is a monstrosity that must be killed?
Because is MFC, another monstrosity that thank God it died, under a different hat. Microsoft are just re-polishing their old way, nothing remotely innovative there.
> I hate Java. I really do. But when it comes to absolute same experience on cross-platform is the only programming language so far.
The problem is that if we're talking about UIs, then Java is only cross-platform for the platforms you care about.
From a UI perspective, JRandom app using Swing won't work as expected on an Android phone. That's not "absolute same experience on cross-platform". That's instead a portability problem that you must solve explicitly by adapting your codebase to support two different UI frameworks or planning ahead for every possible porting target.
If Java was the end all be all, people wouldn't keep trying to create cross-platform UI frameworks. The truth is Java never lived up to it's hype, Flash ate its lunch when it came to browser-launched applications, and given Oracle's licensing and policies towards Java, no IP is truly safe that is built-upon its technology. If your app got popular enough, a greedy Oracle will come after you, i.e. Android.
I don't think you can make an antivirus, firewall or similar with an UI framework anyway so you will have to go native regardless. Just stick to a native UI framework of your choice.
You're missing my point. You can have both full cross-platform AND native with Free Pascal/Lazarus. And making an AV is within its reach, technologically speaking.
The fact that they can’t get macOS’s logo right on their homepage is not very reassuring on the pixel perfect/attention to detail aspect the product tries to sell.
Pro: As someone who's used C# for almost 19 years, this is a holy grail. I've always found in-browser development far behind native desktop / mobile development.
Con: The calculator demo takes waaaaaay too long to load. The long load time might be acceptable for a very rich web application.
So, it gets stressed that this doesn't have a dependency on xamarin.Forms. Ok, but what's the advantage of this versus using the UI building capabilities included in .NET 5 directly?
To paraphrase - what's the selling point of using Uno vs using .NET 5 and .NET MAUI (the successor of Xamarin.Forms) directly?
> WinUI being the UI platform that Microsoft seems to be pushing on windows these days.
WinUI doesn't sit well with me - it has the same problem that all the other "user-mode" UI frameworks have: it isn't a system-service, so once your app ships it's frozen in time and won't benefit from new features added to native widgets and controls (e.g. if you run a well-designed MFC EXE last compiled for Windows 2000 - but tweak the embedded manifest resource file to load the updated CommonControls and Windows 10 compatibility - it will still look good today and fit-in with an MFC program created new last week (I note it will look "good" - not "amazing" - because Microsoft decided to take Windows 10's native widgets downmarket since Windows 8, ugh...).
Could be worse - at least it's not Java AWT or Swing. What on earth was Sun thinking when they designed that?
> Give me raw Win32 over Xlib/Athena/Motif any day of the week.
I share your sentimental attitude, but looking at the past 10+ years of "post-native" desktop UI development being done in Electron, at al, it really does look like the days of platform-specific proprietary UI frameworks and toolkits are coming to an end. Modern HTML+CSS is a far more expressive medium for usable application UI layouts. Trying to build a "responsive" UI in VB6 is essentially impossible, for example. Even from a user's perspective I'm glad that fixed-size, DPI-unaware dialogs are done-away with.
I can't complain that much though - I don't miss writing low-level Win32 message-pumps - nor being limited by GDI's horribly outdated nature (fun-fact: it's impossible to build applications that support 10-bit color with GDI despite GDI's built-in support for different bpp values, because GDI assumed 24bpp / 8bpc was enough for anyone forever).
There's now only a few things missing from HTML+CSS that would enable true native-like applications: borderless sub-windows (think: for context-menus that can extend beyond the parent web-browser's client area on your desktop) and native macOS main-menu support (which feels like an anachronism given the large mouse-movements needed with today's humongous desktop display sizes).
If you look for it, there is plenty of work to be found doing native GUI programming.
I have spent 2014 - 2018 doing Forms/WPF GUIs for life sciences labs, and at least for those customers I can assure they aren't going to switch to Electron, more likely Qt or WinUI when time comes.
You've betrayed your own point by admitting that though: WinForms and WPF aren't native - (well, WinForms is a a thin abstraction layer, but still not truly native). If you're using WPF today you can probably switch to Electron without your users noticing anything (besides a 10x increase in memory usage...)
> you can probably switch to Electron without your users noticing anything
GPU support is not good enough in the browsers. Even 12 years old Direct3D 11.0 is way better than the current WebGL.
In WPF, it’s relatively easy to render a dynamic texture with Direct3D 11 or 12, then pass it to WPF to compose it into the GUI, without ever downloading pixels from VRAM.
Similar for compute shaders. You don’t need WPF to integrate DirectCompute, but you do need convenient native interop. These C structures, typed arrays and unmanaged pointers are all over the API surface. Not sure JavaScript is good enough for the job, the language and VM were designed for very different requirements.
> If you're using WPF today you can probably switch to Electron without your users noticing anything
A WPF app will load much faster and feel more integrated (more Windows like) than an electron app.
I have a C# / WPF app that I optimized to the best of my capacity but that still needs about 1 minute to compute data. I shudder to think how long JS would take to do the same job.
People complained that UWP was too tied to Windows Updates and control updates required major Windows Updates (and who has time to wait for corporate to deploy this year's Windows version?). So Microsoft addressed that by lifting and shifting most of UWP's UI framework out of the OS updates cycle into WinUI 3. It's almost funny to see complaints come full circle back to things should be OS managed and not in a developer cycled framework.
They were looking at the dominate platform at the time for corporate dev...visual basic. Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing.
> Not really sure why there was so much hate on swing, probably from the people who never used it. No performance issues, looked good enough for users, theme able. I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native. AWT was slow and ugly but not swing.
Let's unpack this...
> Not really sure why there was so much hate on swing
Swing itself isn't bad (compared to its predecessor in AWT) but Swing is still an abstraction over multiple different and incompatible desktop UI toolkits - therefore it has to compromise.
> probably from the people who never used it
Used it as an end-user, or used it as an applications developer, though?
The last time I used Swing was around 2010 - and I admit that I haven't stayed on-top of new developments, but I assume that Sun/Oracle switched emphasis away from Swing over to JavaFX (their WPF-compete) and that Swing hasn't changed much (at a fundamental level) much. Please correct me if I'm wrong.
> No performance issues
Yes-and-no. Things like repainting a busy charting component is fast enough, sure - but one thing about Swing that sticks out like a sore thumb is abysmally slow window repainting when a window is resized - I first noticed this when I was a lame warez kiddie using Limewire almost 20 years ago (wow...): actively resizing the Limewire window would cause the JVM to pause repainting the window and just draw a black background color until a few hundred milliseconds after I finished resizing. I've noticed similar behaviour in other Swing applications. It isn't pretty. Especially on macOS where users expect to be able to smoothly resize application windows.
> looked good enough
"good enough" is not exactly the best review in the world
> themeable
Yes, but who honestly goes through the effort to make an entire theme just for their own application? That's only affordable if you're a software giant or a company whose brand identity is heavily based on their software UX (and if that was the case, they wouldn't be using Java for desktop applications).
> I actually built apps that when compared with other native themed apps would not have been distinguishable from windows native
This may have been true in the final months of Windows 98/Me and Windows 2000, but Swing's inability to correctly reimplement (or even wrap) Windows XP's visual styles (especially the animated controls and when running outside of 96dpi mode) was exactly what gave Swing that uncanny-valley feeling (granted - and hypocritically - Microsoft's own WPF is also guilty of this, which is why I avoided it entirely until recently).
Ok. I think I'd rather go for .NET MAUI when it comes out, as native has a better look and feel pretty much always. Apparently though .NET MAUI is set for .NET 6 which doesn't have a release schedule. So there's that.
I haven't used Xamarin.Forms, what's the problem with it?
We've been using Xamarin Forms on the (UWP) desktop for a few years now. It's pretty great. There are bugs yes, but so do all these magic cross-platform UI frameworks. They're investing heavily into MAUI to fix a lot of these things.
Great has not been my experience with forms UWP. Lots and lots of bugs in the UWP components forces you to abandon most of the things you need to make a nice iOS/Android UI.
Unless you’re prototyping or really don’t care at all about UX I don’t see why you wouldn’t write the UI in the native framework. And if you don’t care at all about UX then HTML+CSS+JS is probably a better choice.
We've been working on our Xamarin Forms based product since the first beta in 2014. We released to Android first. Then in 2018 we built a UWP variant of our app. This process barely took a week if I don't include the technical debt that took an extra week to sort out. Then in 2019 we built an iOS variant of our app too - again barely taking a week to do so.
Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order.
I don't know of any other platform that could do this - particularly when considering the years involved.
Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.
In general the main benefit of Uno is that you use UWP XAML rather than some cross-platform first flavor of XAML. If you lurk in github issues for these platforms (MAUI / Xamarin Forms) you will see this as a common complaint/ask.
Has anyone tried this and able to share their experience? I tried to run the Windows Calculator example on macOS, and while it looked alright, the performance wasn’t so smooth.
- It needed to show a loading spinner on a 250 Mbit connection
- It hung the browser while 'booting' the page for a solid 3-5 seconds
- It downloaded 4.39 MB in 50 requests
- Opening web inspector in Firefox while reloading the page was sufficient to cause the boot process to hang indefinitely
- Page looks pretty, but at this point it barely matters
We could conclude either that the project's attention to important details is low, producing this experience, in which case what else might we discover once committed, or alternatively we could conclude that it is high, in which case, this is the best possible experience for any Uno app.
I read your comment and thought it couldn't be that bad and those metrics are not necessarily representative. Then I tried it on FF and Chrome on a 4770k and a GTX 1060. I simply tried switching on the vertical tabs. I got a 0.2-0.5 seconds latency from click to feedback on the screen (and longer for the page to fully load!).
Marketed as a single codebase platform where the most ubiquitous deployment target has a user experience that tells your customers you hate them
4.39 MB in 50 requests is a showstopper on any mobile network, especially when alternative solutions do not have that problem. It is fair to assume some first time experiences will involve 7.5 seconds or more additional latency on 3G networks, double that for a poor signal areas.
I'm in complete agreement that 4.39MB in any number of requests is too much, but I've got bad news for you about the average webpage: It's that or worse, and you pay a similar cost every time you navigate to a new page on the same site. At least for a webapp you pay that cost once and then can navigate freely within it.
Devrel people from the Chrome team have been beating the drum on this for ages - large web content excludes huge chunks of the world from being able to use stuff, no matter what toolchain it's built with. All these huge frameworks and ad networks and in-page video ads eat up so much bandwidth...
The average web page can be as nasty as it likes, but if I can deliver apps that _feel_ awesome and optionally can deliver metrics that provide a commercial basis for that awesomeness to whoever is paying me, I don't really care much about the average web page at all. Insert some truism here about using the incompetence of others to justify one's own slovenly behaviour, and some other truism about standing out from the crowd by applying common sense.
"I built an average web application and it attracted an average number of users, it more or less worked if you visited it from mobile" would look fucking awful on anyone's resume.
I bet the average medium blog loads more than that.
That others are just as wasteful is immaterial; the fact that it's multiplied by every single user makes it downright hostile to everyone except those who are profiting from bandwidth use.
Every single "cross-platform solution" I've seen is basically a sub-optimal experience on every platform. Personally, I'd rather have fewer native applications than the wave of quantity-over-quality not-quite-right-anywhere that stuff like this tends to encourage.
In all endeavours where pixel-perfectness was pursued, it ended in tears for everyone involved. UXers because they could not get what they want and if they got what they envisioned, it still was not what they want as they learned about subpixel-perfectness. For programmers as it was chasing a unicorn. For the business because it is an expensive exercise gaining limited value.
Every time I see pixel-perfectness claimed I immediately approach it with a lot of caution.
This sort of approach just seems too compromised. I really like the Kotlin Multiplatform approach, where a shared core of business logic can be imported into platform-specific code. Then you get all the features you'd like (e.g. iOS 14's new App Clips) with no leaky abstraction layer getting in the way of them or causing per-platform bugs.
Agreed - there's been too many of this "write once, run everywhere" stuff going on and it always disappoints on user experience and performance. On top of that, native features vanish.
I've been out of the smartphone app for a while (was there in the Symbian / J2ME days and in the early iPhone days though) but...
I take it it's now legal according to Apple's term? Because IIRC there used to be (and maybe still is, but it doesn't look like it) an issue regarding generated code / automated porting tools for iOS? I think I remember it was a concern for people making tools allowing to do automated cross-platform porting to a variety of platform.
If anyone knows/remember what I'm talking about and where the situation's at atm, don't hesitate to chime in and tell me when things changed or what I remember wrong.
Well if it's drawing every pixel or using 2D primitives that sounds much more like Flutter than React Native since Flutter also uses Skia while React Native uses platform widgets.
I brought up web accessibility concerns with them almost a year ago and as far as I can tell all they've done since then is add `tab-index` attributes. Probably best to avoid this until they improve it more.
Did this project previously go by a different name? Maybe I'm misremembering but I could swear I saw something like this posted a few years back, the Calculator demo in particular.
Why is this better than Flutter? Flutter is currently amazing, fast, fun to use and a beautiful design.
I consider React Native a dead man walking, Flutter kicks its ass in almost all aspects.
I just hope they manage to make Flutter also viable for web, improve its perfomance, I honestly believe it is going to change the landscape in the startup world..
At this point, it's impossible to get a single code-base for all types of platforms. I have settled on using electron for desktop applications and using react native + (swift, kotlin for specific features) for mobile.
Also I would like to avoid using anything Microsoft, if I can avoid it.
CLR is fast and efficient. C# is an open standard. It's not worse than Java at all, and JVM is also extremely fast and efficient (some Java apps are not, of course). Java- and C#-based GUIs are generally better than Electron-based GUIs, and even with Electron you can find performant, complex GUI apps (VSC as an example).
I have soft (web app) written in C# that's been running on Linux since 2018 (with many patches between) and everything works fine.
The only thing I had to do was installing some fonts in order to make pdf generator works.
Mem usage is generally between 100-300MB for I'd say 98% of the time (sometimes somebody wants to generate not-small Excel files and it spikes). Of course it says nothing because you don't know what the app does, but it's just some reference point.
I use Chrome in `--app` mode to render UI and combine with a Node.JS server and package with nexe and upx to make a cross-platform desktop app. The memory performance is around 200 MB (~150 Mb for the Chrome and 50 Mb for the Node.JS service). It takes about 4 seconds to launch (but about 30 seconds on Windows the first time, I think due to security checks, AV, etc...). The GUI is written in HTML, but it doesn't use Electron.
You can try it out here[0], too. I open sourced it.
And "hello world" binary download size is 10 Mb for Windows.
I can understand what you mean by cpu/mem bloat (I'll add to that install size, assuming this packages things up with all dependencies), but what do the other things mean?
For "usage", mono being like a kind of jvm, you will have a lot of "desktop graphical" or integration issues.
I can't swear that it will really be the case, but here are some examples of kind of thing that I expect:
- Icons, window decoration, style, not matching the system.
- Copy paste issues, for example the middle click not working.
For "dependencies", not considering the real dependencies, you will have to force your user to install mono and its own dependencies. As the application will run on this, in a similar way that you would have to install a JVM + classpath for Java apps. And this one is really fat an ugly.
For "cpu bloat", even if JIT can be more efficient on the long run, there is usually a higher cost at startup. For GUI application that you start often, like a calculator, that could be annoying.
For "ethics", the code will have to run on the mono(ie .net) kind of jvm and so you are dependent of this engine to run your code. And this engine, even if mono is the open source one, is controlled by Microsoft.
They control the language, they control the features, and it is not the spirit that built the linux community to rely on "base components" controlled by Microsoft.
It is a little bit like the control that Oracle has on Java even if not completely similar.
https://uado.platform.uno/
...loads 8.1 MBytes compressed (32 MBytes uncompressed) until the login button appears.
This simple calculator:
https://calculator.platform.uno/
...10.1 MBytes compressed, 53.8 MBytes uncompressed. Needs a splashscreen and 10 seconds to start (on a 50 MBit connection)
It's one thing to "simply" port some cross-platform-code to WASM and make it run in the browser, but making it a proper web application takes some actual effort. I feel that "efforts" like this just give WASM a bad reputation. Sorry to be blunt.