9 ms·

> If you built an applet in one of these technologies, you didn’t really build a web application. You had a web page with a chunk cut out of it, and your applet

> If you built an applet in one of these technologies, you didn’t really build a web application. You had a web page with a chunk cut out of it, and your applet worked within that frame. You lost all of the benefits of other web technologies; you lost HTML, you lost CSS, you lost the accessibility built into the web. But that's also true of an application which relies on WebAssembly (or JavaScript): it loses all the benefits of the web, because in a very real sense it's no longer a web site, but is instead a program running in a web page. WebAssembly or JavaScript, neither is document-oriented; neither is linkable; neither is cacheable. It's Flash, all over again — except at least with Flash one could disable it and sites were okay. with WebAssembly & JavaScript, every site uses them for everything, meaning we get to choose between allowing a site to execute code on our CPUs, or seeing naught but a 'This page requires JavaScript' notice. It is the return of Flash, and that's a bad thing. We thought we'd won the war, but really we just won a battle.

j45 8y ago
Sometimes a program running in the browser will be valuable when it's full window. Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems.
- black_puppydog 8y ago
  Yeah, or a full version of a monero miner...
- cmiles74 8y ago
  In my experience, the application-on-browser products consume far more CPU and RAM than the application-on-OS products. For me, that's a pretty big deal: I need the laptop to run as long as possible on a charge. Right now, I would complain if I _had_ to run a full version of Word or Excel in the browser. Perhaps Web Assembly will drive this power usage down. But as it stands now, I actively avoid more than one of these app-on-browser products at a time.
  - baybal2 8y ago
    Well, modern JS is MORE performant that classical scripting languages in benchmark cases, but the fact is that your browser freezes on half of js CRUDs that do data processing, while an analogous Perl application works at near light speed in comparison. In half cases like that, stuff like sorting, list comparison, deduplication are done in a way that will score low mark even by standards of first year university program. This is telling of web development industry's approach to doing business. The most horrid examples of "LAMP sweatshops" of 10 years ago pale in comparison to what the industry has devolved into these days. My own experience being an involuntary webdev for 3 years left me with following impressions: 1. Webdev is the largest commercial development niche in the whole tech industry. Everything else pales in comparison. It is also about making money quickly. A webapp or even a promo page SPA for a major consumer brand these days can cost up to $100k easily. $100k does not seem a lot to most people here, but such money can be well offered for a 1 month project for a team of of 6-8 professionals. 2. The industry is dominated by shops with 20 to 30 people headcount. Web dev studios generally don't scale much above that because of talent flight. Loss of a single senior dev who supervises hordes of lowest tier mule coders is often the end of a business for most of companies. 3. People from "big dotcom" world are near oblivious to ways of small web dev shops. For people who began their careers at 60k a year internships, getting into shoes of a person who does coding for 30k a year is impossible. 4. Talent flight and turnover is real. 5. This is all about really expensive quick and dirty code. 6. "The big dotcom" type of companies tried time and time again to tap into the market to extract rents, and with exception of Macrovision nobody ever succeeded. This is the reason Adobe is lobbying for unusable, unwieldy APIs in hopes of selling tooling for it.
    - kansface 8y ago
      If I could ask, where do you live? Your experiences don't reflect my own.
      - baybal2 8y ago
        Practiced for near 3 years in Canada, and continued for a half a year after in China. Quit webdev a year ago, now working in engineering consultancy.
