6 ms·

When the topic discussed is software that can run on any platform, you have to care about UNIX desktop, otherwise you're cheating - or at least not providing a

When the topic discussed is software that can run on any platform, you have to care about UNIX desktop, otherwise you're cheating - or at least not providing a solution to the problem as was stated.

pjmlp 10y ago
No, the topic being discussed is "Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do." Which given the increase in mobile OS across the planet and their use of native apps, is something I wish will turn the tide.
- TuringTest 10y ago
  Once you run WebAssembly as a virtual machine providing a core API without a windowing system, it barely counts as a browser anymore. There's nothing in its essence that makes it different from the virtual machines in Java or C# or Python, other than having several alternate working implementations, available in every device that runs a modern browser (true, the latest wouldn't count as "native", but nothing stops you from running a headless WebAssembly instance directly on the metal without the intermediate application layer). The solutions you proposed (iOS, Android and UWP) may count as native, but they definitely don't count as "universal" in the same way that WebAssembly would.
  - pjmlp 10y ago
    There is a big difference from all other VMs, a lowest common denominator UI/UX across all devices, even the JVM does better in regards to integration with the host OS. This has not changed since the HTML5 is going to change the world kind of thing, and I doubt WebAssembly will change that. Simple stuff like Web Components are still pretty much a Chrome thing and WIP everywhere else, let alone more specific OS APIs.
    - TuringTest 10y ago
      Uh? Why would that make it any different from providing an "official" GUI API with the virtual machine, like Java Swing and MS XAML (or whatever Microsoft calls its current View stack nowadays)? Are you talking about implementations not being there (yet, though that could change with time) or is there a fundamental difference in the platform architecture that I'm unaware of?
      - pjmlp 10y ago
        I am talking about the full stack from the lower layers all the way up, integration with peripherals, audio engines,GPGPU, 3D that doesn't look like Glide demos, ability to fully utilize any kid of wireless communication,composition engine, GUI components, security, 2D acceleration that is guaranteed to always work, ...
        TuringTest 10y ago
        Doesn't UWP also try to provide all of that? The only difference I see is that HTML5 comes with a formally defined standard, so it is possible to build more than one implementation by different parties, while UWP is proprietary. I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.
        pjmlp 10y ago
        > I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea. It is not that is a terrible idea, it is that it will never happen, thus always being a 2nd class UI/UX. I am still waiting for a version of WebGL that can actually fully use my graphics card, WebGL 2.0 surely isn't it yet. Or for web components to be ready across devices and multiple browsers. How many years has Google been talking about them at Google IO now?
        10y ago

When the topic discussed is software that can run on any platform, you have to care about UNIX desktop, otherwise you're cheating - or at least not providing a solution to the problem as was stated.

pjmlp 10y ago

No, the topic being discussed is "Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do." Which given the increase in mobile OS across the planet and their use of native apps, is something I wish will turn the tide.

TuringTest 10y ago
Once you run WebAssembly as a virtual machine providing a core API without a windowing system, it barely counts as a browser anymore. There's nothing in its essence that makes it different from the virtual machines in Java or C# or Python, other than having several alternate working implementations, available in every device that runs a modern browser (true, the latest wouldn't count as "native", but nothing stops you from running a headless WebAssembly instance directly on the metal without the intermediate application layer). The solutions you proposed (iOS, Android and UWP) may count as native, but they definitely don't count as "universal" in the same way that WebAssembly would.
- pjmlp 10y ago
  There is a big difference from all other VMs, a lowest common denominator UI/UX across all devices, even the JVM does better in regards to integration with the host OS. This has not changed since the HTML5 is going to change the world kind of thing, and I doubt WebAssembly will change that. Simple stuff like Web Components are still pretty much a Chrome thing and WIP everywhere else, let alone more specific OS APIs.
  - TuringTest 10y ago
    Uh? Why would that make it any different from providing an "official" GUI API with the virtual machine, like Java Swing and MS XAML (or whatever Microsoft calls its current View stack nowadays)? Are you talking about implementations not being there (yet, though that could change with time) or is there a fundamental difference in the platform architecture that I'm unaware of?
    - pjmlp 10y ago
      I am talking about the full stack from the lower layers all the way up, integration with peripherals, audio engines,GPGPU, 3D that doesn't look like Glide demos, ability to fully utilize any kid of wireless communication,composition engine, GUI components, security, 2D acceleration that is guaranteed to always work, ...
      - TuringTest 10y ago
        Doesn't UWP also try to provide all of that? The only difference I see is that HTML5 comes with a formally defined standard, so it is possible to build more than one implementation by different parties, while UWP is proprietary. I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.
        pjmlp 10y ago
        > I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea. It is not that is a terrible idea, it is that it will never happen, thus always being a 2nd class UI/UX. I am still waiting for a version of WebGL that can actually fully use my graphics card, WebGL 2.0 surely isn't it yet. Or for web components to be ready across devices and multiple browsers. How many years has Google been talking about them at Google IO now?
        10y ago