16 ms·

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extensions or even scrape the web without a BigCo webcrawler's level of infra investment. Is everything going to turn into an opaque single page app? Technically, webassembly is really cool, but I worry about where the browser is headed.

EvanAnderson 7y ago
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future. The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website". For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.
- linuxftw 7y ago
  Smart phone apps already do this.
  - jhallenworld 7y ago
    Emulate Android or IOS in the browser- that way you only have to write an app, and not bother with a website.. All it will take is for ADK to a have button that produces a wasm version of your app.
    - gmueckl 7y ago
      Unity and UE4 are very close to having exactly this today. There's no big reason why this shouldn't work for apps targetting a readonable subset of Android.
- cercatrova 7y ago
  This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps faster than the Electron mess we have now.
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
  - feanaro 7y ago
    The outrage is because the web isn't simply a "UI platform". That's only one use of it. It's also a document platform. Also, arguments of the form of "X is unique, all others are doing the bad thing" are suspicious to me. This would mean we should cherish and preserve X, bringing the good aspect to other platforms, not devolving it into mediocrity or worse.
- IvanK_net 7y ago
  It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun. I would be very glad, if you can emulate a computer in a browser, so you can e.g. use VirtualBox or VMWare comfortably in your browser. Still, it will be sandboxed (it can not turn off your computer, or clear your hard drive, etc.). I think the web is the most open, independent, secure and versatile platform today. And I hope it will become even better and more powerful in the future.
  - Quarrelsome 7y ago
    > It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database. So we have a file-system storing a database that exposes a completely different database that holds a file system.
    - golemotron 7y ago
      Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - EvanAnderson 7y ago
    Yes. I am saying that some website operators would like to load an entire browser into your client just so they can control the presentation (make sure you're not able to block their ads, control their scripts, etc). I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it's code running on your computer. You're free to attach a debugger to step thru native code that runs a VM that runs a nested VM that's ultimately running the code you'd actually like to influence. Let me know how that goes for you.) Have you seen JSLinux[1]? [1] - https://bellard.org/jslinux/ https://bellard.org/jslinux/
- mahidhar 7y ago
  Unfortunately, I must agree with you that there are definitely some very troubling implications to how WebAssembly might be used to build more effective walled gardens on the web. I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe even be pre-bundled into the browser?). The only way to discover, download and run these other apps is through this curated Platform module. All this could be rendered through something like the Canvas API instead of the DOM, which again is managed on a low level by the Platform and in turn exposes higher level API's for the Apps. The Platform also has built in support for Ad networks, tracking, etc., which cannot be disabled without disabling the whole ecosystem of apps. And of course, like any good play/app store, it is completely incompatible with anything else, leading to new levels of Balkanization of the web. I hope that this isn't the case, and I'm completely wrong about this. But I just can't shake the feeling that as a community, we are championing WebAssembly as purely a performance win, without considering how big commercial interests might seek to exploit this new technology. Edit: typo with AMP
  - oaiey 7y ago
    This platform wasm will come. And it does not You do not need to be evil, especially in the beginning. Java or .NET Runtime and Libraries are a bit heavy for a small web page. And from there it is just the next step to run a base platform like Android user space or a simple runtime like blazor. In the end wasm is a runtime. There were physical Java Processors and I am pretty sure there will be webassembly processors.
    - lightgreen 7y ago
      There were not physical Java processors, because it’s too hard to emulate jvm in hardware. But there were processors with instructions optimized for interpreting jvm bytecode. These would be pretty useless nowadays (for either jvm or wasm) because baseline compiler which translates vm bytecode to native bytecode is easy and more efficient than direct vm support in hardware.
  - salawat 7y ago
- shadowgovt 7y ago
  Well, someone attempting that will have a long row to hoe to get the thing working with the needs of networks with different performance standards, useragents with different screen structures, and users with different accessibility requirements. Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.
  - EvanAnderson 7y ago
    The inner browser doesn't need to be a general purpose browser. It just needs to render the site-owner's content, run their scripts, etc. Once there's an API for WASM to manipulate the DOM accessibility becomes easier.
    - TomMarius 7y ago
      So react native?
