Hacker News Reader

Comment by zwieback | Hacker News Reader

Very cool!

My question: will this kind of thing become more mainstream? I've seen the web emerge, go from static pages to entire apps being delivered and executed in the browser. The last bastion of native apps and libraries seems to be highly optimized algorithms but maybe those will also migrate to a deliver-from-the-web and execute in some kind of browser sandbox.

Java promised to deliver some version of native code execution but the Java app/applet idea never seemed to take off. In some ways it seems superior to what we have now but maybe the security concerns we had during that era held Java back too much. Or am I misunderstanding what WebAssembly can bring to the game?

View on HN

The web always feels terrible compared to a native app, especially on a phone. Some of the difference is due to Safari being a bad browser (probably intentional), but a bigger part is that the threading model makes it really difficult to have a responsive UI. Not to mention the browser’s gestures often clash with the application’s gestures.

WASM threads are available in all modern browsers now, including Safari. It's very early days in terms of ecosystem but we're steadily getting there.

Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.

Technically yeah, but the threads could only communicate through message passing which isn't ideal for performance. The more recent major improvement is for workers to be able to share a single memory space similar to how threading works in native applications.

The issue isn’t so much having additional threads, it’s needing two main threads. The browser has one main thread for accepting user input and then dispatches the relevant user events to the JS main thread.

The browser can either dispatch the events asynchronously, leading to the events being handled in a noticeably delayed way, or the browser can block its main thread until the JS dispatch finishes, leading to fewer UI events being handled. Either way is an inferior experience.

> Some of the difference is due to Safari being a bad browser (probably intentional), but a bigger part is that only having one thread makes it really difficult to have a responsive UI

Interestingly Safari is actually generally better than other browsers for running a responsive smooth UI. Not sure how much of that is the Safari engine and how much of it is better CPU on iPhones. But even on a first generation iPad or an iPhone 4 it was possible to get 60fps rendering fairly easily. The same could not be said for even higher end android phones of the time.

Anecdotally, the only time I’ve had issues with unresponsiveness for pages in Safari is with sites that were written with Chrome specifically in mind.

So, basically everything.

The impact is minimal to nonexistent on a light-to-moderate-JS “site” and only really shows up in heavy “apps”, like YouTube or GDocs.

Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.

Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.

Hmm the layout is working for me now, but the tile animation is broken. They flicker instead of smoothly flipping over.

Any chance you have reduced motion enabled? They flip for me but are obviously on a short timer.

I generally find Safari’s performance better than other browsers. Also, every mainstream JS runtime is multithreaded. There are limitations on what can be shared between threads, but you can optimize a lot despite those limitations (including using WASM on the web, and native extensions/FFI on Node/Deno).

On iOS, the perf of Safari is definitely better than every other browser, because every other browser is mandated to use WkWebView by Apple. They aren’t allowed to implement their own engine. Of course Apple isn’t subject to the same restriction.

Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)

On a Mac, Safari Javascript generally outperforms Chrome and Firefox (other browsing tasks are also generally better performing), but there are some workloads where Safari turns out slower, especially when the developer has put a lot of work into Chrome-specific optimization.

Safari also generally uses a lot less memory and CPU for the same websites. Chrome in particular burns through my battery very quickly, and is basically completely incapable of keeping up with my browser use style (it just crashes when I try to open a few hundred tabs). Presumably nobody with authority at Google is a heavy laptop web-user or prioritizes client-side resource use: Google’s websites are also among the biggest browser resource hogs, even when sitting idle in a background tab.

Safari often takes a couple years longer than other browsers to implement cutting-edge features. This seems to me like a perfectly reasonable design decision; some web developers love complaining about it though, and some sites that were only developed against the most recent versions of Chrome don’t work correctly in Safari.

In my experience, if the thing I’m working on runs in Safari, it’s buttery smooth. And if it doesn’t run, it completely shits the bed. Stuff like “we don’t support that way of doing shadows in SVG, so rather than simply not implement that property, we’ve turned your entire SVG element black”.

Every mainstream JS runtime has some sort of background garbage collection and parsing/compilation, but for any execution that has to interact with JavaScript heap or stack state you’re still in single threaded territory. SharedArrayBuffer can help if you’re willing to give up on JavaScript objects entirely, and for WebAssembly this is less of a burden, but that’s not going to help you perform rendering on most web apps concurrently. JSCore goes a little bit further and can run javascript in the same runtime instance on multiple threads with some significant limitations, but this isn’t exposed to developers on Safari.

It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are transferable. If your use case doesn’t require passing around functions (and if you can’t find a way to work around that), many workloads which would benefit from multithreading in another language will likely similarly benefit from JS threads (Web Workers, Node’s Worker Threads, etc). The biggest determining factor at that point is whether the overhead of instantiating them, and of message passing, is worth it. (And the latter is often a lot less than people realize; in my experience it’s almost universally faster than crossing a WASM/FFI-type of boundary.)

