11 ms·

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 compil

by 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.