Hacker News Reader

Comment by quickben | Hacker News Reader

So what does the future hold? Will this replace JavaScript?

The more imminent concern is that publishers are beginning to bundle browser runtimes completely replacing native browser functionality along with its established privacy and fair use expectations. Say hello to unskippable interstitials, unblockable analytics and targeted advertising, content that can't be linked, saved/archived, mirrored, cached, shared, translated or made otherwise accessible.

Developers mostly discuss JavaScript shortcomings and new possibilities offered by WebAss, but seem otherwise happy to completely throw the fundamental architecture of the web under the bus.

Technically, what WebAss can do has since long been possible with native applications; the only thing added here are new software licensing models, eg. pay-per-use, but mostly tracking/ad-financed.

Or... you could continue avoiding websites that do what you deem unacceptable things. I won't visit a Forbes website intentionally - I have no intention of supporting a site that wants to throw ads quite that blatantly in my face. There'll always be a very large amount of sites that behave respectably.

What sites do you frequent? Almost every site is infested with advertising.

This isn't a dystopian future we can avoid, it is a dystopian present that already happened and we are stuck with it.

Almost every page needs JS to use. Almost all JS is thoroughly munged beyond readability. It's normal for even page navigation (surely a browser function) to be handled in JS, and for resource loading (again a browser function) to be done through JS making AJAX requests to URLs generated deep in a minified blob. The accessibility nightmare is real.

Ads are common as ever and adblocking is an arms race never won. DRM has been here for years, and HBO isn't putting .mp4s on an FTP server any time soon. YouTube is almost unwatchably saturated with ads and is run by Google, the search and analytics company. Targeted advertising and analytics are a bell that can't be un-rung.

The web you are trying to save became a victim of its own success, somewhere around when everyone decided it was going to be HTTP and HTML instead of gopher, the browser wars started and AOL users started to flood USENET.

"Companies are doing shitty things with browsers nowadays. Instead of shaming them and calling them out on it, lets just create a system that shows us how best to grab our ankles"

This is going to ruin so much about the web, and this 'lets just give up' attitude is one of the reasons why

>Ads are common as ever and adblocking is an arms race never won.

What are you talking about? I think I saw 2-3 ads top through all my browsing for the last year. The arms race is won by the adblocker. There was a slight upset when adblock detectors appeared, but Anti-Adblock killer took care of them.

I have the same worry. Page downloads content as some encrypted binary blob, displays it using <canvas>, impossible to block advertising or copy text.

However, at the end of the day, content providers have to make their content available in plain HTML format in order for search engines to index it. If they did the above without offering a plain HTML alternative, they'd lose traffic from search engines. But, if they are offering that format to search engines, they have to offer it to us too.

