6 ms·

I disagree. When people start using native languages like C++ for the Web, they will quickly realize they could have just used C++ to begin with.

adventured 9y ago
Getting people to download and install traditional software is a substantial point of friction. Average users hate managing software installations, updating, fixing broken installations, dealing with malware, et al. The problem spans from the enterprise down to normal consumers. Browsers as a better software platform, will significantly accelerate the rate at which software eats everything. Most software should ideally just work, no installs, period. The browser can act as that platform and it can go a lot further than it has so far. More to the point, there is no other future outcome than the browser becoming that vehicle, nothing can stop it from moving that direction at this point. You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native.
- frozenport 9y ago
  What we really need is better web-store for applications. What actually runs in it is a different story that the end-user doesn't care about. MS really botched their attempt, by drastically restricting functionality of Windows Store apps, and insisting on verification. Indeed, MSVC could never be deployed on MS's own app store. When they sober up, we might have a better deployment environment.
- repsilat 9y ago
  Really this just points to a lack of vision on the part of operating systems people. There is no reason downloading, possibly "installing" (mostly caching?) and running "traditional software" couldn't be as frictionless as clicking on a link, but that's just not how the software and security model of Windows, OSX or Ubuntu (to name just the household names) are set up. Browsers probably will win, but mostly by accident and as a result of network effects rather than any inherent qualities. As a platform it's positively awful, though it is getting better in fits and starts. Ideally we'd have proper sandboxing, proper compilation, proper libraries, proper access to hardware. Alas, all of that good stuff is basically a historical footnote at this point.
  - bobajeff 9y ago
    I've been thinking lately there should be a file format that's just WebAssembly along with WebAssembly-versions of WebGL, Web Audio and WebRTC. With the goal of making the runtime simpler to implement for non-browser venders. While browser vendors could add a profile to run the format.
    - solarkraft 9y ago
      ... or to just load it up in the browser and skip the HTML part. Non-browser vendors will probably have to integrate browsers.
      - bobajeff 9y ago
        That completely misses the point which is a simpler format to implement and support.
  - colordrops 9y ago
    It's not either/or. The browsers will probably eventually be integrated into the OS until they are almost invisible. All apps will be web apps.
    - solarkraft 9y ago
      I hope the browser will be invisible soon, because I hate having it between me and my application.
    - arbie 9y ago
      Chrome must clearly see this as the end of the road on Windows and MacOS. What incentive do the OS vendors have to champion full-access APIs having feature parity for OS-level JS engines?
    - baq 9y ago
      There's a lisp machine story hiding somewhere over here.
  - 9y ago
- khedoros1 9y ago
  There are a lot of things that still need figured out. Installation performs the functions of conserving my bandwidth and giving me a way to manage the software through the OS. I select software because it does something that I want, in a way that I want it done. I avoid web-based software when possible because it has a tendency to shift underneath me and break the way that I want the software to work....or the company decides that it needs to pivot, and I lose access to something I was depending on. Software that installs comes closer to "just works" than software hosted online, IMO. Make it available in the repo/store/whatever, and that gets rid of a lot of install friction. > You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native. Throughput? Probably not. But please fix the dang latency. It makes software just painful.
- tensor 9y ago
  App stores will solve most of this, if they haven't already.
  - contrarian_ 9y ago
    Yeah, except for that 30% of your revenue vanishing.
farresito 9y ago
I haven't looked much into WebAssembly, but regardless of the native language that you use, your app will be cross-platform without having to put any extra effort, won't it? This solves one of the biggest pain points of native GUI development. While it's pretty amazing what QT has managed to accomplish, I still hear incompatibility problems between OSs.
- notatoad 9y ago
  It "solves" it by not solving it - WebAssembly doesn't do UIs, that component is still built in HTML. The wasm functions are just doing the expensive computation. I think there's been some work to build DOM apis in languages that compile to wasm, but for the most part the workflow is to create your UI in markup or standard javascript and then call out to wasm functions to do things, or else building the UI in WebGL (e.g. games)
  - solarkraft 9y ago
    And that's how it solves an additional problem. You don't have a GUI toolkit pre-defined if you start out with c++ (yes, it takes freedom, but gives ease of development, which seems to be today's currency).
  - clouddrover 9y ago
    > WebAssembly doesn't do UIs, that component is still built in HTML Your UI could be HTML, but equally it could be a WebGL-based UI. Some UI libraries already use OpenGL as a backend so adding support for a WebGL backend shouldn't be too hard.
    - solarkraft 9y ago
      Can you point me to them? Thinking about using HTML to build an app with good UX lets magic smoke leave my head.
      - baq 9y ago
        Qt should work.
colordrops 9y ago
You get several things with with Web Assembly that you don't get with a straight application: * Easy distribution without installation * No worries about dependencies for end users * Much more consistent, and in most cases, better security * Cross platform * No walled gardens
- AnIdiotOnTheNet 9y ago
  * Now you have signups, instead of installation * Only Linux end users have to care much about dependencies * You're kidding right? * Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on * There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions.
  - SquareWheel 9y ago
    This is a pretty poor response to the parent's arguments... >Now you have signups, instead of installation How are these mutually exclusive? Plenty of desktop software requires a signup first. And plenty of webapps do not require a login. >Only Linux end users have to care much about dependencies It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more. >You're kidding right? Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point. >Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately. >There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions. And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web.
    - AnIdiotOnTheNet 9y ago
      > How are these mutually exclusive? Plenty of desktop software requires a signup first. And plenty of webapps do not require a login. It isn't. My point is, signups are at least as inconvenient as having to install things, and are quite prevalent on the platform. It doesn't make much sense to credit the web's success on removing the need for installs. Hell, it was still super popular even when installing Flash was basically a requirement. > It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more. All of which is handled automatically for the user (and regardless is usually unnecessary and only done the way it is because of Microsoft's distribution license terms for DirectX). >Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point. OS's have always active updates, in Windows's case whether you want them or not, and plenty of security options. Web browsers have a huge attack surface that has been exploited at least as often as OSs. > Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately. Impressive. I guess all those frameworks out there that are meant to abstract away all the implementation quirks between IE's various iterations, Edge, Chrome, and FF are useless then? > And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web. Mobile web is still a goddamned garbage fire as far as I can tell. There's a reason all those popular web sites have native apps in the app store.
