14 ms·

Uno: Single-Codebase for Windows, WebAssembly, iOS, macOS, Android and Linux

359 points by octopoc 6y ago

_a1_ 6y ago
Is this a direct competitor to Flutter?
- k__ 6y ago
  "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.
  - gman83 6y ago
    Well if it's drawing every pixel or using 2D primitives that sounds much more like Flutter than React Native since Flutter also uses Skia while React Native uses platform widgets.
    - k__ 6y ago
      Yes, I read "platform 2D primitives" as the basic UI elements of the platform, but you're right.
- TeeWEE 6y ago
  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.
jonpalmisc 6y ago
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.
- ralph87 6y ago
  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
  - hu3 6y ago
    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.
    - ralph87 6y ago
      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
      - hu3 6y ago
        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.
greatgib 6y ago
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...
- _a1_ 6y ago
  Is it really that worse than Java / Electron?
- phendrenad2 6y ago
  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?
  - greatgib 6y ago
    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.
- sz4kerto 6y ago
  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).
alias_neo 6y ago
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/ https://platform.uno/how-it-works/ It appears to be built on Xamarin. What we have here is cross-platform for .NET developers.
LockAndLol 6y ago
Let me guess... it Electron but in C#?
Multicomp 6y ago
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?
- kanox 6y ago
  > 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.
  - jmnicolas 6y ago
    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!
- WorldMaker 6y ago
  > 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.)
jgilias 6y ago
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?
- cdash 6y ago
  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.
  - DaiPlusPlus 6y ago
    > 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?
    - pjmlp 6y ago
      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.
      - DaiPlusPlus 6y ago
        > 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).
numlock86 6y ago
The dark mode brings black text on almost black background when using Fluent. No, thanks.
lewisjoe 6y ago
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 https://writer.zoho.com
- deleted 6y ago
  [deleted]
- intricatedetail 6y ago
  Have you seen Juce? https://juce.com https://juce.com
- datavirtue 6y ago
  Flutter is horrid and will be abandoned by Google. No idea what they were thinking on that one. The only cross platform dev framework even close to a mark of professionalism is Xamarin.Forms.
- dubcanada 6y ago
  Technically Qt can with WebAssembly. It renders the application to a canvas element.
- gorbypark 6y ago
  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.
tambourine_man 6y ago
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.
- larrysalibra 6y ago
  In addition, the logos are blurry because apparently they couldn't be bothered to support "retina" displays. Sloppy.
- joshuaissac 6y ago
  The Windows logo is also off. The tops of the two upper trapezia do not line up.
flohofwoe 6y ago
Kinda hard to find actually working WASM showcases, but this one... https://uado.platform.uno/ https://uado.platform.uno/ ...loads 8.1 MBytes compressed (32 MBytes uncompressed) until the login button appears. This simple calculator: https://calculator.platform.uno/ 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.
- tasogare 6y ago
  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...
  - achn 6y ago
    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.
  - flohofwoe 6y ago
    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.
    - withinboredom 6y ago
silon42 6y ago
Pixel perfect... I hope it supports "Large fonts" settings.
- thomasfromcdnjs 6y ago
  lol feel the pain
whylo 6y ago
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/ https://calculator.platform.uno/) and the gallery (https://gallery.platform.uno/ 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
- thomasfromcdnjs 6y ago
  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 https://blah.com/dashboard (web assembly) (not indexable) https://blah.com/dashboard.data 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.
  - NeutronStar 6y ago
    So something like schema? Don't reinvent the wheel.
  - sdfhbdf 6y ago
    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-structured-data https://developers.google.com/search/docs/guides/intro-struc... [2]: https://json-ld.org https://json-ld.org
danielskogly 6y ago
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 https://github.com/fuse-open/uno
mrtksn 6y ago
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.
- TeeWEE 6y ago
  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.
- unnouinceput 6y ago
  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.
  - wsc981 6y ago
    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?
    - unnouinceput 6y ago
      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.
