5 ms·

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 execu

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?

halpert 5y ago
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.
- jsheard 5y ago
  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.
  - danielvaughn 5y ago
    Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.
    - jsheard 5y ago
      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.
  - halpert 5y ago
    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.
- nicoburns 5y ago
  > 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.
  - kitsunesoba 5y ago
    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.
    - themerone 5y ago
      So, basically everything.
      - kitsunesoba 5y ago
        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.
  - halpert 5y ago
    Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.
    - acdha 5y ago
      Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.
      - 5y ago
- eyelidlessness 5y ago
  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).
  - halpert 5y ago
    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.
    - amelius 5y ago
      Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)
    - jacobolus 5y ago
      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.
  - Uehreka 5y ago
    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”.
- arendtio 5y ago
  > 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.
  - halpert 5y ago
    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.
    - arendtio 5y ago
      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.
      - halpert 5y ago
        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.
brrrrrm 5y ago
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_computer https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...
- pjscott 5y ago
  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.
javajosh 5y ago
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.
MauranKilom 5y ago
Well, here is a related talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

halpert 5y ago

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.

jsheard 5y ago
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.
- danielvaughn 5y ago
  Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.
  - jsheard 5y ago
    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.
- halpert 5y ago
  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.
nicoburns 5y ago
> 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.
- kitsunesoba 5y ago
  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.
  - themerone 5y ago
    So, basically everything.
    - kitsunesoba 5y ago
      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.
- halpert 5y ago
  Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.
  - acdha 5y ago
    Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.
    - 5y ago
eyelidlessness 5y ago
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).
- halpert 5y ago
  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.
  - amelius 5y ago
    Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)
  - jacobolus 5y ago
    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.
- Uehreka 5y ago
  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”.
arendtio 5y ago
> 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.
- halpert 5y ago
  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.
  - arendtio 5y ago
    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.
    - halpert 5y ago
      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.

brrrrrm 5y ago

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_computer https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...

pjscott 5y ago
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.

javajosh 5y ago

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.

MauranKilom 5y ago

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