Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Assembly

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Web Assembly

#51

Post by iamsohungry »

userbinator wrote: post #37
reissbaker wrote: post #32

Earlier quoted context omitted.

This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to r…

Just block the network requests and you're done. Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods. That said, a new type of adblocker based on patt…

> Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts.

This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM.

It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.

Re: Web Assembly

#52

Post by ilaksh »

s3th wrote: post #19
purplerabbit wrote: post #2

Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear. I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.

Things are definitely picking up speed! There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines. We've still got a long ways to go, but it's much nearer than 10+ years! [0]: https://github.com/WebAssembly/wasm-jit-prototype [1]: https…

What about Servo?

Re: Web Assembly

#53

Post by jasode »

reissbaker wrote: post #32
pdkl95 wrote: post #22

Earlier quoted context omitted.

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to r…

pdkl95 has brought this up before[1] and again, it looks like everyone is confused by his (mis)understanding of: WebAssembly, The Halting Problem, and the economics+friction of practical advertising delivery (now and in the future.)

I couldn't convince him/her that any future trends towards pre-built ads rendered on server proxies, or seamless "native advertising", is orthogonal to WebAssembly.

[1]https://news.ycombinator.com/item?id=10211050

Re: Web Assembly

#54

Post by jmhain »

ilaksh wrote: post #52
s3th wrote: post #19

Earlier quoted context omitted.

Things are definitely picking up speed! There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines. We've still got a long ways to go, but it's much nearer than 10+ years! [0]: https://github.com/WebAssembly/wasm-jit-prototype [1]: https…

What about Servo?

Servo uses SpiderMonkey.

Re: Web Assembly

#55

Post by h1282227 »

TranquilMarmot wrote: post #3

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

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

Re: Web Assembly

#56

Post by h1282227 »

cpeterso wrote: post #38
richdougherty wrote: post #8

Earlier quoted context omitted.

wasm and asm.js are perfect examples of incremental improvements rather than building something from scratch. The benefit of this is that incremental improvements can be built slowly on top of existing deployed JavaScript engines, whereas writing something from scratch has a serious bootstrapping problem. The wasm/asm.js story goes like this so far: 1. emscripten, a JavaScript backend for LLVM, demonstrates that you…

How long until someone implements WebAssembly instructions in hardware? ARM's "Jazelle" supported some JVM instructions in hardware.

Hardware support only makes sense if the optimisations are already included in the compiler output. The JVM does all the optimisations which makes Java Bytecode not suitable for that purpose.

Re: Web Assembly

#57

Post by z3t4 »

Why can't virtualization and containing of the app be done on a OS level? Why do we need the browser to run "web" apps?

Re: Web Assembly

#58

Post by tracker1 »

purplerabbit wrote: post #2

Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear. I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.

I'd guess 3-5 if you look at most penetration once an initial implementation takes hold in browsers... now, you may have upwards of 30-40% of people not covered by a feature, but that doesn't mean you can't target it... it comes down to your audience... If MS actually keeps its' promise of rolling releases, or closer to it this time, it could be much sooner than later.

Re: Web Assembly

#59

Post by JupiterMoon »

spankalee wrote: post #17
TranquilMarmot wrote: post #3

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

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

Wouldn't web crawlers prefer read access to content databases?

Re: Web Assembly

#60

Post by simula67 »

pdkl95 wrote: post #26
jacobolus wrote: post #12

Earlier quoted context omitted.

The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s…

> web applications are inherently second-class citizens on every platform. Yes. By design. If a webpage can impersonate a local app, you have a serious security problem. > They make it hard for users to load/save local data There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc. > They don’t interoperate with other applications on the system. That's a feature. > Th…

I think what your parent comment was saying was that : 'even though web is a great solution to many problems that can be solved with software, it has its limitations'. Clearly the problems s/he mentioned are a source of pain for some users, and many of them do not exist in the native application platform. Even if those trade-offs look unreasonable to you, it may not look so to many others. If we have more data to support the statement that somehow the web is always superior to native, then this discussion can move forward. Without it we are more likely going around in circles.
Post reply on HN