madeofpalk 6y ago
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#)
- nwah1 6y ago
  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.
  - madeofpalk 6y ago
    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 https://codepen.io/joshhunt/full/qBOdYjj
JaggerJo 6y ago
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.
- octopoc 6y ago
  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/unoplatform/uno/issues/17 - https://github.com/AvaloniaUI/Avalonia/issues/587 https://github.com/AvaloniaUI/Avalonia/issues/587
  - oscargrouch 6y ago
    > - 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.
jbverschoor 6y ago
pixelperfect, but not platform-perfect
nottorp 6y ago
Hmm last time i heard 'pixel perfect' I was interviewing for a job. Turned it down.
robertlagrant 6y ago
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.
- vr46 6y ago
  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.
TacticalCoder 6y ago
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.
speedgoose 6y ago
This is super slow on Firefox Android.
sharpercoder 6y ago
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.
gwbas1c 6y ago
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.
TheMagicHorsey 6y ago
Why not Flutter :)
larvaetron 6y ago
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.
huhtenberg 6y ago
> Pixel Perfect Everywhere Not to nitpick, but https://i.imgur.com/xzfrim8.png https://i.imgur.com/xzfrim8.png
newbie578 6y ago
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..
- eloc49 6y ago
  Can you elaborate on "I consider React Native a dead man walking"?
  - alexandrius 6y ago
    It's a Flutter fanboys' bedtime story
matesz 6y ago
One of the best cross-platform open source projects I've seen so far is https://makepad.nl 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.
snek 6y ago
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.
blargmaster42_8 6y ago
Silverlight...never forget never forgive!
pier25 6y ago
Ignoring the web target, this looks amazing for mobile and desktop. What's the business strategy here? Providing support and training?
xyst 6y ago
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.
qwerty456127 6y ago
> The only open source-platform for creating true single-source, multi-platform applications. What about Flutter?
- jjn2009 6y ago
  I believe some environments are still beta. I have enjoyed flutter even with that limitation.
theCodeStig 6y ago
If this works with F#, It looks incredibly interesting. P.S. I love the name.

359 points by octopoc 6y ago

_a1_ 6y ago

Is this a direct competitor to Flutter?

k__ 6y ago
"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.
- gman83 6y ago
  Well if it's drawing every pixel or using 2D primitives that sounds much more like Flutter than React Native since Flutter also uses Skia while React Native uses platform widgets.
  - k__ 6y ago
    Yes, I read "platform 2D primitives" as the basic UI elements of the platform, but you're right.
TeeWEE 6y ago
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.

jonpalmisc 6y ago

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.

ralph87 6y ago
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
- hu3 6y ago
  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.
  - ralph87 6y ago
    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
    - hu3 6y ago
      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.

greatgib 6y ago

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...

_a1_ 6y ago
Is it really that worse than Java / Electron?
phendrenad2 6y ago
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?
- greatgib 6y ago
  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.
sz4kerto 6y ago
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).

alias_neo 6y ago

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/ https://platform.uno/how-it-works/ It appears to be built on Xamarin. What we have here is cross-platform for .NET developers.

LockAndLol 6y ago

Let me guess... it Electron but in C#?

Multicomp 6y ago

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?

kanox 6y ago
> 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.
- jmnicolas 6y ago
  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!
WorldMaker 6y ago
> 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.)

jgilias 6y ago

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?

cdash 6y ago
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.
- DaiPlusPlus 6y ago
  > 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?
  - pjmlp 6y ago
    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.
    - DaiPlusPlus 6y ago
      > 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).

numlock86 6y ago

The dark mode brings black text on almost black background when using Fluent. No, thanks.

lewisjoe 6y ago

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 https://writer.zoho.com