- Eequei3i 8y ago
  > decrease our reliance on particular operating systems By replacing it with a poor simulacrum of an operating system. Browser APIs are an inefficient subset of libc and bsd sockets offer. And they provide near-zero interoperability with native applications. No filesystem access (beyond the clunky save-one-file dialog), no CLI, no IPC, nothing. That means browsers are building on top of operating systems while not interoperating with them.
  - throwaway2016a 8y ago
    > No filesystem access This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1] > No IPC WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally. Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC. > That means browsers are building on top of operating systems while not interoperating with them. While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one. [1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemDirectoryEntry https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...
    - TeMPOraL 8y ago
      > This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
- TeMPOraL 8y ago
  > Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems. I for one would, because the browser is an absolutely shitty interface. You're still forced into "there are tabs, which contain sandboxed documents" model of use. Interoperability is nonexistant, integration with machine capabilities is superficial and completely opaque to the user, the data model is hidden (where is my localStorage equivalent of the file browser again?), everything assumes you're constantly connected - it's a corporate wet dream, but for individuals, it's a nightmare.
  - j45 8y ago
    Nothings perfect, though. If operating systems aren't, I wouldn't expect browsers to be either. Creating mobile and/or offline first exoeriences for individuals isn't a pipe dream, it was possible and happened in the 90's when connectivity (dialup) informed content (largely offline or downloaded). I'm not looking at replacement, only reasonable substitutes, which I think will become useful similar to using Google docs on mobile and web.
  - yorwba 8y ago
    > where is my localStorage equivalent of the file browser again? The Firefox developer tools have a "storage" tab that lets you inspect the content of various databases associated with a website.
    - TeMPOraL 8y ago
      Default-disabled, read-only and scope-limited to domains your current tab works with, but I guess it's better than nothing.
- sidlls 8y ago
  Different psuedo-VMs, I mean browsers, operate differently even on the same specs for various technologies (CSS, JS). They already act effectively like "particular operating systems," except they're less efficient and more obnoxious to work with.
- sparkie 8y ago
  You web folk are mentally ill, with the desease known as Not Invented Here Syndrome. The w3c completely detests the idea of utilizing existing technologies that don't have their name on them. Whatever the technology, it MUST be reinvented (often badly) so it can be one of their standards. I've even seen WebVR pop up recently. I'm surprised nobody has standardized a WebOffice yet, but I assume it has been put on hold because of the magnitude of the task. Can be pretty sure we'll be seeing these in the coming years: WebStore: It's silly to have Google Play and the Apple store as separate things. In future, all apps will be written in WEB and distributed from WebStore. WebCoin: Bitcoin is great, but it exists separate from the web. We find the utterly unacceptable, and we are therefore publishing WebCoin so transactions are standardized across browsers. WebPilot: Self-driving cars, IN THE BROWSER!
  - sctb 8y ago
    This comment breaks a handful of guidelines and is not civil or substantive. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
EvanAnderson 8y ago
I envision horrible "all WASM" websites, just like the old "all Flash" websites, that won't have accessibility, won't be able to be linked to, etc. Worse, I envision this as being another step in the ad blocker arms race. Inevitably there are going to be websites that package an entire WASM-based browser that will need to be used to access the site, nullifying client-side ad and script blockers. I can see the pitch now-- "Keep your existing website but add our tools to prevent ad blockers!" (Edit: Typos. I should know better than to post from my phone by now. Grrr...)
- colanderman 8y ago
  It already is possible, with JavaScript. WASM doesn't change anything. And the fact that although it happens with JavaScript, it isn't pervasive, I think should assuage this fear.
  - toadworrier 8y ago
    I agree WASM doesn't bring in anything fundamental to this picture that isn't already there with JS. But that is no comfort. In the ancient web world, the site author wrote HTML to describe the data she wanted presented and the browser took care of making it accessible. But authors (especially companies) wanted detailed control of how their sites looked, so they turned to flash etc. JS has long been re-playing this trend in slow motion -- moving away from web pages being interactive documents presented by the GUI app called browser and towards them being stand-alone GUIs like in flash.
- Yoric 8y ago
  I don't think so. Accessibility, links, ad blocking etc. behave exactly the same with wasm as with JS. What difference do you see?
  - disiplus 8y ago
    no if you don't target DOM, if i could have "browser" in a browser that targets canvas or webgl then i cannot block it, only on network level.
rfinney 8y ago
Webassembly is linkable: https://webassembly.org/docs/dynamic-linking/ https://webassembly.org/docs/dynamic-linking/ in the dynamic linking sense. WebAssembly enables load-time and run-time (dlopen) dynamic linking in the MVP by having multiple instantiated modules share functions, linear memories, tables and constants using module imports and exports. In particular, since all (non-local) state that a module can access can be imported and exported and thus shared between separate modules’ instances, toolchains have the building blocks to implement dynamic loaders. The code is fetched via URLs so you can link to it in that sense, too. It's also cacheable: https://developer.mozilla.org/en-US/docs/WebAssembly/Caching_modules https://developer.mozilla.org/en-US/docs/WebAssembly/Caching...
- colanderman 8y ago
  I think the GP means "links" as in "clickable links", not "binary linker/loader".
- dingo_bat 8y ago
  I think he meant linkable in the web sense, ie, hyperlinks.
- rhencke 8y ago
  I believe the parent comment was referring to hyperlinks, not dynamic linking. The point was more that once webpages become applications running on the client (think single page apps), the natural document metaphor of web pages and the tooling built on it (hyperlinks, forward/back, bookmarks, history) falls apart unless you do extra work to ensure that experience is maintained.
  - rfinney 8y ago
    ah. thanks. "clickable" Because you certainly can link to the wasm and js code that come with webassembly instantiateables.
  - mindcrime 8y ago
    the natural document metaphor of web pages and the tooling built on it (hyperlinks, forward/back, bookmarks, history) falls apart unless you do extra work to ensure that experience is maintained But not everything needs to be a document. Sometimes the thing you're working with really is an application and not a document. To me, one of the biggest problems with the current web is that we've commingled "app stuff" and "document stuff" so badly that browsers have been forced to become a shitty, inferior X-server (or Operating System outright), instead of being really good browsers. Browsers for browsing is great... browsers as a UI remoting protocol, is a bit janky.
api 8y ago
The web long ago became not only a document store but also a thin client platform for distributing full client applications to end users. That cat is out of the bag and is not going to be stuffed back in. WASM is really just a cleaner, faster, more elegant way of running alternative languages to JavaScript in the browser. It replaces transpilers that turned languages like Java or Go into ugly basically machine code JavaScript blobs. It will save bandwidth and improve performance but otherwise doesn't change much. Note that transpiled and uglified JavaScript is already "closed source," so nothing changes there. Anything can be obfuscated.
- clan 8y ago
  I do see your point! I am however scared that HTML will go the way of Gopher. Why would anyone care to maintain boring hypertext documents when we can have app of the day. Marketing departments everywhere tend to turn the web into Blinkenlights. How many support documents of more than 15-20 years ago are you able to still find using the old links? So many sites are working as dumb front-ends for a database. The information retrieval and persistence over time is not something many worries about. The cat is for sure out of the bag. I just hope what was still can survive.
  - TeMPOraL 8y ago
    > The cat is for sure out of the bag. I just hope what was still can survive. I hope so too, but as a member of predatory and territorial species, the cat will most likely keep on killing everything else around it.
    - jessaustin 8y ago
      Yes, but only for about four hours a day, because naps.
  - Dolanator11 8y ago
    >I am however scared that HTML will go the way of Gopher. Why would anyone care to maintain boring hypertext documents when we can have app of the day. JS or Wasm can't create documents by themselves, they still need a DOM. Even if it's a 2D canvas or some WebGL canvas, it's still a DOM element. Or even if it's just an iframe that loads some blob, on the top level it's still a DOM element. And as such it can be inspected and controlled.
steveklabnik 8y ago
My position on this is basically, WebAssembly is no different than JavaScript here. If you think JavaScript ruins this property, well, the web was only in the form you describe for four years, and has existed this way for 23 years now.
- EvanAnderson 8y ago
  The focus on driving WASM performance in the browser platforms, combined with the ability to transpile more languages to WASM, pushes the barrier-to-entry lower. Yes, these concerns aren't specific to WASM, but the platform is being made more capable of hosting this kind of troubling code, and more attractive to developers who would develop these things.
  - emodendroket 8y ago
    I don't think the barrier to entry or ease of development is really the issue when we're talking about ad networks.
    - EvanAnderson 8y ago
      Ad networks, no-- I agree with that. I'm more concerned about entire websites becoming "apps", complete with browser-in-a-browser functionality (with the inner browser's behavior being completely under the control of the site operator). It would be an interesting experiment to transpile a less complex browser, like Arachne, over to WASM as a proof of concept to demonstrate how awful this kind of future would be. (Yet another "if I had some free time" wishes... >sigh<)
      - TeMPOraL 8y ago
        > It would be an interesting experiment to transpile a less complex browser, like Arachne, over to WASM as a proof of concept to demonstrate how awful this kind of future would be. (Yet another "if I had some free time" wishes... >sigh<) Don't. Most people will ignore the demonstration, but someone greedy will fork the project, build a library out of it, and start selling as a product to ad networks and media companies.
