Uno: Single-Codebase for Windows, WebAssembly, iOS, macOS, Android and Linux(platform.uno)
platform.uno
Uno: Single-Codebase for Windows, WebAssembly, iOS, macOS, Android and Linux
https://platform.uno/
204 comments
that calculator took 35 seconds to load on my ipad pro... not a great first impression (and the ui lag was quite noticable as well)
- Uno dev here
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).
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).
i see, thanks for the pointers, i guess apple doesnt have much incentive to speed up web assembly...
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...
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.
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.
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.
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.
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.
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.
Unity has supported the .Net Framework (using .Net 4x) for several years...
However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific.
https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetP...
However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific.
https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetP...
Unity uses normal C#. They switched to using the Rosyln compiler several years ago. https://yadiyasheng.medium.com/confusing-threesome-in-unity-...
They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.
They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.
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.
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.
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.
- Uno dev here
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.
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.
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.
I guess we'll just have to wait for WASM binaries to support dynamic linking, at which point we'll get services like "cdnwasm" or "wasmdelivr".
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.
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.
because web tech isn't really the best solution for quick and dirty UIs.
source: been involved in quick and dirty UIs in a business for the past decade
source: been involved in quick and dirty UIs in a business for the past decade
So what has that decade taught you is the best solution for quick and dirty UIs?
VisualBasic, back in the day.
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.
WASM (language independence) on electron (fixed, controlled browser version) with delphi-like UI designer could work, maybe.
PowerBuilder, in the EMR industry.
HyperCard.
Beeware!
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.
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'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.
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
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
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.
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.
1: https://github.com/dotnet/runtimelab/
1: https://github.com/dotnet/runtimelab/
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.)
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.
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.
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.
I really hope that they actually deliver proper AOT, specially now with the uncertain future for .NET Native.
Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.
Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.
It is planned to merge CoreCLR into .NET 6.0.
- Uno dev here
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.
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.
I'd guess you'll be shipping precompiled essential .NET assemblies with Edge?
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.
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.
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.)
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.)
>language-agnostic wasm standard lib
Can such a thing even exist?
I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
Can such a thing even exist?
I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
> Can such a thing even exist?
Yes, cross-language code sharing is being worked on.
> I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
How would a site know what libraries are available? How would versioning work?
This is a caching problem, best solved at the normal browser resource cache level IMO.
Yes, cross-language code sharing is being worked on.
> I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
How would a site know what libraries are available? How would versioning work?
This is a caching problem, best solved at the normal browser resource cache level IMO.
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.
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é.
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.
I don't think this is intended for public facing, low bandwidth/mobile websites.
I think there's still a lot of room for improvement ;) For instance when you look at these demos:
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.
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.
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) )
(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....
uado isn't quite "pixel-perfect" on Firefox (82.0.2, Mac): https://i.imgur.com/EYFzTv3.png
seems fixed now!
It's a known bug with the caching of fonts. If you clear all your browser cache and restart it again, you'll see it once again.
This simple calculator... Needs a splashscreen and 10 seconds to start (on a 50 MBit connection)
Consider yourself lucky. It doesn't do anything on my machine except show the splash screen.
macOS 10.15.6 / Safari 14.0
Consider yourself lucky. It doesn't do anything on my machine except show the splash screen.
macOS 10.15.6 / Safari 14.0
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.
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.
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.
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.
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.
[deleted]
> This simple calculator … 53.8 MBytes uncompressed.
So it's no better than Electron? I'm primarily interested in the cross-platform desktop part.
So it's no better than Electron? I'm primarily interested in the cross-platform desktop part.
I understand this is th web version. If you build native, it is going to be smaller and faster.
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?
Is this a direct competitor to Flutter?
"It will use either the underlying platform 2D primitives to render same UI everywhere or use Skia to draw every pixel."
Sounds more like a React-Native competitor to me.
Sounds more like a React-Native competitor to me.
Seems like it. I do like flutters "widget composability" design better, and native support for animations...
And the components in flutter are of very high quality. Pixel perfect copies of ios and material design.
And the components in flutter are of very high quality. Pixel perfect copies of ios and material design.
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.
The gallery app looks to be authored using it:
- 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.
Instant pass
- 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.
Instant pass
That's for webassembly. None of that matters for most applications on the other platforms it targets.
And even for webassembly, 4.39 MB is not prohibitive for some use cases. Specially with caching. I bet the average medium blog loads more than that.
I wouldn't be so quick on dismissing a solution.
And even for webassembly, 4.39 MB is not prohibitive for some use cases. Specially with caching. I bet the average medium blog loads more than that.
I wouldn't be so quick on dismissing a solution.
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.
It's still an instant pass
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.
It's still an instant pass
Implying the solution requires 50 requests by looking at the gallery is rather uncharitable.
Half of the requests are unrelated js/css/images that could be combined into smaller and fewer requests.
As for the other half of files, most are .clr.
I'm not privy on the details of this solution but most webassembly demos I've seen combined all files into one single wasm file.
Half of the requests are unrelated js/css/images that could be combined into smaller and fewer requests.
As for the other half of files, most are .clr.
I'm not privy on the details of this solution but most webassembly demos I've seen combined all files into one single wasm file.
Effectively this is arguing for the project's attention to detail being low, we covered this already
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...
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 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.
They published their demo calculator app on the Play Store: https://play.google.com/store/apps/details?id=uno.platform.c...
All the top reviews are talking about how slow it is. A calculator app.
All the top reviews are talking about how slow it is. A calculator app.
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.
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.
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!).
Sorry to any dev at Uno, but that's terrible.
Sorry to any dev at Uno, but that's terrible.
The moment you claimed to make a software for Linux by using c#/.net/mono, you failed!
Usage, cpu/mem bloat, dependencies, ethic, will all be all wrong...
Usage, cpu/mem bloat, dependencies, ethic, will all be all wrong...
Is it really that worse than Java / Electron?
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.
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.
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).
Sure, if you compare to Java or Electron, it is not necessarily worse.
But these 2 solutions for GUI are not prime candidates for users on Linux.
Compared to a c#/mono app, Electron can be relatively light in term of dependencies to run.
And as you can easily notice, very very few "java" GUI applications are successful on Linux computers.
Users would use a java application only when there is really no other program available for a purpose.
But these 2 solutions for GUI are not prime candidates for users on Linux.
Compared to a c#/mono app, Electron can be relatively light in term of dependencies to run.
And as you can easily notice, very very few "java" GUI applications are successful on Linux computers.
Users would use a java application only when there is really no other program available for a purpose.
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.
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.
[0]: https://github.com/c9fe/graderjs
You can try it out here[0], too. I open sourced it.
And "hello world" binary download size is 10 Mb for Windows.
[0]: https://github.com/c9fe/graderjs
I was about to suggest that we've been here before with the likes of Xamarin, but then I read: https://platform.uno/how-it-works/
It appears to be built on Xamarin.
What we have here is cross-platform for .NET developers.
It appears to be built on Xamarin.
What we have here is cross-platform for .NET developers.
Let me guess... it Electron but in C#?
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 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?
> The value proposition for winforms and WPF for me is that they have been around forever and will continue to be around forever.
Checking on wikipedia shows that winforms was introduced in 2002 and wpf in 2006. This makes me feel very old.
Checking on wikipedia shows that winforms was introduced in 2002 and wpf in 2006. This makes me feel very old.
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!
> 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.)
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.)
It is version 3 and I still prefer WPF. WPF is a masterpiece. It is a shame it is essentially abandoned.
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?
To paraphrase - what's the selling point of using Uno vs using .NET 5 and .NET MAUI (the successor of Xamarin.Forms) directly?
From just glancing at it, it looks like this is targeted at developers creating WinUI applications and turning those into cross platform applications.
WinUI being the UI platform that Microsoft seems to be pushing on windows these days.
WinUI being the UI platform that Microsoft seems to be pushing on windows these days.
> 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?
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?
Basically outside NeWS and NeXTSTEP, most UNIX companies were hardly known for actually being able to design proper GUI frameworks.
Give me raw Win32 over Xlib/Athena/Motif any day of the week.
Give me raw Win32 over Xlib/Athena/Motif any day of the week.
> 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).
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.
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...)
They are native UIs of the Windows platform, built on top of Win32, GDI+ and DirectX.
There is so much that the Web still fails short of WPF.
There is so much that the Web still fails short of WPF.
> 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.
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.
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.
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).
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).
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.
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?
I haven't used Xamarin.Forms, what's the problem with it?
Xamarin.Forms apparently has some stability issues on the Mac.
In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
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.
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.
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.
.Net has yearly release schedule, so 6 will be in Nov 2021.
https://devblogs.microsoft.com/dotnet/net-core-releases-and-...
https://devblogs.microsoft.com/dotnet/net-core-releases-and-...
Is there a guarantee that this is not going to share the fate of WPF?
Like still being maintained and supported on latest Windows and .NET versions?
The problem is they never truly iterated on the product. There are a hundred ways you could simplify and improve WPF.
Feel like contributing? https://github.com/dotnet/wpf
No thanks, it's been dead for a while.
There are updates to WPF (and WinForms) in .NET Core 5. It's probably more accurately "undead" than "dead".
On the contrary, plenty of gigs available in Europe and it is still being updated.
Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.
Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.
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.
The dark mode brings black text on almost black background when using Fluent. No, thanks.
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?
[1] https://writer.zoho.com
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]
Have you seen Juce? https://juce.com
Technically Qt can with WebAssembly. It renders the application to a canvas element.
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 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.
In addition, the logos are blurry because apparently they couldn't be bothered to support "retina" displays. Sloppy.
The Windows logo is also off. The tops of the two upper trapezia do not line up.
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
I've been thinking for a while that the larger spidering community (google/bots) can just agree on a way to associate data with a url.
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.
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.
That's interesting you mention.
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
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
Sounds like we come from the same experience.
I think for anyone who wants to pioneer this idea, the costs will be noticeable, but that's what bandwagons and the youth are for =D
Ultimately I think there will be a reduction in costs (bits, process, maintenance)
To steal from React lingo, UI represented as state, that is more or less what any web page is.
Wrapping it in a meta layer like the DOM just adds overhead which I think can be optimized.
I'm undecided but still entertaining the idea.
I think for anyone who wants to pioneer this idea, the costs will be noticeable, but that's what bandwagons and the youth are for =D
Ultimately I think there will be a reduction in costs (bits, process, maintenance)
To steal from React lingo, UI represented as state, that is more or less what any web page is.
Wrapping it in a meta layer like the DOM just adds overhead which I think can be optimized.
I'm undecided but still entertaining the idea.
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.
Yeah I agree, don't doubt it will have problems.
Search engines have been dealing with black hat SEO for a while now. I'm a bit persuaded that Google knows whats up.
As in, I think it's just one of those inevitable technical challenges of castle defence.
Build better walls, they build better trebuchets, ad infinitum.
Search engines have been dealing with black hat SEO for a while now. I'm a bit persuaded that Google knows whats up.
As in, I think it's just one of those inevitable technical challenges of castle defence.
Build better walls, they build better trebuchets, ad infinitum.
- Uno dev here
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.
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.
Thanks for your response. It's great to hear you're improving accessibility - I look forward to trying it out when it's released
If anyone else is interested, I found the relevant GitHub issue: https://github.com/unoplatform/uno/issues/1141
If anyone else is interested, I found the relevant GitHub issue: https://github.com/unoplatform/uno/issues/1141
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.
This also looks very foreign on the mac.
Is this related to Uno[0] by Fuse Open, which is also a C#-thing for native app development?
[0] https://github.com/fuse-open/uno
[0] https://github.com/fuse-open/uno
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.
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 and JS is not an excellent experience on mobile. Its quite shitty if you compare them to native apps..
Flutter is the platform that provides excellent experience here... Not on web yet, but its coming close.
Flutter is the platform that provides excellent experience here... Not on web yet, but its coming close.
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 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?
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 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.
Sciter is commonly used for anti-virus programs (600 million PCs....)
https://www.kickstarter.com/projects/c-smile/open-source-sci... (check the logos)
https://news.ycombinator.com/item?id=23167751
https://www.kickstarter.com/projects/c-smile/open-source-sci... (check the logos)
https://news.ycombinator.com/item?id=23167751
That's the UI, not the engine itself. My point is to actually make the engine, i.e access files/network packets. I wanna see HTML/JS doing that.
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 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.
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.
Those are great if you're building the front end for a remote service.
If you're building the GUI for some local tool TCL/TK is a lot better IMO.
If you're building the GUI for some local tool TCL/TK is a lot better IMO.
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.
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.
It’s the ultimate cross platform UI framework.
It’s the ultimate cross platform UI framework.
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#)
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#)
Have the exact opposite experience.
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.
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
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.
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.
[deleted]
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.
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/
This was to make a widget - ghostoverlay.com - for the Xbox Game Bar on Windows, so I was specificlly targeting native platforms.
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.
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.
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..
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.
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.
Here are some differences I was able to find:
- 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
- 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
> - 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.
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.
pixelperfect, but not platform-perfect
Hmm last time i heard 'pixel perfect' I was interviewing for a job. Turned it down.
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.
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.
This is super slow on Firefox Android.
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.
Every time I see pixel-perfectness claimed I immediately approach it with a lot of caution.
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.
Con: The calculator demo takes waaaaaay too long to load. The long load time might be acceptable for a very rich web application.
Why not Flutter :)
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.
> Pixel Perfect Everywhere
Not to nitpick, but https://i.imgur.com/xzfrim8.png
Not to nitpick, but https://i.imgur.com/xzfrim8.png
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..
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..
Can you elaborate on "I consider React Native a dead man walking"?
It's a Flutter fanboys' bedtime story
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.
- 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 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.
Ignoring the web target, this looks amazing for mobile and desktop.
What's the business strategy here? Providing support and training?
What's the business strategy here? Providing support and training?
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.
Also I would like to avoid using anything Microsoft, if I can avoid it.
> The only open source-platform for creating true single-source, multi-platform applications.
What about Flutter?
What about Flutter?
I believe some environments are still beta. I have enjoyed flutter even with that limitation.
If this works with F#, It looks incredibly interesting.
P.S. I love the name.
P.S. I love the name.
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.