deleted 6y ago
[deleted]
intricatedetail 6y ago
Have you seen Juce? https://juce.com https://juce.com
datavirtue 6y ago
Flutter is horrid and will be abandoned by Google. No idea what they were thinking on that one. The only cross platform dev framework even close to a mark of professionalism is Xamarin.Forms.
dubcanada 6y ago
Technically Qt can with WebAssembly. It renders the application to a canvas element.
gorbypark 6y ago
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.

tambourine_man 6y ago

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.

larrysalibra 6y ago
In addition, the logos are blurry because apparently they couldn't be bothered to support "retina" displays. Sloppy.
joshuaissac 6y ago
The Windows logo is also off. The tops of the two upper trapezia do not line up.

flohofwoe 6y ago

Kinda hard to find actually working WASM showcases, but this one... https://uado.platform.uno/ https://uado.platform.uno/ ...loads 8.1 MBytes compressed (32 MBytes uncompressed) until the login button appears. This simple calculator: https://calculator.platform.uno/ 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.

tasogare 6y ago
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...
- achn 6y ago
  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.
- flohofwoe 6y ago
  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.
  - withinboredom 6y ago

silon42 6y ago

Pixel perfect... I hope it supports "Large fonts" settings.

thomasfromcdnjs 6y ago
lol feel the pain

whylo 6y ago

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/ https://calculator.platform.uno/) and the gallery (https://gallery.platform.uno/ 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

thomasfromcdnjs 6y ago
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 https://blah.com/dashboard (web assembly) (not indexable) https://blah.com/dashboard.data 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.
- NeutronStar 6y ago
  So something like schema? Don't reinvent the wheel.
- sdfhbdf 6y ago
  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-structured-data https://developers.google.com/search/docs/guides/intro-struc... [2]: https://json-ld.org https://json-ld.org

danielskogly 6y ago

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 https://github.com/fuse-open/uno

mrtksn 6y ago

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.

TeeWEE 6y ago
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.
unnouinceput 6y ago
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.
- wsc981 6y ago
  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?
  - unnouinceput 6y ago
    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.

madeofpalk 6y ago

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#)

nwah1 6y ago
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.
- madeofpalk 6y ago
  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 https://codepen.io/joshhunt/full/qBOdYjj

JaggerJo 6y ago

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.

octopoc 6y ago
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/unoplatform/uno/issues/17 - https://github.com/AvaloniaUI/Avalonia/issues/587 https://github.com/AvaloniaUI/Avalonia/issues/587
- oscargrouch 6y ago
  > - 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.

jbverschoor 6y ago

pixelperfect, but not platform-perfect

nottorp 6y ago

Hmm last time i heard 'pixel perfect' I was interviewing for a job. Turned it down.

robertlagrant 6y ago

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.

vr46 6y ago
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.

TacticalCoder 6y ago

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.

speedgoose 6y ago

This is super slow on Firefox Android.

sharpercoder 6y ago

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.

gwbas1c 6y ago

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.

TheMagicHorsey 6y ago

Why not Flutter :)

larvaetron 6y ago

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.

huhtenberg 6y ago

> Pixel Perfect Everywhere Not to nitpick, but https://i.imgur.com/xzfrim8.png https://i.imgur.com/xzfrim8.png

newbie578 6y ago

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..

eloc49 6y ago
Can you elaborate on "I consider React Native a dead man walking"?
- alexandrius 6y ago
  It's a Flutter fanboys' bedtime story

matesz 6y ago

One of the best cross-platform open source projects I've seen so far is https://makepad.nl 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.

snek 6y ago

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.

blargmaster42_8 6y ago

Silverlight...never forget never forgive!

pier25 6y ago

Ignoring the web target, this looks amazing for mobile and desktop. What's the business strategy here? Providing support and training?

xyst 6y ago

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.

qwerty456127 6y ago

> The only open source-platform for creating true single-source, multi-platform applications. What about Flutter?

jjn2009 6y ago
I believe some environments are still beta. I have enjoyed flutter even with that limitation.

theCodeStig 6y ago

If this works with F#, It looks incredibly interesting. P.S. I love the name.