smrtinsert 8y ago
Yes its bad for document markup, but I wouldn't waste time coding the next Excel in HTML and CSS, I'd just straight to a gui language with guaranteed cross platform rendering.
derefr 8y ago
Potentially fun questions: are there any “DOM-native JavaScript games”? I.e., games that manipulate the DOM for their “graphics”—or even have hypertext in place of graphics—rather than running in a canvas? The only example I can think of is the Twine engine for Interactive Fiction.
- SenHeng 8y ago
  Well there's this. https://github.com/mozilla/BrowserQuest https://github.com/mozilla/BrowserQuest Doesn't work in Safari.
- jayflux 8y ago
  You should look into Crafty, it’s a js game engine which can output to either the DOM or canvas, I’m not sure how popular it is anymore but quite a few games used it. There are demo games here http://craftyjs.com http://craftyjs.com
marcosdumay 8y ago
Compiling to Wasm will only get easier. It's only hard now because the target is new and people are still adapting the tooling. There is no reason why it would be any harder than compiling for a machine. Wasm will almost certainly lead to UI frameworks for the Web. JS people try very hard to get similar stuff, but the language is just not good enough; at the same time the desktop people that have this stuff is claiming for some way to use the same on the Web. People are already working on those frameworks, by the way.

j45 8y ago