solarkraft 9y ago
I was going to say this is just for portability for average consumer facing applications you need shipped as easily as possible, but actually I've seen people developing "native" extensions for Node.js with WebAssembly.
imtringued 9y ago
You still need an abstraction layer between compiled program and the target architecture.
j_s 9y ago
Web browsers cross the uncanny valley home to 99+% of open-source, free-as-in-beer, and even commercially supported cross-platform GUI toolkits. This is due in part to the freedom to evolve new UI/UX concepts, but primarily because incentives align for polishing rough edges. Web browsers grew up with an always-on Internet connection -- continuously pushing updates to code and data. This has expanded to continuous updates "all the way down" (the native code browser auto-updating on top of an auto-updating OS). Rebuilding core features such as these, even if by selecting unencumbered open-source libraries, basically means winding up in nearly the same place (since browsers are competing to optimize their implementations). Finding a way to connect to the browser foundation underneath whatever layer in the stack begins feeling bloated is worth evaluating, but there are diminishing returns.

adventured 9y ago

Getting people to download and install traditional software is a substantial point of friction. Average users hate managing software installations, updating, fixing broken installations, dealing with malware, et al. The problem spans from the enterprise down to normal consumers. Browsers as a better software platform, will significantly accelerate the rate at which software eats everything. Most software should ideally just work, no installs, period. The browser can act as that platform and it can go a lot further than it has so far. More to the point, there is no other future outcome than the browser becoming that vehicle, nothing can stop it from moving that direction at this point. You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native.

frozenport 9y ago
What we really need is better web-store for applications. What actually runs in it is a different story that the end-user doesn't care about. MS really botched their attempt, by drastically restricting functionality of Windows Store apps, and insisting on verification. Indeed, MSVC could never be deployed on MS's own app store. When they sober up, we might have a better deployment environment.
repsilat 9y ago
Really this just points to a lack of vision on the part of operating systems people. There is no reason downloading, possibly "installing" (mostly caching?) and running "traditional software" couldn't be as frictionless as clicking on a link, but that's just not how the software and security model of Windows, OSX or Ubuntu (to name just the household names) are set up. Browsers probably will win, but mostly by accident and as a result of network effects rather than any inherent qualities. As a platform it's positively awful, though it is getting better in fits and starts. Ideally we'd have proper sandboxing, proper compilation, proper libraries, proper access to hardware. Alas, all of that good stuff is basically a historical footnote at this point.
- bobajeff 9y ago
  I've been thinking lately there should be a file format that's just WebAssembly along with WebAssembly-versions of WebGL, Web Audio and WebRTC. With the goal of making the runtime simpler to implement for non-browser venders. While browser vendors could add a profile to run the format.
  - solarkraft 9y ago
    ... or to just load it up in the browser and skip the HTML part. Non-browser vendors will probably have to integrate browsers.
    - bobajeff 9y ago
      That completely misses the point which is a simpler format to implement and support.
- colordrops 9y ago
  It's not either/or. The browsers will probably eventually be integrated into the OS until they are almost invisible. All apps will be web apps.
  - solarkraft 9y ago
    I hope the browser will be invisible soon, because I hate having it between me and my application.
  - arbie 9y ago
    Chrome must clearly see this as the end of the road on Windows and MacOS. What incentive do the OS vendors have to champion full-access APIs having feature parity for OS-level JS engines?
  - baq 9y ago
    There's a lisp machine story hiding somewhere over here.
