5 ms·

Do we need text (HTML is text) and Javascript? Why can't be browsers used only to run native binary apps? Wouldn't that be more efficient? And even easier to d

Do we need text (HTML is text) and Javascript? Why can't be browsers used only to run native binary apps? Wouldn't that be more efficient? And even easier to develop for?

8organicbits 3y ago
WebAssembly already exists. It's easier for certain use cases, but not most. It gives good performance, but worse than native software outside the browser.
- wewxjfq 3y ago
  WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.
  - flohofwoe 3y ago
    Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.
- pjmlp 3y ago
  And after a decade the tooling still sucks, comparing with the development experience of native code.
  - flohofwoe 3y ago
    That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)
    - pjmlp 3y ago
      Like I say, the tooling sucks. I am well aware of that workflow. We can walk with a cane, doesn't mean walking without it isn't much better.
      - flohofwoe 3y ago
        The single parts are all there (but only since very recently), now they just need to be connected through a VSCode extension. I cobbled such a workflow together myself [1] with a couple of python scripts and existing VSCode extensions which is good enough for me. In the end it's up to IDE vendors to provide a similar workflow. [1] https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
        pjmlp 3y ago
        Yeah, it only covers C and C++, solves your specific use case, and still doesn't change the fact the tooling sucks for everyone else, with exception of something like Blazor or Unity.
- flohofwoe 3y ago
  > worse than native software outside the browser ...for typical portable C code the performance difference is surprisingly small though (within 20% or so). The main advantage of native compilation targets is that you have more "manual optimization potential" via non-standard language extensions like builtins and intrinsics (usually at the cost of portability and compiler compatibility).
troupo 3y ago
We've tried that already with several technologies. It has always been a disaster.
- MrBuddyCasino 3y ago
  Nacl worked fine, but was limited to x86.
  - bmacho 3y ago
    Flash and java worked fine too, but noone bothered to write a secure runtime.
onion2k 3y ago
And even easier to develop for? We don't really need to speculate - just look at mobile apps. They're binaries. They're relatively easy to develop, but we need gatekeepers like Google and Apple verifying they're safe, and the quality is horrible at the low end. And devs need to pay an annual fee to distribute them. Browsers already support something very similar (plugins via app stores) but they get very little love because making a website is the same and the only benefits of making a plugin are too niche for many things to actually need.
- conradfr 3y ago
  > And devs need to pay an annual fee to distribute them. Only with Apple.
  - pjmlp 3y ago
    You also have to pay for PlayStore, Windows Store, Playstation, Nintendo, XBox.
    - conradfr 3y ago
      I don't know about the others but the Play Store is a one time $25 fee.
      - pjmlp 3y ago
        Anual or one time, it is still a fee. On the consoles, not only you have to prove worthy of the platform, have to sign the NDAs, and then rent the devkits.
- DeathArrow 3y ago
  Apps for web wouldn't need app stores. You just point the browser to an URL, download and run. The browser would just isolate the app.
baz00 3y ago
As purely an end user, yes. I don't want to run another virtual machine that eats up RAM, has worse performance and battery life than something natively compiled and generally serves only the interests of the person servicing it to me. I want apps that are 100% native and work when occasionally connected. And I want the www to go back to servicing content, not apps and garbage to me. I don't want a gigabyte RAM footprint Electron app that ships Rust in webassembly to read emails when my current mail client used 77 meg of RAM and just works. I don't want 50 browser engines running on my phone. I think as an industry we've lost our way and turned to crack smoking crazy.
- kaba0 3y ago
  > than something natively compiled Yet, basically every hot enough method will be run as JIT compiled native code.
  - baz00 3y ago
    Eventually. At the end users's cost of time, memory, CPU and laggy ass performance while the JIT process is running. This is done on potentially millions of machines multiple times a day. Which is my point about it serving the needs of the publisher, not the end user.
    - kaba0 3y ago
      > This is done on potentially millions of machines multiple times a day And? Your car is working at an average of 20-30% of thermal efficiency, yet the benefit you get greatly outweighs the costs, doesn’t it?
      - baz00 3y ago
        That's not even an analogous argument.
- crabmusket 3y ago
  I also want a www of content, but as well as a www of apps. The web is too good to give up. The idea that I can send you a URL into an application state, or navigate between states of different applications, is really cool. Somehow having more separation between content and applications sounds ontologically impossible, if desirable.