Sometimes a program running in the browser will be valuable when it's full window. Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems.

black_puppydog 8y ago
Yeah, or a full version of a monero miner...
cmiles74 8y ago
In my experience, the application-on-browser products consume far more CPU and RAM than the application-on-OS products. For me, that's a pretty big deal: I need the laptop to run as long as possible on a charge. Right now, I would complain if I _had_ to run a full version of Word or Excel in the browser. Perhaps Web Assembly will drive this power usage down. But as it stands now, I actively avoid more than one of these app-on-browser products at a time.
- baybal2 8y ago
  Well, modern JS is MORE performant that classical scripting languages in benchmark cases, but the fact is that your browser freezes on half of js CRUDs that do data processing, while an analogous Perl application works at near light speed in comparison. In half cases like that, stuff like sorting, list comparison, deduplication are done in a way that will score low mark even by standards of first year university program. This is telling of web development industry's approach to doing business. The most horrid examples of "LAMP sweatshops" of 10 years ago pale in comparison to what the industry has devolved into these days. My own experience being an involuntary webdev for 3 years left me with following impressions: 1. Webdev is the largest commercial development niche in the whole tech industry. Everything else pales in comparison. It is also about making money quickly. A webapp or even a promo page SPA for a major consumer brand these days can cost up to $100k easily. $100k does not seem a lot to most people here, but such money can be well offered for a 1 month project for a team of of 6-8 professionals. 2. The industry is dominated by shops with 20 to 30 people headcount. Web dev studios generally don't scale much above that because of talent flight. Loss of a single senior dev who supervises hordes of lowest tier mule coders is often the end of a business for most of companies. 3. People from "big dotcom" world are near oblivious to ways of small web dev shops. For people who began their careers at 60k a year internships, getting into shoes of a person who does coding for 30k a year is impossible. 4. Talent flight and turnover is real. 5. This is all about really expensive quick and dirty code. 6. "The big dotcom" type of companies tried time and time again to tap into the market to extract rents, and with exception of Macrovision nobody ever succeeded. This is the reason Adobe is lobbying for unusable, unwieldy APIs in hopes of selling tooling for it.
  - kansface 8y ago
    If I could ask, where do you live? Your experiences don't reflect my own.
    - baybal2 8y ago
      Practiced for near 3 years in Canada, and continued for a half a year after in China. Quit webdev a year ago, now working in engineering consultancy.
