6 ms·

I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, runnin

I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......

nathancahill 11y ago
It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.
- ino 11y ago
  Big regression in accessibility, copy/paste, automatic translation, everything that makes the web uniquely great.
  - jacobolus 11y ago
    The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.) They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of. In short, web applications are inherently second-class citizens on every platform. BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.
    - jdc 11y ago
      Yeah, I wouldn't mind being able to write something like QT for the web.
      - discreteevent 11y ago
        https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-...
    - pdkl95 11y ago
      > web applications are inherently second-class citizens on every platform. Yes. By design. If a webpage can impersonate a local app, you have a serious security problem. > They make it hard for users to load/save local data There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc. > They don’t interoperate with other applications on the system. That's a feature. > They flagrantly violate UI design conventions on every platform. The user agent can render the page however it wants. This is a feature. > They can’t access most local hardware devices. Are you trying to introduce even more security problems? > They are difficult or impossible to build proper cryptographic primitives on top of. That's not the place you should be implementing crypo. > Accidentally pressing the back button can destroy hours of user work. Ok, that one would be nicer to fix, but that's a problem for the browser, and shouldn't impact the page at all. -- If you want to develop software that uses more than the web can provide, you should choose a platform that actually provides those features. There is a trade-off, of course, but making that kind of decision is a an important part of software engineering. While many people have been ignoring some or all of the security aspects of programming, it is important to remember that anything connected (even indirectly) to a network is under attack, so security must be considered first.
      - deleted 11y ago
        [deleted]
      - simula67 11y ago
        I think what your parent comment was saying was that : 'even though web is a great solution to many problems that can be solved with software, it has its limitations'. Clearly the problems s/he mentioned are a source of pain for some users, and many of them do not exist in the native application platform. Even if those trade-offs look unreasonable to you, it may not look so to many others. If we have more data to support the statement that somehow the web is always superior to native, then this discussion can move forward. Without it we are more likely going around in circles.
- aikah 11y ago
  Flash should definitely export to WebAssembly and retire its player once and for all. Whether Adobe is ready to do that is another issue. Flash is still an excellent IDE for artists. And I enjoy some "creativity" on the web. The "everything's flat and like the next site because Bootstrap" web is getting old.
- s3th 11y ago
  It's possible to eschew the DOM even today with just JavaScript & <canvas> [0]! While this would be possible with wasm & WebGL as well, we're working to build something that integrates well into the open web platform. Check out #3 from our high-level goals [1]. [0]: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas [1]: https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
  - corysama 11y ago
    Doesn't flipboard still use the DOM to do the initial rasterization? I thought it just used canvas as a caching layer.
- krapp 11y ago
  Flash and Java applets were (and are) kind of terrible, but the basic premise of compiled binary applications accessible as embeds in a browser is, I think, potentially more revolutionary than even that of the web as linked documents. It just may be that the first iteration of this was too primitive to realize its true potential, and the traditional javascript run "web app" is just an awkward interstitial phase we have to get past. Although... I also think that at some point the line between the web, browser and operating system might have to blur or disappear entirely.
s3th 11y ago
We're working hard to make sure that WebAssembly is a first-class citizen in the open web platform in ways that other native execution environments didn't accomplish. For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that wasm plays well with everything that's great about the web today. [0]: https://github.com/WebAssembly/design/blob/master/Web.md https://github.com/WebAssembly/design/blob/master/Web.md (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
- spicyj 11y ago
  > As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly. Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.
  - s3th 11y ago
    We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform. [0]: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
    - Nrpf 11y ago
      Any chance python could be a first class citizen here, or are we looking at more compile-able languages?
      - s3th 11y ago
        Check out the last paragraph of "Is WebAssembly only for C/C++ Programmers?" in the FAQ [0]. The tl;dr is that you'll be able to port a Python interpreter (that is itself written in C) to WebAssembly from day 1, but a more robust solution that relies on WebAssembly GC will have to wait until after the MVP. [0]: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
spankalee 11y ago
This would be terrible for the web from crawl-ability, accessibility, extension and OS integration points of view. The web is awesome because it's document based, and largely because of links embedded in a open document format. Get rid of the document and you get rid of readable links, web crawlers, find-in-page, screen readers, and on and on...
- corysama 11y ago
  This assumes what you want is documents. The web is already great for documents. Meanwhile, a lot of people also want apps. You can bemoan document viewers being stretched beyond reason into app platforms, but it already happened over a decade ago and shows no sign of slowing. It's time to just deal with it. With wasm and webgl, these document viewers can at least be slightly less crappy app platforms.
- JupiterMoon 11y ago
  Wouldn't web crawlers prefer read access to content databases?
chmod888 11y ago
As someone who works in VR this is something I've been thinking about a lot. We need an open platform for creating and sharing VR content which is 3D rendered. WebAssembly + WebVR + WebGL might be the beginning of that platform.
h1282227 11y ago
The reason for that is very simple. asm.js has no access to the DOM. You have no choice other than to use WebGL. Guess what problem web assembly is trying to solve?

