...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.
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.
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.
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.
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.
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.
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.
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 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
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?
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.
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?
> 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.
Readit News
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.
1: https://github.com/dotnet/runtimelab/
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.)
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.
Fair comment.
Here are some other live Wasm apps examples: https://github.com/unoplatform/uno#live-webassembly-apps.
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.
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.
source: been involved in quick and dirty UIs in a business for the past decade
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.
I don't think this is intended for public facing, low bandwidth/mobile websites.
https://floooh.github.io/sokol-html5/
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.
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.
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.
0 - https://webassembly.github.io/spec/core/exec/instructions.ht...
1 - https://github.com/golang/go/issues/26622
2 - https://github.com/cretz/go-wasm-bake
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.
So it's no better than Electron? I'm primarily interested in the cross-platform desktop part.
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.
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.
Consider yourself lucky. It doesn't do anything on my machine except show the splash screen.
macOS 10.15.6 / Safari 14.0
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).
For the iPad, the iOS built version of the same app works lots better (https://apps.apple.com/us/app/uno-calculator/id1464736591).
Accessibility is high on our feature list; we have added aria base support in recent builds of Uno, which the calculator will start using soon (the iOS https://apps.apple.com/us/app/uno-calculator/id1464736591 and Android https://play.google.com/store/apps/details?id=uno.platform.c...) versions of the same app are screen-reader enabled). The Linux one (Snap https://snapcraft.io/uno-calculator, AppImage https://github.com/unoplatform/calculator/releases/tag/1.2.4...) is not yet enabled, but will also be.
The WinUI framework provides great accessibility support, and we intend to port it fully in the coming months.
If anyone else is interested, I found the relevant GitHub issue: https://github.com/unoplatform/uno/issues/1141
e.g.
https://blah.com/dashboard (web assembly) (not indexable)
https://blah.com/dashboard.data (common format for representing data) (what the DOM currently tries to do)
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.
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
[1]: https://developers.google.com/search/docs/guides/intro-struc...
[2]: https://json-ld.org
Dead Comment
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.
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
If I wanted to make a website, I'm more than confident and productive with HTML/CSS/JS/React to build out what i need.
- 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.
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?
[1] https://writer.zoho.com
Deleted Comment
Dead Comment
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?
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.)
Checking on wikipedia shows that winforms was introduced in 2002 and wpf in 2006. This makes me feel very old.
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
Links:
- https://github.com/unoplatform/uno/issues/17
- https://github.com/AvaloniaUI/Avalonia/issues/587
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.
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.
Flutter is the platform that provides excellent experience here... Not on web yet, but its coming close.
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.
If you're building the GUI for some local tool TCL/TK is a lot better IMO.
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.
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?
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.