- thosakwe 7y ago
  > Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?
  - sjy 7y ago
    Users seem pretty satisfied with single-page apps. They are slow to load and have frustrating-to-use (inconsistent) interfaces, at least compared to my memory of 1990s desktop software. If users actually cared about performance then software would get faster over time.
  - Someone 7y ago
    Consider some company running some web application for their employees that “works best in” IE 6 or, for example, Chrome, but the 2018 version. A third party that offers a way to run that on their iPad at the cost of a one-time 100MB download will find customers. archive.org also might find something like it useful. How else are you going to show old sites in 20 year’s time?
- marcosdumay 7y ago
  Yes, and for games it will be great. And a mixed bless for web applications. What won't be great are sites that do this to enforce ad viewing. But if it becomes common enough, you can expect ad-blockers to act on the frame-buffer of that virtual browser. Anyway, the most annoying will be the stupid people that do that just because "Even Google does it!" "It's webscale!", or whatever people will be saying 5 years from now.
harrygallagher4 7y ago
I think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a site to function and which parts are the tracking? I'm not trying to be overly cynical here, all of these topics remind me of high school when I'd download mildly-sketchy executables, decompile them, and try figure out whether or not they were safe to run. I would love to poke around with reverse engineering wasm, but I'd rather not have to do that every time I visit a new website.
- BlueTemplar 7y ago
  And this is why if blocking the "web"site JavaScript breaks the "web"site itself, then it never was a website to start with! (Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)
  - Shish2k 7y ago
    How I wish the problem were only breaking the "web" - these days, blocking tracking scripts on my router ends up breaking my desktop applications... (Example of the day, Parsec; example from yesterday, NVidia's driver-update software :( )
    - marcthe12 7y ago
      Just wow. I won't be surprised if doing something like that will break the os.
BlueTemplar 7y ago
Indeed, HTML = World Wide Web If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!
- krapp 7y ago
  > Indeed, HTML = World Wide Web The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of HTTP and the intent of HTML and the web itself. By your rationale, no site created after the addition of the <SCRIPT>, <APPLET> or <OBJECT> tags in HTML could be considered a part of the WWW, which would exclude the entirety of the web after HTML 3.2. This is "not even wrong" levels of ridiculousness.
  - BlueTemplar 7y ago
    Why do you find this stance ridiculous ? Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...) I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though I'm pretty sure that the capability has been here for more than a decade.) With the ability to run arbitrary code comes the loss of a common standard, and therefore the inability to communicate, especially for machines - you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?
    - krapp 7y ago
      It's ridiculous because you're claiming that HTML is "the web", but that somehow the content that HTML marks up is "not the web." I can guarantee that no one was looking at a Java applet or a Flash site in the 1990s and thinking "I don't know what this is, but it definitely isn't part of the World Wide Web." >Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? On the other hand, Flash allowed animators and game developers an outlet for creative expression and distribution and led to an explosion of content, and launch more than a few professional careers. And Java applets... existed. At the very least, I think it's controversial to say the web jumped the shark at that point. >you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ? I do see those results in search engines. Visibility in a search engine is a result of SEO and those sites' indexing rules, it has nothing to do with whether or not a site is part of the web - if I can reach it in a browser, it's part of the web by definition.
Already__Taken 7y ago
I worry more about the war against the URL than js progression. a simple way to send state to people is incredible.
simias 7y ago
If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features. Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know. If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble. To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.
- Pete_D 7y ago
  The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.
  - throwaway894345 7y ago
    My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamentally static content, but it sets the context for your perceived “shift in dev culture”.
danShumway 7y ago
> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users. HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user. A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.
- crimsonalucard 7y ago
  It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.
  - danShumway 7y ago
    95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
