[ralph87]

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

[josalhor]

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.

[hu3]

That's for webassembly. None of that matters for most applications on the other platforms it targets.

And even for webassembly, 4.39 MB is not prohibitive for some use cases. Specially with caching. I bet the average medium blog loads more than that.

I wouldn't be so quick on dismissing a solution.

[ralph87]

Marketed as a single codebase platform where the most ubiquitous deployment target has a user experience that tells your customers you hate them

4.39 MB in 50 requests is a showstopper on any mobile network, especially when alternative solutions do not have that problem. It is fair to assume some first time experiences will involve 7.5 seconds or more additional latency on 3G networks, double that for a poor signal areas.

It's still an instant pass

[hu3]

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]

Effectively this is arguing for the project's attention to detail being low, we covered this already

[kevingadd]

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]

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.

[bjano]

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.

[userbinator]

I bet the average medium blog loads more than that.

That others are just as wasteful is immaterial; the fact that it's multiplied by every single user makes it downright hostile to everyone except those who are profiting from bandwidth use.

Every single "cross-platform solution" I've seen is basically a sub-optimal experience on every platform. Personally, I'd rather have fewer native applications than the wave of quantity-over-quality not-quite-right-anywhere that stuff like this tends to encourage.