kaba0 3y ago
Wasm is not more efficient for many use cases than regular old JS. HTML is text is pretty meaningless - it is parsed into the DOM, which is efficiently represented in native code by the browser. And this DOM - with all its warts - is the biggest benefit of the web, it’s standard, accessible, available everywhere. WASM can only access it through JS, foregoing its benefits, while drawing on a canvas would kill everything that makes the web introspectable.
- cdogl 3y ago
  Mostly agree with your comment, but: > WASM can only access it through JS, foregoing its benefits Is this a fundamental limitation of WASM? I assume browsers will one day expose a native DOM API.
  - kaba0 3y ago
    WasmGC is now available, so I guess it can also be solved sometime in the future, and I wouldn’t mind it at all. Though we would need much better wasm debug tooling, similarly to JS consoles — today’s minified, obfuscated JS is not much better than machine code, but at least with the tooling we can sort of touch into the internals. I would like to keep that property of the web.
    - ncruces 3y ago
      WASM can bundle DWARF sections, which enable stack traces with line numbers, step debugging, profiling…
  - flohofwoe 3y ago
    > I assume browsers will one day expose a native DOM API. TBH, that's extremely unlikely to happen. The entire DOM is built around the Javascript object model, trying to map the DOM to a C-style API would be possible, but inconvient to use and performance-wise it really wouldn't make a difference compared to going through a JS shim (since performance will be dominated by the browser-intenal DOM implementation, not by the user code manipulating it). A 'WASM-native' WebGPU API would make a lot more sense, but again, that's extremely unlikely to happen. The currently required Javascript shim might still disappear, but only because it might be generated automatically under the hood in the future.
jbergens 3y ago
Do you really want the thousands of bugs that would occur if we shipped a real binary to each device? And all security problems? Sorry, the FooApp 1.1 does not support your iPhone 12. It also crashes on Samsung Galaxy 21 and lower and has a huge security problem on Windows 10 when using an Intel Core i5.
flohofwoe 3y ago
Text parsing isn't the bottleneck: https://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html https://mozakai.blogspot.com/2013/05/the-elusive-universal-w... (this blog post is pre-WASM, but the main advantage of WASM vs asm.js isn't that WASM is a binary format or even better performance than JS, but that Javascript can focus on being a language again, while WASM can focus on being a compile target)

Do we need text (HTML is text) and Javascript? Why can't be browsers used only to run native binary apps? Wouldn't that be more efficient? And even easier to develop for?

8organicbits 3y ago

WebAssembly already exists. It's easier for certain use cases, but not most. It gives good performance, but worse than native software outside the browser.

wewxjfq 3y ago
WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.
- flohofwoe 3y ago
  Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.
pjmlp 3y ago
And after a decade the tooling still sucks, comparing with the development experience of native code.
- flohofwoe 3y ago
  That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)
  - pjmlp 3y ago
    Like I say, the tooling sucks. I am well aware of that workflow. We can walk with a cane, doesn't mean walking without it isn't much better.
    - flohofwoe 3y ago
      The single parts are all there (but only since very recently), now they just need to be connected through a VSCode extension. I cobbled such a workflow together myself [1] with a couple of python scripts and existing VSCode extensions which is good enough for me. In the end it's up to IDE vendors to provide a similar workflow. [1] https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
      - pjmlp 3y ago
        Yeah, it only covers C and C++, solves your specific use case, and still doesn't change the fact the tooling sucks for everyone else, with exception of something like Blazor or Unity.
flohofwoe 3y ago
> worse than native software outside the browser ...for typical portable C code the performance difference is surprisingly small though (within 20% or so). The main advantage of native compilation targets is that you have more "manual optimization potential" via non-standard language extensions like builtins and intrinsics (usually at the cost of portability and compiler compatibility).

troupo 3y ago

We've tried that already with several technologies. It has always been a disaster.

MrBuddyCasino 3y ago
Nacl worked fine, but was limited to x86.
- bmacho 3y ago
  Flash and java worked fine too, but noone bothered to write a secure runtime.

onion2k 3y ago

And even easier to develop for? We don't really need to speculate - just look at mobile apps. They're binaries. They're relatively easy to develop, but we need gatekeepers like Google and Apple verifying they're safe, and the quality is horrible at the low end. And devs need to pay an annual fee to distribute them. Browsers already support something very similar (plugins via app stores) but they get very little love because making a website is the same and the only benefits of making a plugin are too niche for many things to actually need.