greggman2 7y ago
Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves There's some incentive to use HTML as it's indexable but it doesn't seem to be affecting mobile, although maybe mobile is in large part successful because of the web? Like the fact that you can post a tweet or a facebook post or a youtube video everywhere. Not sure that HTML is required for that and if it's not then it seems at least possible HTML will die.
- sectiondetail 7y ago
  >Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves Fortunately advertisers are renowned for their self-restraint, and can be trusted to not abuse this capability to simply shove in as many ads as they possible can, wherever they can, with masses of unblockable trackers underneath it all.
jt2190 7y ago
> I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. What, exactly, is "content"? Are binary formats content? (Audio, Video, etc?) Are textual comments and notes on other text content, or is only the work being commented on content? Are languages that rely on unicode encodings content? Must content be static or can it change frequently, even second by second? (Stock quotes, for example). Must things be easily scrapeable to be content? Furthermore, must we lock down the structure of content from now until the end of time as HTML or ASCII, or should future generations be allowed to define what they mean by content? There may be merit in a separation of content from browser, but we should not artificially limit ourselves to content that only fits into our legacy notion of what a browser is. If the browser must become a general purpose OS that can host whatever content people can dream up, I'm all for it.
- BlueTemplar 7y ago
  No, the browser should not be used for all content. It's not designed for it, and we already have the OS itself for that, why do you want to add needless levels of abstraction??
- 6gvONxR4sf7o 7y ago
  I agree that we should free up the constraints. But text is everywhere for a good reason. Assuming that while we add more non-text, we still keep making more text too, I hope we don't lose the ability to openly parse that new text.