(Okay, they could lock it down so the plain HTML is only available if User-Agent = Googlebot/Bingbot/etc and source IP is coming from Google/Bing/etc network. But, will the search engines let them get away with that? I would hope Google would refuse to index it on the grounds that their crawler is getting something very different from what the real user sees, but I guess that's their decision.)

You can already do all this. In practice, I've never seen a site render its text and ads to a canvas to make things difficult for me.

IMO, the bigger obstacle to "content that can't be linked, saved/archived, mirrored, cached, shared, translated or made otherwise accessible" is the "fundamental architecture of the web": HTTP. You can't link it (who knows if the person who clicks the link will get the same page?), you can't cache it (who knows when to invalidate it?), you can't mirror it (who can enumerate the dependencies?), and so on. Something like IPFS would fix these things (and should fix these things). But in practice, a fairly cacheable, linkable, mirrorable, sharable web has been built on HTTP and I expect nothing much will change when wasm is thrown into the big vat of web technologies too.

Google (for years now) have been indexing "apps" ie. they execute code found in web pages and index the generated DOM (within bounds and with additional heuristics, obviously). In fact, not deepening Google's search monopoly is another excellent reason not to go all-in on the procedural web.

Mind you, I have nothing against Google nor ads in general (but I do have an issue with tracking, even though it has legitimate uses).

Sounds like flash based sites. Nothing really new. WebAssembly means I can use a safe language like Rust, and deliver to any platform with zero install pain for the user.

If publishers are replacing browser functionality, it's probably because the current way to reach browser functionality from wasm is bad/slow. See the second stick man graphic here:

https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...

That will also put a barrier in front of the current practice of borrowing code and techniques from other sites. How much of that goes on today is pretty opaque, so I'm not sure what effect it would have.

I don't get why people are so excited about WebAssembly, at least on the whole "replace Javascript"/"remove web bloat" aspect.

Right now we have Javascript and its assorted libraries, which, as bad as they are, come with the browser or at least are generally reused/cached very frequently.

People seem to fail to realize that everyone and their mother will dump their runtimes and their VMs on top of WebAssembly as soon as they will be able to. Java Applets 1, 2, ..., 100.

Yes, they will present it in a very fancy and attractive way, but fundamentally that's what will happen, cause who wants to rewrite everything for Javascript-land when they're not forced to? Competitive pressure will always push towards bloat, just look at Facebook and they Android-runtime busting app for an example.

I, for one, am looking forward to the day where, besides the 500MB of Javascript my 40 tabs are loading, I'll also load 1.5 GB of WebAssemblied formerly native runtimes.

I doubt it will be for average brochure sites, but I have used it in two situations, one to encode a series of captured canvas frames into ogg video on the client using ffmpeg to save bandwidth on a telehealth web application, and another to embed a mobile game engine in with samples so users can interact in the browser without having to download build and run http://moaiforge.com/samples/sample-browser/player/index.htm...

I'm excited at the prospect of 64-bit integer support, which will significantly speed up many applications, making even web-based proof-of-work mining feasible.

Wait. Why would you want web-based proof-of-work mining? Does this have a legitimate purpose, or is it all about forcing unsuspecting visitors to mine Bitcoin for you?

For things that are DOS-sensitive

The web page should only start the miner if the user is well informed and clicks a button to start it.

Legitimate purposes include spam-proofing message boxes, as well as cryptocurrencies whose PoW is somewhat CPU friendly, such as those bottlenecked by DRAM latency.

JavaScript got at least part of its popularity because it was the only thing that ran in all clients (Flash and Java were close, but had the disadvantage of being owned by a single big player)

Similarly, node.js got at least part of its popularity because it was the only thing that used _the_ language you can also run in the client.

This levels that playing field at least a bit (completely, if it can manipulate the DOM with little friction)

I expect to see many server-side languages will fairly soon compile to WebAssembly, so that they can position themeselves as an alternative to node (For example, I think Apple would be stupid if it wasn't working on a Swift-to-WebAssembly compiler).

In my book, that is good; competition in that field will improve all tools.

As I understand it, wasm is not asm, but an AST format for the JS VM. You're essentially compiling your c, rust, whatever, directly into the same thing JS is compiled to on the fly. But you do it in advance, so no parse time needed. Also, no GC, so good luck getting Java code on there for now.

https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

In the short term: probably not for small glue scripts, but it'll provide a serious alternative for larger web applications.

In the long term, we might see WebAssembly used as a means to implement JavaScript, such that you can count on the same set of features in every browser.

That'll depend on how well WebAssembly can interface with the DOM and with other browser APIs without needing JavaScript shim layers.

The point about having a nice API is huge-otherwise we'd still be writing java applets.

Intel x86 assembler is arguably not a nice API, but most of us are not working at that level any more.

The requirements for an instruction set aren't really the same as the requirements for a language well suited to writing, say, video poker games.

> Will [Wasm] replace JavaScript?

For bigger games, maybe. For applications, not so much.

However, it will give you the ability to mix and match different languages more freely. E.g. you can write processing-intensive modules in Rust/C/C++ and continue to script the UI with JS/TS/Dart.

This way you won't have to recompile tens or even hundreds of thousands of lines of code for minor UI changes.

WebAssembly does have GC, Polymorphic Inline Cache, and direct DOM integration on their roadmap.

So, at some point, you should be able to compile any language to WASM, including Javascript. The only real barrier would be the size of the runtime / standard library for the language. If WASM supports also supports some kind of hashed cache where many sites can share a language runtime, that's not even much of a barrier.

I suspect once it's stable, you'll see all sorts of languages being used in the browser.

Reply on news.ycombinator.com