That's odd - I tried the same page, and felt it was very responsive, up until I did 7+ square root operations. This is in Vivaldi, on a Windows 10 (2.5 year old fairly beefy "gaming") laptop, with a bunch of tabs and Spotify running. I do have uBlock Origin enabled, though even with it disabled that page seems fine to me.

Not defending or excusing it, or doubting your results - I guess mostly lamenting we don't have more consistent performance across platforms...

Firefox on linux, Ryzen 7 2700. Sometimes it's very responsive, but most of the time there's at least a quarter-second lag from when I hit a number to it appearing on the display. I wouldn't be surprised if chromium based browsers are more consistent.

I tried the calculator and it had an even worse version of the iPhone calculator bug for me. The iPhone bug was that the buttons had a cool-down period where they didn’t work after being pressed so if you pressed a button too many times in a short time it wouldn’t work. The bug here was that after pressing a button, everything would lock out for a while, but maybe it’s just a web standards thing or my device being slow.

I don’t know why Uno continues to advertise WASM as a target. It’s a great framework for desktop and mobile but it’s obvious how slow their web demos are. They really shouldn’t advertise it, it’s not suitable for production…

It has worse problems than performance. It’s not a calculator, it’s random number generator.

Steps to reproduce: click “C“ with the mouse, then type on numeric keypad 2 * 2 {enter}

Expected result 4, actual: 0.

6 seconds to load

35.8 mb of ressources

for a calculator...

how can people be fine with that and press the publish button?

Hi, Uno Platform dev here. We're not fine with the current payload size of the application, really.

It's definitely too large, and that is the current state of .NET running on WebAssembly, where missing WebAssembly features (like exception handling) are forcing the compiler to generate a lot of code to compensate.

Still, we have one issue in this build where the PWA webworker doubles parts the payload, but even at ~25MB, it is still too big even if it is downloaded once and cached. For reference, the original windows version is around 13MB on disk for x86.

The point of the Calculator exercise is to show the ability to port the Windows calculator as-is (though translated from C++ to C#) to multiple non-Windows platforms. We continue working on that to improve the payload size and performance further, following WebAssembly, browsers and the .NET runtime advances.

Then maybe don't showcase it so prominently. I bet this demo is what about 90% of people interested in Uno check out and my perception was certainly "wow, this performs badly", tainting my perception of the whole thing.

The same way they can be fine with a bash processes having 24 megabyte VM footprints.

  kaz      22301  0.0  0.0  25188  7264 pts/2    Ss+  Nov03   0:02 bash
  kaz      25976  0.0  0.1  27268  9632 pts/1    Ss   Nov16   0:08 bash
  kaz      27179  0.0  0.0  24368  6704 pts/0    Ss   Nov16   0:01 bash
           ^^^^^ ??

EMACS = Eight Megabytes and Constantly Swapping used to be a ha-ha only not funny joke.

That does seem weird. Just checked my bash processes and none exceed 13 megabytes of virtual memory

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command 
  2048 REDACTED 20   0 12852  1844  1816 S  0.0  0.0  0:00.01 │ bash

Ubuntu 20.04 with latest patches

I remember a moment from 1994 or so. I was using a friend's machine, which was running X on top of Linux. It was some model of 486. I had some image viewing windows open (xv program), and was editing a complex figure in XFig, and had some audio playing.

I was thinking, "man, this is nicely responsive and usable; how much RAM is in this thing?"

I drop to the shell to run "free" ... 6 megs!

Remembering these things is important, kind of like remembering rivers full of fish, frozen polar ice caps, or the song of an extinct bird.

The same that would otherwise create a react app to display static text or an image gallery.