On what engine have you seen postmessage be faster than a WASM/JS boundary? It’s at least an order of magnitude slower on Chrome/V8, even when a call needs to pass significant strings into WASM (microseconds vs hundreds of ns). It’s also worth noting that postmessage is itself an FFI boundary that requires a JS to C++ transition on every engine I’m aware of.

I’ve seen in on Node 16 (also V8) trying both purpose-built and custom bindings to libraries built in Rust, C, C++ and Go. All of the purpose built libraries acknowledge there’s an overhead to cross the native/WASM boundary. In my experience, measuring extensively, postMessage with native runtime objects outperforms any other ser/de solution that works with JS values.

> The web always feels terrible compared to a native app

'always' is certainly not true. Yes, with modern frameworks it is very easy to build websites which are slow. But it is also possible to build websites with butter smooth animations and instant responses.

I hope that in the future we will get frameworks that make it easier to create lightweight web apps, so that we will see more high performance apps.

I made a another comment further down, but basically web apps can’t run as fast as native apps for a variety of reasons.

One reason is the thread model. There are two main threads that need to be synchronized (browser main thread and JS main thread) which will always be slower than a single main thread.

Another reason is that layout and measurement of elements in HTML is really complicated. Native apps heavily encourage deferred measurement which lets the app measure and lay itself out once per render pass. In JavaScript, layouts may need to happen immediately based on what properties of the dom you’re reading and setting.

I think nobody will argue against, that the majority of native apps are faster than web apps. But the key point isn't faster, but how much is fast enough.

In general, 60fps is considered sufficient for smooth rendering and even 5 years ago, mobile hardware was fast enough for 60 fps web page rendering. However, many web pages a built in ways, that the browsers can't achieve that goal.

So yes, it is harder for developers to create a pleasant experience and as a result there are more bad apples in the web app basket.

I disagree. Yes, if you have a static webpage and all you need to do is scroll, then you can easily get 60 fps, notably because the scrolling is handled natively by the browser and basically is just a translation on the GPU. If the web app accepts user input, especially touch with dragging, then the page will not feel native with the current batch of browsers for the reasons I mentioned above.

You don’t have to always use the DOM. You can render in another thread, or even run compute in another thread and use the animation frame system to handle updates.

Having said that, maybe a little less than 10 years ago, we achieved the desired performance with touch-screen dragging of DOM elements. I don’t remember specifics, but we didn’t use any frameworks.

So what would be needed to prove you wrong?

How about a 240fps video of a 60Hz display, with 2 implementations

1. Qt

2. Web

Both times a finger dragging a slider from point A to point B?

I would want to see an iOS app that renders 1000 items in a list, with each item pushing to the navigation stack when clicked. And then I would want to see the same thing implemented in the browser with similar responsiveness on iOS Safari.

Writing this out made me realize another limitation of the browser: the page unloads when navigating, so going “back” can be a pain / impossible depending on the circumstances.

Actually, the biggest issue here is writing a native iOS app, due to the limitations enforced by Apple. Browsers on iOS are also a big pain, because all iOS browsers use the Safari rendering engine and the users don't even have the choice to use anything else.

However, you wrote that 'the page unloads when navigating' which made me wonder, how much you know about frontend development, because the pattern to prevent browsers from navigating is such a common topic and there are multiple solution patterns, all well understood by professional frontend developers:

- preventDefault

- return false

- use anchors

The 1000 item list is indeed a problem frontend developers have to be aware of. Modern flagship smartphones may have the capability to render such lists, but less powerful devices can't handle the load in a 60fps fashion. So you have to build list views that render only the visible part of the list. In the end, you have to do that anyway, because even for high-end devices there are limits to what they can show, but many web-components are not build with such scenarios in mind. And that is certainly one of the reasons why there are so many web apps with slow performance rendering.

The web solved software distribution. Full stop. There only remain the edge cases, and that's where webasm wants to help.

Sun/Java wanted badly to solve this problem, but tried to do too much too soon. Java gave devs in 1999 cutting edge OOP tools for doing GUIs (e.g. Swing) but distribution was always the problem. Installing and running browser plugins was always error prone, and it turned out the browser was itself just good enough to deliver value, so it won. (With the happy side-effect of giving the world-wide community of devs one of the gooeyist languages ever to express their fever dreams of what application code should be).

The question in my mind is whether there is enough demand for the kinds of software webasm enables, especially given that other routes of distribution (app stores) have filled in the gaps of what the web delivers, and are generally a lot more pleasant and predictable to native devs.

I'm not really equipped to predict anything, but I think recent surge in popularity of simple RISC-y[1] architectures like ARM will allow the WebAssembly standard to stay small yet efficient. I'm hopeful, but standards often have a way of not keeping up with the newest technology so we'll see.

[1] https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...

I don't expect ARM to have much effect here. The wasm instruction set is basically a low-level compiler intermediate representation, and to go from that to machine code for x86 or ARM is about equally difficult in both cases.

Well, here is a related talk: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Reply on news.ycombinator.com