Eequei3i 8y ago
> decrease our reliance on particular operating systems By replacing it with a poor simulacrum of an operating system. Browser APIs are an inefficient subset of libc and bsd sockets offer. And they provide near-zero interoperability with native applications. No filesystem access (beyond the clunky save-one-file dialog), no CLI, no IPC, nothing. That means browsers are building on top of operating systems while not interoperating with them.
- throwaway2016a 8y ago
  > No filesystem access This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. There are some use cases that are hard to support (like being able to open all the files in a folder). But people are working on a solution.[1] > No IPC WebRTC while not the same and far more overhead (due to TCP sockets vs OS level sockets) can function very much like IPC. And there is nothing stopping a process running in a different browser (or even no browser at all) to connect to a webapp using WebRTC locally. Additionally, if a new window is opened by Javascript and both pages are in the same domain + port (or subdomains of the same domain and you have access to the parent domain) you can communicate between the windows with simple Javascript function calls. And since browsers are moving towards a 1 process per window setup this is essentially IPC. > That means browsers are building on top of operating systems while not interoperating with them. While I can't argue with that. So is X Window. The abstraction between app and OS is a thick gray line not a thin black one. [1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemDirectoryEntry https://developer.mozilla.org/en-US/docs/Web/API/FileSystemD...
  - TeMPOraL 8y ago
    > This is a step forward not backwards. The security model of allowing apps access to your full filesystem (assuming your user has access) is flawed. It leads to apps storing data in funny places, reading files they shouldn't, and general mayhem. Requiring the user to explicitly allow the app to access the file is a good thing. Most apps being limited to their little part of the filesystem is not a problem. The problem is, now as a user, I can't access those files. I can't view them in a form that suits me, I can't use other applications to operate on them. The true form of the data is forever hidden from me, a secret of the application that "owns" it.
TeMPOraL 8y ago
> Would I complain if I could run a full version of Word or Excel in the browser? The browser would become a universal interface in another way and decrease our reliance on particular operating systems. I for one would, because the browser is an absolutely shitty interface. You're still forced into "there are tabs, which contain sandboxed documents" model of use. Interoperability is nonexistant, integration with machine capabilities is superficial and completely opaque to the user, the data model is hidden (where is my localStorage equivalent of the file browser again?), everything assumes you're constantly connected - it's a corporate wet dream, but for individuals, it's a nightmare.
- j45 8y ago
  Nothings perfect, though. If operating systems aren't, I wouldn't expect browsers to be either. Creating mobile and/or offline first exoeriences for individuals isn't a pipe dream, it was possible and happened in the 90's when connectivity (dialup) informed content (largely offline or downloaded). I'm not looking at replacement, only reasonable substitutes, which I think will become useful similar to using Google docs on mobile and web.
- yorwba 8y ago
  > where is my localStorage equivalent of the file browser again? The Firefox developer tools have a "storage" tab that lets you inspect the content of various databases associated with a website.
  - TeMPOraL 8y ago
    Default-disabled, read-only and scope-limited to domains your current tab works with, but I guess it's better than nothing.
sidlls 8y ago
Different psuedo-VMs, I mean browsers, operate differently even on the same specs for various technologies (CSS, JS). They already act effectively like "particular operating systems," except they're less efficient and more obnoxious to work with.
sparkie 8y ago
You web folk are mentally ill, with the desease known as Not Invented Here Syndrome. The w3c completely detests the idea of utilizing existing technologies that don't have their name on them. Whatever the technology, it MUST be reinvented (often badly) so it can be one of their standards. I've even seen WebVR pop up recently. I'm surprised nobody has standardized a WebOffice yet, but I assume it has been put on hold because of the magnitude of the task. Can be pretty sure we'll be seeing these in the coming years: WebStore: It's silly to have Google Play and the Apple store as separate things. In future, all apps will be written in WEB and distributed from WebStore. WebCoin: Bitcoin is great, but it exists separate from the web. We find the utterly unacceptable, and we are therefore publishing WebCoin so transactions are standardized across browsers. WebPilot: Self-driving cars, IN THE BROWSER!
- sctb 8y ago
  This comment breaks a handful of guidelines and is not civil or substantive. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