- 9y ago
khedoros1 9y ago
There are a lot of things that still need figured out. Installation performs the functions of conserving my bandwidth and giving me a way to manage the software through the OS. I select software because it does something that I want, in a way that I want it done. I avoid web-based software when possible because it has a tendency to shift underneath me and break the way that I want the software to work....or the company decides that it needs to pivot, and I lose access to something I was depending on. Software that installs comes closer to "just works" than software hosted online, IMO. Make it available in the repo/store/whatever, and that gets rid of a lot of install friction. > You don't need something equivalent to maximum native performance to do what 99% of users want to do. The rare edge cases that need extreme performance will remain native. Throughput? Probably not. But please fix the dang latency. It makes software just painful.
tensor 9y ago
App stores will solve most of this, if they haven't already.
- contrarian_ 9y ago
  Yeah, except for that 30% of your revenue vanishing.

farresito 9y ago

I haven't looked much into WebAssembly, but regardless of the native language that you use, your app will be cross-platform without having to put any extra effort, won't it? This solves one of the biggest pain points of native GUI development. While it's pretty amazing what QT has managed to accomplish, I still hear incompatibility problems between OSs.

notatoad 9y ago
It "solves" it by not solving it - WebAssembly doesn't do UIs, that component is still built in HTML. The wasm functions are just doing the expensive computation. I think there's been some work to build DOM apis in languages that compile to wasm, but for the most part the workflow is to create your UI in markup or standard javascript and then call out to wasm functions to do things, or else building the UI in WebGL (e.g. games)
- solarkraft 9y ago
  And that's how it solves an additional problem. You don't have a GUI toolkit pre-defined if you start out with c++ (yes, it takes freedom, but gives ease of development, which seems to be today's currency).
- clouddrover 9y ago
  > WebAssembly doesn't do UIs, that component is still built in HTML Your UI could be HTML, but equally it could be a WebGL-based UI. Some UI libraries already use OpenGL as a backend so adding support for a WebGL backend shouldn't be too hard.
  - solarkraft 9y ago
    Can you point me to them? Thinking about using HTML to build an app with good UX lets magic smoke leave my head.
    - baq 9y ago
      Qt should work.

colordrops 9y ago

You get several things with with Web Assembly that you don't get with a straight application: * Easy distribution without installation * No worries about dependencies for end users * Much more consistent, and in most cases, better security * Cross platform * No walled gardens

AnIdiotOnTheNet 9y ago
* Now you have signups, instead of installation * Only Linux end users have to care much about dependencies * You're kidding right? * Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on * There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions.
- SquareWheel 9y ago
  This is a pretty poor response to the parent's arguments... >Now you have signups, instead of installation How are these mutually exclusive? Plenty of desktop software requires a signup first. And plenty of webapps do not require a login. >Only Linux end users have to care much about dependencies It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more. >You're kidding right? Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point. >Sure, if you only target one browser your code will probably work more or less the same on that one browser on at least some of the OSs it runs on Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately. >There aren't any walled gardens in PC Destkop land worth talking about, other than maybe the package repositories of Linux distributions. And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web.
  - AnIdiotOnTheNet 9y ago
    > How are these mutually exclusive? Plenty of desktop software requires a signup first. And plenty of webapps do not require a login. It isn't. My point is, signups are at least as inconvenient as having to install things, and are quite prevalent on the platform. It doesn't make much sense to credit the web's success on removing the need for installs. Hell, it was still super popular even when installing Flash was basically a requirement. > It's rare to find a game that doesn't start by installing DirectX, Visual C++ Redistributable, and more. All of which is handled automatically for the user (and regardless is usually unnecessary and only done the way it is because of Microsoft's distribution license terms for DirectX). >Modern browsers have powerful sandboxes and always-active updates to address security threats. Sounding indignant isn't actually making a point. OS's have always active updates, in Windows's case whether you want them or not, and plenty of security options. Web browsers have a huge attack surface that has been exploited at least as often as OSs. > Browsers are very standardized these days. It's very rare that I write code that doesn't work cross-plat immediately. Impressive. I guess all those frameworks out there that are meant to abstract away all the implementation quirks between IE's various iterations, Edge, Chrome, and FF are useless then? > And on mobile? Remember we're talking true cross platform here. Apple's App Store has far more limitations than you'll run into on the web. Mobile web is still a goddamned garbage fire as far as I can tell. There's a reason all those popular web sites have native apps in the app store.

solarkraft 9y ago

I was going to say this is just for portability for average consumer facing applications you need shipped as easily as possible, but actually I've seen people developing "native" extensions for Node.js with WebAssembly.

imtringued 9y ago

You still need an abstraction layer between compiled program and the target architecture.

j_s 9y ago

Web browsers cross the uncanny valley home to 99+% of open-source, free-as-in-beer, and even commercially supported cross-platform GUI toolkits. This is due in part to the freedom to evolve new UI/UX concepts, but primarily because incentives align for polishing rough edges. Web browsers grew up with an always-on Internet connection -- continuously pushing updates to code and data. This has expanded to continuous updates "all the way down" (the native code browser auto-updating on top of an auto-updating OS). Rebuilding core features such as these, even if by selecting unencumbered open-source libraries, basically means winding up in nearly the same place (since browsers are competing to optimize their implementations). Finding a way to connect to the browser foundation underneath whatever layer in the stack begins feeling bloated is worth evaluating, but there are diminishing returns.