gfodor 7y ago
It may be sad to see the web grow well beyond it's original scope of a web of documents, but at the same time, consider the alternative: without a solid standardized execution format, that ground would likely be permanently ceded as being under the guise of the existing native players. We all can see where the native vendors are headed: it seems likely in 10 years, you will not be able to distribute binaries to users of mainstream native operating systems without going through a centralized approval process by those vendors. Apple set the ball in motion with the App Store a decade ago, and we're well on our way towards seeing the end result as it creeps into our 'legacy' PC operating systems. The core dynamic of the web, more than document sharing, has been decentralization and removing lock-in and gatekeepers around content distributed through the Internet. As long as we continue to feel that is true (which becomes less believable as browser diversity declines) I feel we should be excited every time the web expands the scope of what can be done with it. It seems likely that 100 years from now, WASM will still exist, and it will allow people to create and distribute software without gatekeepers. If it never existed, or nothing like it did, it seems like the future would have been markedly worse for creators. Each of these enabling browser technologies that get into the standards should be heralded as having potentially massive positive counterfactual effects on our ancestors and future selves (WebXR being another notable example, landing soon.)
ChicagoDave 7y ago
A couple of takeaways: I’d love to see a XAML implementation for wasm, because it’s cleaner than html/css. Looking forward to .NET Core running in warm. I could see hackability actually improving since data and API access could be well-defined. I could see Publishers adopting wasm so their websites are more under their control. But most of all, software development getting out of the scripting business, which has such a wide range of misuse that it becomes expensive and unwieldy to maintain.
zzo38computer 7y ago
"I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. ..." This I agree with you. I think JavaScript and WebAssembly are not so bad programming languages, but I do think that scripts in web pages are overused (regardless what programming language is used, which isn't the issue). Opaque single page apps are also bad for URL. Also I often use curl when I want to download a file (or in one case, to stream audio), so do not want to have to deal with the web browser to do that.
calibas 7y ago
There's a push towards more server-side rendering, though it's generally a pain in the butt at the moment. Also, executing JavaScript when scraping isn't that difficult, depending on what you're using to scrape. Node.js has Puppeteer: https://github.com/puppeteer/puppeteer https://github.com/puppeteer/puppeteer
- 6gvONxR4sf7o 7y ago
  I agree that executing js when scraping isn't difficult, but wonder what that will look like a couple decades into the webassembly world. It might be closer in difficulty to trying to parse a netflix stream when scraping.
k__ 7y ago
Funny thing is, that JS lead to exactly that, separation of content (APIs) and interactivity (PWA/SPA)
iamlyingman 7y ago
Perhaps for web applications but they're already like that.

EvanAnderson 7y ago

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future. The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website". For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.

linuxftw 7y ago
Smart phone apps already do this.
- jhallenworld 7y ago
  Emulate Android or IOS in the browser- that way you only have to write an app, and not bother with a website.. All it will take is for ADK to a have button that produces a wasm version of your app.
  - gmueckl 7y ago
    Unity and UE4 are very close to having exactly this today. There's no big reason why this shouldn't work for apps targetting a readonable subset of Android.
cercatrova 7y ago
This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps faster than the Electron mess we have now.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- feanaro 7y ago
  The outrage is because the web isn't simply a "UI platform". That's only one use of it. It's also a document platform. Also, arguments of the form of "X is unique, all others are doing the bad thing" are suspicious to me. This would mean we should cherish and preserve X, bringing the good aspect to other platforms, not devolving it into mediocrity or worse.
IvanK_net 7y ago
It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun. I would be very glad, if you can emulate a computer in a browser, so you can e.g. use VirtualBox or VMWare comfortably in your browser. Still, it will be sandboxed (it can not turn off your computer, or clear your hard drive, etc.). I think the web is the most open, independent, secure and versatile platform today. And I hope it will become even better and more powerful in the future.
- Quarrelsome 7y ago
  > It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database. So we have a file-system storing a database that exposes a completely different database that holds a file system.
  - golemotron 7y ago
    Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- EvanAnderson 7y ago
  Yes. I am saying that some website operators would like to load an entire browser into your client just so they can control the presentation (make sure you're not able to block their ads, control their scripts, etc). I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it's code running on your computer. You're free to attach a debugger to step thru native code that runs a VM that runs a nested VM that's ultimately running the code you'd actually like to influence. Let me know how that goes for you.) Have you seen JSLinux[1]? [1] - https://bellard.org/jslinux/ https://bellard.org/jslinux/
mahidhar 7y ago
Unfortunately, I must agree with you that there are definitely some very troubling implications to how WebAssembly might be used to build more effective walled gardens on the web. I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe even be pre-bundled into the browser?). The only way to discover, download and run these other apps is through this curated Platform module. All this could be rendered through something like the Canvas API instead of the DOM, which again is managed on a low level by the Platform and in turn exposes higher level API's for the Apps. The Platform also has built in support for Ad networks, tracking, etc., which cannot be disabled without disabling the whole ecosystem of apps. And of course, like any good play/app store, it is completely incompatible with anything else, leading to new levels of Balkanization of the web. I hope that this isn't the case, and I'm completely wrong about this. But I just can't shake the feeling that as a community, we are championing WebAssembly as purely a performance win, without considering how big commercial interests might seek to exploit this new technology. Edit: typo with AMP
- oaiey 7y ago
  This platform wasm will come. And it does not You do not need to be evil, especially in the beginning. Java or .NET Runtime and Libraries are a bit heavy for a small web page. And from there it is just the next step to run a base platform like Android user space or a simple runtime like blazor. In the end wasm is a runtime. There were physical Java Processors and I am pretty sure there will be webassembly processors.
  - lightgreen 7y ago
    There were not physical Java processors, because it’s too hard to emulate jvm in hardware. But there were processors with instructions optimized for interpreting jvm bytecode. These would be pretty useless nowadays (for either jvm or wasm) because baseline compiler which translates vm bytecode to native bytecode is easy and more efficient than direct vm support in hardware.
- salawat 7y ago
shadowgovt 7y ago
Well, someone attempting that will have a long row to hoe to get the thing working with the needs of networks with different performance standards, useragents with different screen structures, and users with different accessibility requirements. Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.
- EvanAnderson 7y ago
  The inner browser doesn't need to be a general purpose browser. It just needs to render the site-owner's content, run their scripts, etc. Once there's an API for WASM to manipulate the DOM accessibility becomes easier.
  - TomMarius 7y ago
    So react native?
thosakwe 7y ago
> Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?
- sjy 7y ago
  Users seem pretty satisfied with single-page apps. They are slow to load and have frustrating-to-use (inconsistent) interfaces, at least compared to my memory of 1990s desktop software. If users actually cared about performance then software would get faster over time.
- Someone 7y ago
  Consider some company running some web application for their employees that “works best in” IE 6 or, for example, Chrome, but the 2018 version. A third party that offers a way to run that on their iPad at the cost of a one-time 100MB download will find customers. archive.org also might find something like it useful. How else are you going to show old sites in 20 year’s time?
marcosdumay 7y ago
Yes, and for games it will be great. And a mixed bless for web applications. What won't be great are sites that do this to enforce ad viewing. But if it becomes common enough, you can expect ad-blockers to act on the frame-buffer of that virtual browser. Anyway, the most annoying will be the stupid people that do that just because "Even Google does it!" "It's webscale!", or whatever people will be saying 5 years from now.

harrygallagher4 7y ago

I think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a site to function and which parts are the tracking? I'm not trying to be overly cynical here, all of these topics remind me of high school when I'd download mildly-sketchy executables, decompile them, and try figure out whether or not they were safe to run. I would love to poke around with reverse engineering wasm, but I'd rather not have to do that every time I visit a new website.

BlueTemplar 7y ago
And this is why if blocking the "web"site JavaScript breaks the "web"site itself, then it never was a website to start with! (Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)
- Shish2k 7y ago
  How I wish the problem were only breaking the "web" - these days, blocking tracking scripts on my router ends up breaking my desktop applications... (Example of the day, Parsec; example from yesterday, NVidia's driver-update software :( )
  - marcthe12 7y ago
    Just wow. I won't be surprised if doing something like that will break the os.

BlueTemplar 7y ago

Indeed, HTML = World Wide Web If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!

krapp 7y ago
> Indeed, HTML = World Wide Web The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of HTTP and the intent of HTML and the web itself. By your rationale, no site created after the addition of the <SCRIPT>, <APPLET> or <OBJECT> tags in HTML could be considered a part of the WWW, which would exclude the entirety of the web after HTML 3.2. This is "not even wrong" levels of ridiculousness.
- BlueTemplar 7y ago
  Why do you find this stance ridiculous ? Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...) I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though I'm pretty sure that the capability has been here for more than a decade.) With the ability to run arbitrary code comes the loss of a common standard, and therefore the inability to communicate, especially for machines - you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?
  - krapp 7y ago
    It's ridiculous because you're claiming that HTML is "the web", but that somehow the content that HTML marks up is "not the web." I can guarantee that no one was looking at a Java applet or a Flash site in the 1990s and thinking "I don't know what this is, but it definitely isn't part of the World Wide Web." >Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? On the other hand, Flash allowed animators and game developers an outlet for creative expression and distribution and led to an explosion of content, and launch more than a few professional careers. And Java applets... existed. At the very least, I think it's controversial to say the web jumped the shark at that point. >you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ? I do see those results in search engines. Visibility in a search engine is a result of SEO and those sites' indexing rules, it has nothing to do with whether or not a site is part of the web - if I can reach it in a browser, it's part of the web by definition.

Already__Taken 7y ago

I worry more about the war against the URL than js progression. a simple way to send state to people is incredible.

simias 7y ago

If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features. Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know. If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble. To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.

Pete_D 7y ago
The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.
- throwaway894345 7y ago
  My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamentally static content, but it sets the context for your perceived “shift in dev culture”.

danShumway 7y ago

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users. HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user. A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.

crimsonalucard 7y ago
It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.
- danShumway 7y ago
  95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target. This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.

greggman2 7y ago

Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves There's some incentive to use HTML as it's indexable but it doesn't seem to be affecting mobile, although maybe mobile is in large part successful because of the web? Like the fact that you can post a tweet or a facebook post or a youtube video everywhere. Not sure that HTML is required for that and if it's not then it seems at least possible HTML will die.

sectiondetail 7y ago
>Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves Fortunately advertisers are renowned for their self-restraint, and can be trusted to not abuse this capability to simply shove in as many ads as they possible can, wherever they can, with masses of unblockable trackers underneath it all.

jt2190 7y ago

> I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. What, exactly, is "content"? Are binary formats content? (Audio, Video, etc?) Are textual comments and notes on other text content, or is only the work being commented on content? Are languages that rely on unicode encodings content? Must content be static or can it change frequently, even second by second? (Stock quotes, for example). Must things be easily scrapeable to be content? Furthermore, must we lock down the structure of content from now until the end of time as HTML or ASCII, or should future generations be allowed to define what they mean by content? There may be merit in a separation of content from browser, but we should not artificially limit ourselves to content that only fits into our legacy notion of what a browser is. If the browser must become a general purpose OS that can host whatever content people can dream up, I'm all for it.

BlueTemplar 7y ago
No, the browser should not be used for all content. It's not designed for it, and we already have the OS itself for that, why do you want to add needless levels of abstraction??
6gvONxR4sf7o 7y ago
I agree that we should free up the constraints. But text is everywhere for a good reason. Assuming that while we add more non-text, we still keep making more text too, I hope we don't lose the ability to openly parse that new text.

gfodor 7y ago

It may be sad to see the web grow well beyond it's original scope of a web of documents, but at the same time, consider the alternative: without a solid standardized execution format, that ground would likely be permanently ceded as being under the guise of the existing native players. We all can see where the native vendors are headed: it seems likely in 10 years, you will not be able to distribute binaries to users of mainstream native operating systems without going through a centralized approval process by those vendors. Apple set the ball in motion with the App Store a decade ago, and we're well on our way towards seeing the end result as it creeps into our 'legacy' PC operating systems. The core dynamic of the web, more than document sharing, has been decentralization and removing lock-in and gatekeepers around content distributed through the Internet. As long as we continue to feel that is true (which becomes less believable as browser diversity declines) I feel we should be excited every time the web expands the scope of what can be done with it. It seems likely that 100 years from now, WASM will still exist, and it will allow people to create and distribute software without gatekeepers. If it never existed, or nothing like it did, it seems like the future would have been markedly worse for creators. Each of these enabling browser technologies that get into the standards should be heralded as having potentially massive positive counterfactual effects on our ancestors and future selves (WebXR being another notable example, landing soon.)

ChicagoDave 7y ago

A couple of takeaways: I’d love to see a XAML implementation for wasm, because it’s cleaner than html/css. Looking forward to .NET Core running in warm. I could see hackability actually improving since data and API access could be well-defined. I could see Publishers adopting wasm so their websites are more under their control. But most of all, software development getting out of the scripting business, which has such a wide range of misuse that it becomes expensive and unwieldy to maintain.

zzo38computer 7y ago

"I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. ..." This I agree with you. I think JavaScript and WebAssembly are not so bad programming languages, but I do think that scripts in web pages are overused (regardless what programming language is used, which isn't the issue). Opaque single page apps are also bad for URL. Also I often use curl when I want to download a file (or in one case, to stream audio), so do not want to have to deal with the web browser to do that.

calibas 7y ago

There's a push towards more server-side rendering, though it's generally a pain in the butt at the moment. Also, executing JavaScript when scraping isn't that difficult, depending on what you're using to scrape. Node.js has Puppeteer: https://github.com/puppeteer/puppeteer https://github.com/puppeteer/puppeteer

6gvONxR4sf7o 7y ago
I agree that executing js when scraping isn't difficult, but wonder what that will look like a couple decades into the webassembly world. It might be closer in difficulty to trying to parse a netflix stream when scraping.

k__ 7y ago

Funny thing is, that JS lead to exactly that, separation of content (APIs) and interactivity (PWA/SPA)

iamlyingman 7y ago

Perhaps for web applications but they're already like that.