nathancahill 11y ago

It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.

ino 11y ago
Big regression in accessibility, copy/paste, automatic translation, everything that makes the web uniquely great.
- jacobolus 11y ago
  The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.) They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of. In short, web applications are inherently second-class citizens on every platform. BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.
  - jdc 11y ago
    Yeah, I wouldn't mind being able to write something like QT for the web.
    - discreteevent 11y ago
      https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-...
  - pdkl95 11y ago
    > web applications are inherently second-class citizens on every platform. Yes. By design. If a webpage can impersonate a local app, you have a serious security problem. > They make it hard for users to load/save local data There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc. > They don’t interoperate with other applications on the system. That's a feature. > They flagrantly violate UI design conventions on every platform. The user agent can render the page however it wants. This is a feature. > They can’t access most local hardware devices. Are you trying to introduce even more security problems? > They are difficult or impossible to build proper cryptographic primitives on top of. That's not the place you should be implementing crypo. > Accidentally pressing the back button can destroy hours of user work. Ok, that one would be nicer to fix, but that's a problem for the browser, and shouldn't impact the page at all. -- If you want to develop software that uses more than the web can provide, you should choose a platform that actually provides those features. There is a trade-off, of course, but making that kind of decision is a an important part of software engineering. While many people have been ignoring some or all of the security aspects of programming, it is important to remember that anything connected (even indirectly) to a network is under attack, so security must be considered first.
    - deleted 11y ago
      [deleted]
    - simula67 11y ago
      I think what your parent comment was saying was that : 'even though web is a great solution to many problems that can be solved with software, it has its limitations'. Clearly the problems s/he mentioned are a source of pain for some users, and many of them do not exist in the native application platform. Even if those trade-offs look unreasonable to you, it may not look so to many others. If we have more data to support the statement that somehow the web is always superior to native, then this discussion can move forward. Without it we are more likely going around in circles.
aikah 11y ago
Flash should definitely export to WebAssembly and retire its player once and for all. Whether Adobe is ready to do that is another issue. Flash is still an excellent IDE for artists. And I enjoy some "creativity" on the web. The "everything's flat and like the next site because Bootstrap" web is getting old.
s3th 11y ago
It's possible to eschew the DOM even today with just JavaScript & <canvas> [0]! While this would be possible with wasm & WebGL as well, we're working to build something that integrates well into the open web platform. Check out #3 from our high-level goals [1]. [0]: https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas [1]: https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
- corysama 11y ago
  Doesn't flipboard still use the DOM to do the initial rasterization? I thought it just used canvas as a caching layer.
krapp 11y ago
Flash and Java applets were (and are) kind of terrible, but the basic premise of compiled binary applications accessible as embeds in a browser is, I think, potentially more revolutionary than even that of the web as linked documents. It just may be that the first iteration of this was too primitive to realize its true potential, and the traditional javascript run "web app" is just an awkward interstitial phase we have to get past. Although... I also think that at some point the line between the web, browser and operating system might have to blur or disappear entirely.

s3th 11y ago

We're working hard to make sure that WebAssembly is a first-class citizen in the open web platform in ways that other native execution environments didn't accomplish. For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that wasm plays well with everything that's great about the web today. [0]: https://github.com/WebAssembly/design/blob/master/Web.md https://github.com/WebAssembly/design/blob/master/Web.md (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)

spicyj 11y ago
> As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly. Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.
- s3th 11y ago
  We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform. [0]: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
  - Nrpf 11y ago
    Any chance python could be a first class citizen here, or are we looking at more compile-able languages?
    - s3th 11y ago
      Check out the last paragraph of "Is WebAssembly only for C/C++ Programmers?" in the FAQ [0]. The tl;dr is that you'll be able to port a Python interpreter (that is itself written in C) to WebAssembly from day 1, but a more robust solution that relies on WebAssembly GC will have to wait until after the MVP. [0]: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

spankalee 11y ago

This would be terrible for the web from crawl-ability, accessibility, extension and OS integration points of view. The web is awesome because it's document based, and largely because of links embedded in a open document format. Get rid of the document and you get rid of readable links, web crawlers, find-in-page, screen readers, and on and on...

corysama 11y ago
This assumes what you want is documents. The web is already great for documents. Meanwhile, a lot of people also want apps. You can bemoan document viewers being stretched beyond reason into app platforms, but it already happened over a decade ago and shows no sign of slowing. It's time to just deal with it. With wasm and webgl, these document viewers can at least be slightly less crappy app platforms.
JupiterMoon 11y ago
Wouldn't web crawlers prefer read access to content databases?

chmod888 11y ago

As someone who works in VR this is something I've been thinking about a lot. We need an open platform for creating and sharing VR content which is 3D rendered. WebAssembly + WebVR + WebGL might be the beginning of that platform.

h1282227 11y ago

The reason for that is very simple. asm.js has no access to the DOM. You have no choice other than to use WebGL. Guess what problem web assembly is trying to solve?