EvanAnderson 8y ago

I envision horrible "all WASM" websites, just like the old "all Flash" websites, that won't have accessibility, won't be able to be linked to, etc. Worse, I envision this as being another step in the ad blocker arms race. Inevitably there are going to be websites that package an entire WASM-based browser that will need to be used to access the site, nullifying client-side ad and script blockers. I can see the pitch now-- "Keep your existing website but add our tools to prevent ad blockers!" (Edit: Typos. I should know better than to post from my phone by now. Grrr...)

colanderman 8y ago
It already is possible, with JavaScript. WASM doesn't change anything. And the fact that although it happens with JavaScript, it isn't pervasive, I think should assuage this fear.
- toadworrier 8y ago
  I agree WASM doesn't bring in anything fundamental to this picture that isn't already there with JS. But that is no comfort. In the ancient web world, the site author wrote HTML to describe the data she wanted presented and the browser took care of making it accessible. But authors (especially companies) wanted detailed control of how their sites looked, so they turned to flash etc. JS has long been re-playing this trend in slow motion -- moving away from web pages being interactive documents presented by the GUI app called browser and towards them being stand-alone GUIs like in flash.
Yoric 8y ago
I don't think so. Accessibility, links, ad blocking etc. behave exactly the same with wasm as with JS. What difference do you see?
- disiplus 8y ago
  no if you don't target DOM, if i could have "browser" in a browser that targets canvas or webgl then i cannot block it, only on network level.

rfinney 8y ago

Webassembly is linkable: https://webassembly.org/docs/dynamic-linking/ https://webassembly.org/docs/dynamic-linking/ in the dynamic linking sense. WebAssembly enables load-time and run-time (dlopen) dynamic linking in the MVP by having multiple instantiated modules share functions, linear memories, tables and constants using module imports and exports. In particular, since all (non-local) state that a module can access can be imported and exported and thus shared between separate modules’ instances, toolchains have the building blocks to implement dynamic loaders. The code is fetched via URLs so you can link to it in that sense, too. It's also cacheable: https://developer.mozilla.org/en-US/docs/WebAssembly/Caching_modules https://developer.mozilla.org/en-US/docs/WebAssembly/Caching...

colanderman 8y ago
I think the GP means "links" as in "clickable links", not "binary linker/loader".
dingo_bat 8y ago
I think he meant linkable in the web sense, ie, hyperlinks.
rhencke 8y ago
I believe the parent comment was referring to hyperlinks, not dynamic linking. The point was more that once webpages become applications running on the client (think single page apps), the natural document metaphor of web pages and the tooling built on it (hyperlinks, forward/back, bookmarks, history) falls apart unless you do extra work to ensure that experience is maintained.
- rfinney 8y ago
  ah. thanks. "clickable" Because you certainly can link to the wasm and js code that come with webassembly instantiateables.
- mindcrime 8y ago
  the natural document metaphor of web pages and the tooling built on it (hyperlinks, forward/back, bookmarks, history) falls apart unless you do extra work to ensure that experience is maintained But not everything needs to be a document. Sometimes the thing you're working with really is an application and not a document. To me, one of the biggest problems with the current web is that we've commingled "app stuff" and "document stuff" so badly that browsers have been forced to become a shitty, inferior X-server (or Operating System outright), instead of being really good browsers. Browsers for browsing is great... browsers as a UI remoting protocol, is a bit janky.

api 8y ago

The web long ago became not only a document store but also a thin client platform for distributing full client applications to end users. That cat is out of the bag and is not going to be stuffed back in. WASM is really just a cleaner, faster, more elegant way of running alternative languages to JavaScript in the browser. It replaces transpilers that turned languages like Java or Go into ugly basically machine code JavaScript blobs. It will save bandwidth and improve performance but otherwise doesn't change much. Note that transpiled and uglified JavaScript is already "closed source," so nothing changes there. Anything can be obfuscated.

