...loads 8.1 MBytes compressed (32 MBytes uncompressed) until the login button appears.
This simple calculator:
...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.
BUT, putting Mono out there let everyone else in the community start developing tooling (that Microsoft will take the best ideas from before politely acting like the community didn't keep the whole idea afloat.)
For context, the Blazor team started with their own interpreter compiled to WASM (via emscripten) instead of using either Mono or CoreRT - because shipping and getting user feedback is really important, and you can't do that while waiting for the ideal tech to be ready. It was swapped out later.
CoreRT is pretty cool tech but I rarely encounter anyone using it. Hopefully that will change in the future. The only CoreRT-based production app I know of is Streets of Rage 4 and it's a very recent release.
I agree that getting early user feedback is really important, but IMO it would be better if a limited version of Blazor WebAssembly (that would support only subset of .NET features, but have usable runtime size) was released on CoreRT tech and then slowly add more features. Blazor WebAssembly at it's current state, even though it supports all features, is too big to be really usable.
Spreading development resources thin between old tech like Mono and future tech just means future tech will be delayed even more. And when they figure out that in order to get the size down to a competitive levels, it would be better, if some features were kept out of the WebAssembly runtime (eg dropping reflection and relying on code generation instead), it will be too late, because it'll break compatibility with released Blazor WebAssembly projects.
Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.
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.
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.
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.
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.
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.
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.
But then, I don't understand why you wouldnt just make it with web tech to begin with and 'port' it to native platforms with Electron.
source: been involved in quick and dirty UIs in a business for the past decade
WASM (language independence) on electron (fixed, controlled browser version) with delphi-like UI designer could work, maybe.
The same logic applies now and it's even more compelling since the tooling and performance are better now with the full LLVM WASM toolchain and more robust C# AOT compilation available, vs the dark ages when people had JSIL, Saltarelle and Bridge to choose from.
I'll also note that every major company I'm aware of that made a C# -> Browser move for their tooling eventually regretted it and started shifting away to something better, partly due to platform churn and partly due to how much was outside of their control. Electron may change the equation there enough to be good enough, we'll see - I don't know of any companies that have taken that route yet.
I don't think this is intended for public facing, low bandwidth/mobile websites.
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.
(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) )
Sometimes you just want for code to be able to run at all, even with a sizable download, if it means you don't need to do any porting work. For example if you have many years of work on a codebase, and you can run it on the web with almost no effort, that can be really useful.
I agree that we want most things on the web to be optimized for the web. But sometimes business or other reasons matter more than code size.
Part of including unicode package itself (transitively or otherwise) has a ton of package-level vars that bloat the WASM. Also, they slow down init because a bunch of code has to be run to initialize them. Also, due to the fact that WASM doesn't have arbitrary jumping, in order to support coroutine yielding and resumption, Go's WASM support puts big br_tables at the top.
A while back, I brought up some efficiency concerns w/ data size and init instruction count 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. I kinda gave up on using Go and WASM after all of that, but there is real room for improvement there.
0 - https://webassembly.github.io/spec/core/exec/instructions.ht...
1 - https://github.com/golang/go/issues/26622
2 - https://github.com/cretz/go-wasm-bake
I dont think this case of whole complex applications in WASM will fly. It looks like ActiveX 2.0 all over again.
Of course some things will happen as full apps in WASM, but they are mostly tools people already use outside of the Web, so that particular crowd just want to reach the tool, it doesnt matter the medium.
So it's no better than Electron? I'm primarily interested in the cross-platform desktop part.
The way Unity solves this is by creating their own C# dialect, compiler and minimal runtime (without GC etc). Sort of a brute-force approach, but until the standard .NET ecosystem solves the bloat problem it would have been better to build on a different language ecosystem.
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.
However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific.
They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.
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.
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.
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.
Consider yourself lucky. It doesn't do anything on my machine except show the splash screen.
macOS 10.15.6 / Safari 14.0
The Safari Support for large WebAssembly binaries is not particularly great at this point. We hope that the Safari team will improve the performance aspects of WebAssembly, but it does not seem to be a priority at this point (see the Wasm feature map here: https://webassembly.org/roadmap).
For the iPad, the iOS built version of the same app works lots better (https://apps.apple.com/us/app/uno-calculator/id1464736591).
Accessibility is high on our feature list; we have added aria base support in recent builds of Uno, which the calculator will start using soon (the iOS https://apps.apple.com/us/app/uno-calculator/id1464736591 and Android https://play.google.com/store/apps/details?id=uno.platform.c...) versions of the same app are screen-reader enabled). The Linux one (Snap https://snapcraft.io/uno-calculator, AppImage https://github.com/unoplatform/calculator/releases/tag/1.2.4...) is not yet enabled, but will also be.
The WinUI framework provides great accessibility support, and we intend to port it fully in the coming months.
If anyone else is interested, I found the relevant GitHub issue: https://github.com/unoplatform/uno/issues/1141
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.
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.
I think it's already happening in a little different form with Structured Data  and schema.org and it's using for example JSON-LD .
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
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.
At first XAML feels really nice because you've got the nice GridView and other UI components, but the moment you want to start customising these everything falls down. I was really disapointed by it's lack of more flexible layout semantics (like flexbox or display: grid), and instead offloading that all into writing custom C# code to lay things out at pixel locations.
What was just a single line in css - grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)) - ended up being many lines of custom layout code to achieve something much less performant.
I find the codegen/bindings situation to be really weird and XAML as well. Making custom XAML components/reusing code is trickier than it should be. React really got it right with JSX being just a thin layer of syntactic sugar on regular JS (I'm unsure how this would work for a static language like C#)
The inconsistency of the web platform is a nightmare compared to my pain-free experience with XAML.
XAML and C# allows a single developer to get a functional modern application going quickly.
I had zero problems with extensibility as long as I followed the patterns. Using MVVM, convertors, triggers, events, and behaviors where needed. The Blend tool is ridiculously cool, but I'm not artistic enough to make great use of it. But it reminds me of how Flash made me feel early on. As a kid I could make cartoons without issue in Flash.
Almost everything is open source or has an open source replacement available.
Making new UserControls is trivial. Much easier than any Web Components nonsense.
I still don't know how you're supposed to properly update data for a grouped List/GridView without causing the entire view to rerender. I'm so used to React's functional approach to building UIs that mutating collections seemed extremley alien and cumbersome to me.
I still never found a good way to achieve this a in in XAML, a grid layout where the cells will expand to fill remaining space on the row, and then wrap. Multiple components got kind of close, but always lacked 1 aspect https://codepen.io/joshhunt/full/qBOdYjj
By telling your views what was updated.
For updating sets of items, see INotifyCollectionChanged interface, implemented by ObservableCollection<T> from the framework.
For updating properties, see INotifyPropertyChanged.
> Multiple components got kind of close, but always lacked 1 aspect
Find a panel that does it best, then either copy-paste and patch, or inherit and override.
The entire layout model is implemented in just 2 methods, MeasureOverride and ArrangeOverride. They are virtual, i.e. designed to be user-replaceable as you inherit from framework classes.
> for building responsive layouts?
There're two kinds of them. On the web it means arranging stuff to only have vertical scrolling but not horizontal. On desktop you often don't want any scrolling, no amount of auto-wrapping is going to do that regardless on the GUI framework.
If I wanted to make a website, I'm more than confident and productive with HTML/CSS/JS/React to build out what i need.
- wasm source takes around 2 MB
- loads up quickly and it is fast even in mobile browsers
- great codebase!
- compiles in under a minute (41s on my laptop) inspite being written in Rust
Still needs a lot of work to be usable:
- missing UI features like proper layouting, configurability etc.
- imo font rendering still needs a lot of work; but there are already project in rust which do font rendering right, for instance: (git clone github.com/linebender/druid && cd druid && cargo run --release --example=text)
- no animated transitions of UI components
Makepad doesn't strive to be UI toolkit, but judging by the way it works already and dedication of the founders it looks really promising.
Right now I'm studying how Flutter has achieved this using Skia. I'm also following JetBrains Compose, but as of the moment it only seems to support desktop native apps. How is this one different from Flutter/JetBrains Compose?
Under normal circumstances I dismiss any new Microsoft UI framework like uwp or winui3 out of hand because I know in two years or so, some other product manager will take over and will need to make their own stamp on the organization, so they will introduce yet another UI framework and Winui3 will be stagnated just like silverlight was.
I use F# Fable right now for web applications with intentions to learn Avalonia and eventually trim down my use of good old winforms when I'm writing desktop only applications.
Having said all that, I do like the idea of being able to write code in one code base and have it be compiled via xamarin to other runtimes.
Does this platform deliver on that promise?
Is anyone who has a few battle scars using this tool able to give a small review?
You do realize that the 3 implies it is the 3rd version of a project? WinUI 3 is just the "third version" of the UI component library used inside UWP originally, but now with bonus compatibility with WinForms and WPF.
To me that's the opposite of "stagnated" or "deprecated every two years". The UI parts of UWP and WinUI3 are more the same thing, just versions over time, than they are different. It just continues to evolve with each new versions that include new features (such as the new "Now with much better WPF and WinForms support" features for people in brownfield applications).
You should be excited about WinUI3 because it lets you dip your toes in what UWP added to the UI framework from your WinForms and WPF development. You'll probably find it feels a lot more like WPF than you'd think given how demonized UWP's UI framework has been. (It's not WPF, of course, and there are compatibility breaks to learn/deal with, but it's still XAML-based UI design with a lot of very similar controls and tools in the toolkits.)
Checking on wikipedia shows that winforms was introduced in 2002 and wpf in 2006. This makes me feel very old.
This might lead to a unified style across platforms but as it does not use the same rendering logic/code on every platform I'd doubt that it's pixel perfect. Building a text editor would probably expose a lot of these close but not similar scenarios.
On the other hand this adds the benefit of getting native behaviour of text boxes maybe ?
Avalonia on the other hand does custom rendering using Skia and therefore really has pixel perfect rendering across platforms. This also means that it does not use the native controls and behaviour differs.
If I had to write a cross platform app (and had the budget) I would probably use Xamarin and just write platform specific UIs. If there are heavy UI components these could still be shared.
If on a budget something like this seems fine. Would probably go with avalonia UI tho tbh.
- Uno uses the UWP API and XAML, whereas Avalonia uses a derivative of WPF
- Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think)
- Uno is based on WinUI, so in theory WinUI components should be usable in Uno apps
- Uno supports WebAssembly, but not Linux and MacOS natively
This line remembers a constant pitch i see here on HN, where people ask for native controls to be rendered for multi-platform UI sdk's that i think go on the "faster horse"(Ford) sort of misdirection.
The problem with the 'faster horse' paradox is that the only way to make people forget about wanting a faster horse is by showing them the car.
I think a platform like Flutter get this right, as do HTML/CSS/JS, because theres no way to get really consistent if you have to use the platform native controls. It will also be messy for the developers, requiring a lot of effort and money to make things partially right.
I bet with you that most of these people asking for this use a Mac, and while Apple is more or less half of the market of US, in the rest of the world Apple have much smaller deploy base.
So sometimes, you need to be careful because even HN can suffer from a bubble social effect, that will misguide people that actually listen what they are asking for.
In the long term there's already a multi-platform UI paradigm there is set to win, and its called HTML..
Native UI platforms had a sort of comeback because of the iphone revolution, but in the long term, they will not be the winners, because Apple is doing the same mistakes they did in the eighties.
All those cross-platform app frameworks fail at the same point: Meeting the user expectations since they are different on different platforms. It always feels off if the platform specific experience is not fine tuned to the platform and at that point why just don't go native and have all the shiny things that the platform has to offer.
Flutter is the platform that provides excellent experience here... Not on web yet, but its coming close.
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.
It’s the ultimate cross platform UI framework.
If you're building the GUI for some local tool TCL/TK is a lot better IMO.
I hate Java. I really do. But when it comes to absolute same experience on cross-platform is the only programming language so far. None else is in the same league as Java. A distant second would be Free Pascal/Lazarus but their richness of libraries is like 10% of Java's. And please do not come with Xamarin, that monstrosity must be killed.
In case of Android-only I would actually rather use C# and Xamarin than Java.
Why do you feel Xamarin is a monstrosity that must be killed?
The problem is that if we're talking about UIs, then Java is only cross-platform for the platforms you care about.
From a UI perspective, JRandom app using Swing won't work as expected on an Android phone. That's not "absolute same experience on cross-platform". That's instead a portability problem that you must solve explicitly by adapting your codebase to support two different UI frameworks or planning ahead for every possible porting target.
(check the logos)
Con: The calculator demo takes waaaaaay too long to load. The long load time might be acceptable for a very rich web application.
To paraphrase - what's the selling point of using Uno vs using .NET 5 and .NET MAUI (the successor of Xamarin.Forms) directly?
WinUI being the UI platform that Microsoft seems to be pushing on windows these days.
WinUI doesn't sit well with me - it has the same problem that all the other "user-mode" UI frameworks have: it isn't a system-service, so once your app ships it's frozen in time and won't benefit from new features added to native widgets and controls (e.g. if you run a well-designed MFC EXE last compiled for Windows 2000 - but tweak the embedded manifest resource file to load the updated CommonControls and Windows 10 compatibility - it will still look good today and fit-in with an MFC program created new last week (I note it will look "good" - not "amazing" - because Microsoft decided to take Windows 10's native widgets downmarket since Windows 8, ugh...).
Could be worse - at least it's not Java AWT or Swing. What on earth was Sun thinking when they designed that?
Give me raw Win32 over Xlib/Athena/Motif any day of the week.
I share your sentimental attitude, but looking at the past 10+ years of "post-native" desktop UI development being done in Electron, at al, it really does look like the days of platform-specific proprietary UI frameworks and toolkits are coming to an end. Modern HTML+CSS is a far more expressive medium for usable application UI layouts. Trying to build a "responsive" UI in VB6 is essentially impossible, for example. Even from a user's perspective I'm glad that fixed-size, DPI-unaware dialogs are done-away with.
I can't complain that much though - I don't miss writing low-level Win32 message-pumps - nor being limited by GDI's horribly outdated nature (fun-fact: it's impossible to build applications that support 10-bit color with GDI despite GDI's built-in support for different bpp values, because GDI assumed 24bpp / 8bpc was enough for anyone forever).
There's now only a few things missing from HTML+CSS that would enable true native-like applications: borderless sub-windows (think: for context-menus that can extend beyond the parent web-browser's client area on your desktop) and native macOS main-menu support (which feels like an anachronism given the large mouse-movements needed with today's humongous desktop display sizes).
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.
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.
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.
There is so much that the Web still fails short of WPF.
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
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).
I haven't used Xamarin.Forms, what's the problem with it?
In any case, MAUI is Xamarin.Forms extended to the desktop, the name changed for marketing purposes.
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.
Xamarin Forms let us build 4 years worth of tech for Android only. And then, when we had time and the customer demand to do so, with a small amount of work - port our app to 2 other platforms in fairly short order.
I don't know of any other platform that could do this - particularly when considering the years involved.
Our app uses local databases on the device - so a web based app would not have cut it. And our app has roots in 2014 tech when many possible alternate approaches did not exist yet.
Yes the team is small, still great than zero and more mature than plenty of wannabe FOSS GUI frameworks.
It appears to be built on Xamarin.
What we have here is cross-platform for .NET developers.
- 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.
Sorry to any dev at Uno, but that's terrible.
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.
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
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.
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...
"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.
All the top reviews are talking about how slow it is. A calculator app.
That others are just as wasteful is immaterial; the fact that it's multiplied by every single user makes it downright hostile to everyone except those who are profiting from bandwidth use.
Every single "cross-platform solution" I've seen is basically a sub-optimal experience on every platform. Personally, I'd rather have fewer native applications than the wave of quantity-over-quality not-quite-right-anywhere that stuff like this tends to encourage.
Every time I see pixel-perfectness claimed I immediately approach it with a lot of caution.
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.
And the components in flutter are of very high quality. Pixel perfect copies of ios and material design.
Sounds more like a React-Native competitor to me.
What's the business strategy here? Providing support and training?
What about Flutter?
Not to nitpick, but https://i.imgur.com/xzfrim8.png
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..
P.S. I love the name.
Also I would like to avoid using anything Microsoft, if I can avoid it.
Usage, cpu/mem bloat, dependencies, ethic, will all be all wrong...
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.
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.
You can try it out here, too. I open sourced it.
And "hello world" binary download size is 10 Mb for Windows.
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.