conradfr 3y ago
> And devs need to pay an annual fee to distribute them. Only with Apple.
- pjmlp 3y ago
  You also have to pay for PlayStore, Windows Store, Playstation, Nintendo, XBox.
  - conradfr 3y ago
    I don't know about the others but the Play Store is a one time $25 fee.
    - pjmlp 3y ago
      Anual or one time, it is still a fee. On the consoles, not only you have to prove worthy of the platform, have to sign the NDAs, and then rent the devkits.
DeathArrow 3y ago
Apps for web wouldn't need app stores. You just point the browser to an URL, download and run. The browser would just isolate the app.

baz00 3y ago

As purely an end user, yes. I don't want to run another virtual machine that eats up RAM, has worse performance and battery life than something natively compiled and generally serves only the interests of the person servicing it to me. I want apps that are 100% native and work when occasionally connected. And I want the www to go back to servicing content, not apps and garbage to me. I don't want a gigabyte RAM footprint Electron app that ships Rust in webassembly to read emails when my current mail client used 77 meg of RAM and just works. I don't want 50 browser engines running on my phone. I think as an industry we've lost our way and turned to crack smoking crazy.

kaba0 3y ago
> than something natively compiled Yet, basically every hot enough method will be run as JIT compiled native code.
- baz00 3y ago
  Eventually. At the end users's cost of time, memory, CPU and laggy ass performance while the JIT process is running. This is done on potentially millions of machines multiple times a day. Which is my point about it serving the needs of the publisher, not the end user.
  - kaba0 3y ago
    > This is done on potentially millions of machines multiple times a day And? Your car is working at an average of 20-30% of thermal efficiency, yet the benefit you get greatly outweighs the costs, doesn’t it?
    - baz00 3y ago
      That's not even an analogous argument.
crabmusket 3y ago
I also want a www of content, but as well as a www of apps. The web is too good to give up. The idea that I can send you a URL into an application state, or navigate between states of different applications, is really cool. Somehow having more separation between content and applications sounds ontologically impossible, if desirable.

kaba0 3y ago

Wasm is not more efficient for many use cases than regular old JS. HTML is text is pretty meaningless - it is parsed into the DOM, which is efficiently represented in native code by the browser. And this DOM - with all its warts - is the biggest benefit of the web, it’s standard, accessible, available everywhere. WASM can only access it through JS, foregoing its benefits, while drawing on a canvas would kill everything that makes the web introspectable.

cdogl 3y ago
Mostly agree with your comment, but: > WASM can only access it through JS, foregoing its benefits Is this a fundamental limitation of WASM? I assume browsers will one day expose a native DOM API.
- kaba0 3y ago
  WasmGC is now available, so I guess it can also be solved sometime in the future, and I wouldn’t mind it at all. Though we would need much better wasm debug tooling, similarly to JS consoles — today’s minified, obfuscated JS is not much better than machine code, but at least with the tooling we can sort of touch into the internals. I would like to keep that property of the web.
  - ncruces 3y ago
    WASM can bundle DWARF sections, which enable stack traces with line numbers, step debugging, profiling…
- flohofwoe 3y ago
  > I assume browsers will one day expose a native DOM API. TBH, that's extremely unlikely to happen. The entire DOM is built around the Javascript object model, trying to map the DOM to a C-style API would be possible, but inconvient to use and performance-wise it really wouldn't make a difference compared to going through a JS shim (since performance will be dominated by the browser-intenal DOM implementation, not by the user code manipulating it). A 'WASM-native' WebGPU API would make a lot more sense, but again, that's extremely unlikely to happen. The currently required Javascript shim might still disappear, but only because it might be generated automatically under the hood in the future.

jbergens 3y ago

Do you really want the thousands of bugs that would occur if we shipped a real binary to each device? And all security problems? Sorry, the FooApp 1.1 does not support your iPhone 12. It also crashes on Samsung Galaxy 21 and lower and has a huge security problem on Windows 10 when using an Intel Core i5.

flohofwoe 3y ago

Text parsing isn't the bottleneck: https://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html https://mozakai.blogspot.com/2013/05/the-elusive-universal-w... (this blog post is pre-WASM, but the main advantage of WASM vs asm.js isn't that WASM is a binary format or even better performance than JS, but that Javascript can focus on being a language again, while WASM can focus on being a compile target)