clan 8y ago
I do see your point! I am however scared that HTML will go the way of Gopher. Why would anyone care to maintain boring hypertext documents when we can have app of the day. Marketing departments everywhere tend to turn the web into Blinkenlights. How many support documents of more than 15-20 years ago are you able to still find using the old links? So many sites are working as dumb front-ends for a database. The information retrieval and persistence over time is not something many worries about. The cat is for sure out of the bag. I just hope what was still can survive.
- TeMPOraL 8y ago
  > The cat is for sure out of the bag. I just hope what was still can survive. I hope so too, but as a member of predatory and territorial species, the cat will most likely keep on killing everything else around it.
  - jessaustin 8y ago
    Yes, but only for about four hours a day, because naps.
- Dolanator11 8y ago
  >I am however scared that HTML will go the way of Gopher. Why would anyone care to maintain boring hypertext documents when we can have app of the day. JS or Wasm can't create documents by themselves, they still need a DOM. Even if it's a 2D canvas or some WebGL canvas, it's still a DOM element. Or even if it's just an iframe that loads some blob, on the top level it's still a DOM element. And as such it can be inspected and controlled.

steveklabnik 8y ago

My position on this is basically, WebAssembly is no different than JavaScript here. If you think JavaScript ruins this property, well, the web was only in the form you describe for four years, and has existed this way for 23 years now.

EvanAnderson 8y ago
The focus on driving WASM performance in the browser platforms, combined with the ability to transpile more languages to WASM, pushes the barrier-to-entry lower. Yes, these concerns aren't specific to WASM, but the platform is being made more capable of hosting this kind of troubling code, and more attractive to developers who would develop these things.
- emodendroket 8y ago
  I don't think the barrier to entry or ease of development is really the issue when we're talking about ad networks.
  - EvanAnderson 8y ago
    Ad networks, no-- I agree with that. I'm more concerned about entire websites becoming "apps", complete with browser-in-a-browser functionality (with the inner browser's behavior being completely under the control of the site operator). It would be an interesting experiment to transpile a less complex browser, like Arachne, over to WASM as a proof of concept to demonstrate how awful this kind of future would be. (Yet another "if I had some free time" wishes... >sigh<)
    - TeMPOraL 8y ago
      > It would be an interesting experiment to transpile a less complex browser, like Arachne, over to WASM as a proof of concept to demonstrate how awful this kind of future would be. (Yet another "if I had some free time" wishes... >sigh<) Don't. Most people will ignore the demonstration, but someone greedy will fork the project, build a library out of it, and start selling as a product to ad networks and media companies.

smrtinsert 8y ago

Yes its bad for document markup, but I wouldn't waste time coding the next Excel in HTML and CSS, I'd just straight to a gui language with guaranteed cross platform rendering.

derefr 8y ago

Potentially fun questions: are there any “DOM-native JavaScript games”? I.e., games that manipulate the DOM for their “graphics”—or even have hypertext in place of graphics—rather than running in a canvas? The only example I can think of is the Twine engine for Interactive Fiction.

SenHeng 8y ago
Well there's this. https://github.com/mozilla/BrowserQuest https://github.com/mozilla/BrowserQuest Doesn't work in Safari.
jayflux 8y ago
You should look into Crafty, it’s a js game engine which can output to either the DOM or canvas, I’m not sure how popular it is anymore but quite a few games used it. There are demo games here http://craftyjs.com http://craftyjs.com

marcosdumay 8y ago

Compiling to Wasm will only get easier. It's only hard now because the target is new and people are still adapting the tooling. There is no reason why it would be any harder than compiling for a machine. Wasm will almost certainly lead to UI frameworks for the Web. JS people try very hard to get similar stuff, but the language is just not good enough; at the same time the desktop people that have this stuff is claiming for some way to use the same on the Web. People are already working on those frameworks, by the way.