[HN Gopher] Uno: Single-Codebase for Windows, WebAssembly, iOS, ...
___________________________________________________________________
Uno: Single-Codebase for Windows, WebAssembly, iOS, macOS, Android
and Linux
Author : octopoc
Score : 312 points
Date : 2020-11-05 11:30 UTC (11 hours ago)
(HTM) web link (platform.uno)
(TXT) w3m dump (platform.uno)
| TacticalCoder wrote:
| 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.
| larvaetron wrote:
| 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.
| silon42 wrote:
| Pixel perfect... I hope it supports "Large fonts" settings.
| thomasfromcdnjs wrote:
| lol feel the pain
| _a1_ wrote:
| Is this a direct competitor to Flutter?
| k__ wrote:
| _" 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 wrote:
| 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__ wrote:
| Yes, I read "platform 2D primitives" as the basic UI
| elements of the platform, but you're right.
| TeeWEE wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bjano wrote:
| 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.
| ralph87 wrote:
| 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
| kevingadd wrote:
| 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...
| ralph87 wrote:
| 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.
| hu3 wrote:
| 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.
| ralph87 wrote:
| Effectively this is arguing for the project's attention
| to detail being low, we covered this already
| josalhor wrote:
| 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.
| huhtenberg wrote:
| > _Pixel Perfect Everywhere_
|
| Not to nitpick, but https://i.imgur.com/xzfrim8.png
| greatgib wrote:
| 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_ wrote:
| Is it really that worse than Java / Electron?
| phendrenad2 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| greatgib wrote:
| 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.
| hobby-coder-guy wrote:
| A software?
| tester34 wrote:
| 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.
| graderjs wrote:
| 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
| blargmaster42_8 wrote:
| Silverlight...never forget never forgive!
| whylo wrote:
| 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
| thomasfromcdnjs wrote:
| 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.
| s_fischer wrote:
| 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.
| thomasfromcdnjs wrote:
| 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.
| NeutronStar wrote:
| So something like schema?
|
| Don't reinvent the wheel.
| sdfhbdf wrote:
| 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
| thomasfromcdnjs wrote:
| 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.
| athenot wrote:
| This also looks very foreign on the mac.
| jlaban-uno wrote:
| - 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/sto
| re/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.co
| m/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.
| whylo wrote:
| 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
| cool-RR wrote:
| 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.
| TheMagicHorsey wrote:
| Why not Flutter :)
| speedgoose wrote:
| This is super slow on Firefox Android.
| danielskogly wrote:
| 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
| sharpercoder wrote:
| 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.
| alias_neo wrote:
| 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.
| xyst wrote:
| 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.
| LockAndLol wrote:
| Let me guess... it Electron but in C#?
| newbie578 wrote:
| 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 wrote:
| Can you elaborate on "I consider React Native a dead man
| walking"?
| alexandrius wrote:
| It's a Flutter fanboys' bedtime story
| gwbas1c wrote:
| _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.
| Multicomp wrote:
| 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?
| WorldMaker wrote:
| > 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.)
| kanox wrote:
| > 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 wrote:
| 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!
| jgilias wrote:
| 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 wrote:
| 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.
| intricatedetail wrote:
| Is there a guarantee that this is not going to share the fate
| of WPF?
| pjmlp wrote:
| Like still being maintained and supported on latest Windows
| and .NET versions?
| moogly wrote:
| The problem is they never truly iterated on the product.
| There are a hundred ways you could simplify and improve
| WPF.
| pjmlp wrote:
| Feel like contributing? https://github.com/dotnet/wpf
| moogly wrote:
| No thanks, it's been dead for a while.
| WorldMaker wrote:
| There are updates to WPF (and WinForms) in .NET Core 5.
| It's probably more accurately "undead" than "dead".
| moogly wrote:
| I'll buy "undead", since it's just maintenance (just
| check their roadmap).
| pjmlp wrote:
| I prefer mature and stable.
| pjmlp wrote:
| 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.
| DaiPlusPlus wrote:
| > 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 wrote:
| 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 wrote:
| > 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).
| pjmlp wrote:
| 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.
| DaiPlusPlus wrote:
| 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...)
| pjmlp wrote:
| 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.
| jmnicolas wrote:
| > 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.
| Const-me wrote:
| > 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.
| datavirtue wrote:
| 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.
| DaiPlusPlus wrote:
| > 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).
| WorldMaker wrote:
| 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.
| jgilias wrote:
| 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?
| pjmlp wrote:
| 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.
| nbevans wrote:
| 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.
| nxc18 wrote:
| 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.
| blackoil wrote:
| .Net has yearly release schedule, so 6 will be in Nov 2021.
|
| https://devblogs.microsoft.com/dotnet/net-core-releases-
| and-...
| JamesSwift wrote:
| 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.
| mrtksn wrote:
| 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.
| swiley wrote:
| 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.
| trboyden wrote:
| 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.
| TeeWEE wrote:
| 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 wrote:
| 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.
| acuozzo wrote:
| > 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.
| wsc981 wrote:
| 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 wrote:
| 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.
| mrtksn wrote:
| 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.
| unnouinceput wrote:
| 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.
| trboyden wrote:
| 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.
| qwerty456127 wrote:
| > The only open source-platform for creating true single-source,
| multi-platform applications.
|
| What about Flutter?
| robertlagrant wrote:
| 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 wrote:
| 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.
| numlock86 wrote:
| The dark mode brings black text on almost black background when
| using Fluent. No, thanks.
| matesz wrote:
| 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.
| lewisjoe wrote:
| 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
| intricatedetail wrote:
| Have you seen Juce? https://juce.com
| datavirtue wrote:
| 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.
| [deleted]
| dubcanada wrote:
| Technically Qt can with WebAssembly. It renders the application
| to a canvas element.
| pier25 wrote:
| Ignoring the web target, this looks amazing for mobile and
| desktop.
|
| What's the business strategy here? Providing support and
| training?
| madeofpalk wrote:
| _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 wrote:
| 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 wrote:
| 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
| Mertax wrote:
| 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/
| madeofpalk wrote:
| 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.
| gregopet wrote:
| 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..
| JaggerJo wrote:
| 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 wrote:
| 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
| oscargrouch wrote:
| > - 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.
| tambourine_man wrote:
| 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 wrote:
| In addition, the logos are blurry because apparently they
| couldn't be bothered to support "retina" displays. Sloppy.
| joshuaissac wrote:
| The Windows logo is also off. The tops of the two upper
| trapezia do not line up.
| jbverschoor wrote:
| pixelperfect, but not platform-perfect
| flohofwoe wrote:
| Kinda hard to find actually working WASM showcases, but this
| one...
|
| 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.
| jeswin wrote:
| 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/
| kevingadd wrote:
| 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.
| zigzag312 wrote:
| +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.
| csharptwdec19 wrote:
| 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.)
| greggman3 wrote:
| 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.
| qwerty456127 wrote:
| > This simple calculator ... 53.8 MBytes uncompressed.
|
| So it's no better than Electron? I'm primarily interested in
| the cross-platform desktop part.
| MarkyC4 wrote:
| uado isn't quite "pixel-perfect" on Firefox (82.0.2, Mac):
| https://i.imgur.com/EYFzTv3.png
| MarkyC4 wrote:
| seems fixed now!
| carldebilly wrote:
| 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.
| tasogare wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kevingadd wrote:
| 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.
| madeofpalk wrote:
| 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.
| flohofwoe wrote:
| 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.
| jlaban-uno wrote:
| - 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.
| flohofwoe wrote:
| 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.
| kevingadd wrote:
| 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.
| chabad360 wrote:
| 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".
| oscargrouch wrote:
| 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.
| jlaban-uno wrote:
| - 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.
| ComodoHacker wrote:
| I'd guess you'll be shipping precompiled essential .NET
| assemblies with Edge?
| kevingadd wrote:
| 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.
| jlaban-uno wrote:
| 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.
| greggman3 wrote:
| 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.
| lukevp wrote:
| 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?
| JoshTriplett wrote:
| > 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.)
| ComodoHacker wrote:
| >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.
| rictic wrote:
| > 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.
| Spivak wrote:
| "Please Update .NET to the latest version to access this
| website."
| reaperducer wrote:
| _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
| azakai wrote:
| 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.
| filleduchaos wrote:
| 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.
| azakai wrote:
| 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.
| kevingadd wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| flohofwoe wrote:
| 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.
| jcelerier wrote:
| 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) )
| sippeangelo wrote:
| 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.
| Touche.
| madeofpalk wrote:
| 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.
| merb wrote:
| 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.
| kevingadd wrote:
| 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.
| baq wrote:
| 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
| SiVal wrote:
| So what has that decade taught you is the best solution for
| quick and dirty UIs?
| baq wrote:
| 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.
| acuozzo wrote:
| HyperCard.
| 0x10c0fe11ce wrote:
| Beeware!
| SenHeng wrote:
| PowerBuilder, in the EMR industry.
| qzw wrote:
| VisualBasic, back in the day.
| smoyer wrote:
| 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.
| kevingadd wrote:
| 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.
| kodablah wrote:
| > 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
| smoyer wrote:
| 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.
| andrekandre wrote:
| 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)
| jlaban-uno wrote:
| - 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).
| snek wrote:
| 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.
| nottorp wrote:
| Hmm last time i heard 'pixel perfect' I was interviewing for a
| job. Turned it down.
___________________________________________________________________
(page generated 2020-11-05 23:00 UTC)