<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>leoc</author><text>&amp;gt; asm.js has several strengths over NaCl and even PNaCl&lt;p&gt;Why should we have to choose one or the other? Content negotiation is your friend.&lt;p&gt;Of that liast, I think only 1 and maybe 4 are real strengths.&lt;p&gt;Strength 1 means that old browsers or browsers from uncooperative vendors can still run applications at some level of performance (which might or might not be a usable level). Probably more important, tbh, is that it alters users&amp;#x27; perceptions of who is to blame for poor support. It seems that when a site runs fast on browser A but slowly on browser B the user tends to blame browser B, but when a site runs fast on browser A but not at all on browser B the user tends to blame the site owner. When users correctly allocate blame to uncooperative browser vendors this provides the impetus for browser vendors to reform their ways and&amp;#x2F;or for users to switch browsers.&lt;p&gt;As to point 2, the fact that asm.js means that authors and tools don&amp;#x27;t have to target a new runtime language is a pretty mixed blessing, because perforce it means that they have to continue targeting the old one, which is JS. When did &amp;quot;here, compile to a subset of this old high-level scripting language and we&amp;#x27;ll try to get the performance back using the latest in JIT and specialisation&amp;quot; become a reasonable candidate for a portable assembler system? Like a dog walking on its hind legs, it&amp;#x27;s impressive that asm.js works as well as it does, but that doesn&amp;#x27;t actually make it a reasonable approach. It only makes technical sense as part of a heroic effort to provide backwards-compatibility with JS-only browsers (see strength 1).&lt;p&gt;A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl&amp;#x2F;PNaCl? It seems that there&amp;#x27;s simply been no external effort to standardise it or interest in standardising it. Since &amp;quot;Web standards&amp;quot; are, to a good first approximation, a sock-puppet for the browser-vendor oligopoly this basically means that the other browser vendors have no desire for NaCl to become standardised. So I don&amp;#x27;t see how browser vendors telling us that NaCL is bad because Mr. Socky won&amp;#x27;t approve use of it is anything other than a childish deception. Let the other vendors make a serious, good-faith effort to standardise NaCL&amp;#x2F;PNaCl then we&amp;#x27;ll talk about lack of standardisation.&lt;p&gt;EDIT: additionally, notice how &amp;quot;it&amp;#x27;s a black box&amp;quot; has quietly disappeared from the list of the other browser vendors&amp;#x27; complaints against NaCl? C or C++ pushed through LLVM then Emscripten and ground up into asm.js is surely just as opaque to the site users as the same C or C++ pushed through LLVM and emitted as a PNaCl or NaCl binary. But it&amp;#x27;s &lt;i&gt;their&lt;/i&gt; black box, so that&amp;#x27;s OK.</text><parent_chain><item><author>TazeTSchnitzel</author><text>I agree. asm.js has several strengths over NaCl and even PNaCl:&lt;p&gt;* It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means &lt;i&gt;every&lt;/i&gt; browser supports asm.js, and supports it today&lt;p&gt;* It doesn&amp;#x27;t require a new runtime or API, merely using the existing web APIs&lt;p&gt;* It is simple for other browser vendors to implement, and isn&amp;#x27;t reliant on a single implementation&lt;p&gt;* It can interface with existing JavaScript code, so it can use JS libraries and, similarly, JS code can use asm.js libraries&lt;p&gt;* It is a completely open standard&lt;p&gt;* It is architecture-independent (so&amp;#x27;s PNaCl, though)</text></item><item><author>higherpurpose</author><text>I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl.&lt;p&gt;It&amp;#x27;s unacceptable that a &amp;quot;browser-os&amp;quot; that should have no problem being architecture agnostic, &lt;i&gt;still&lt;/i&gt; gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how &lt;i&gt;crazy&lt;/i&gt; is that?&lt;p&gt;I can understand ARM not having a serious chance on Windows laptops because of all the legacy x86 programs, but at worst it should be equal with x86 running an OS such as Chrome OS.</text></item></parent_chain></comment><story><title>Massive: The asm.js Benchmark</title><url>https://hacks.mozilla.org/2014/11/massive-the-asm-js-benchmark/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>amelius</author><text>I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly &lt;i&gt;multithreading&lt;/i&gt; platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there&amp;#x27;s webworkers, but I don&amp;#x27;t consider them a multithreading solution, because they don&amp;#x27;t allow a shared address space for inter-thread communication (only message-passing). This can be detrimental for performance, because the &amp;quot;structural sharing&amp;quot; paradigm becomes useless.&lt;p&gt;I think that a base-language without support for garbage collection would be preferable. The main advantage is that multithreading is easier to implement. (Any language built on top of this language could implement its own garbage collection, in principle.)</text><parent_chain><item><author>TazeTSchnitzel</author><text>I agree. asm.js has several strengths over NaCl and even PNaCl:&lt;p&gt;* It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means &lt;i&gt;every&lt;/i&gt; browser supports asm.js, and supports it today&lt;p&gt;* It doesn&amp;#x27;t require a new runtime or API, merely using the existing web APIs&lt;p&gt;* It is simple for other browser vendors to implement, and isn&amp;#x27;t reliant on a single implementation&lt;p&gt;* It can interface with existing JavaScript code, so it can use JS libraries and, similarly, JS code can use asm.js libraries&lt;p&gt;* It is a completely open standard&lt;p&gt;* It is architecture-independent (so&amp;#x27;s PNaCl, though)</text></item><item><author>higherpurpose</author><text>I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl.&lt;p&gt;It&amp;#x27;s unacceptable that a &amp;quot;browser-os&amp;quot; that should have no problem being architecture agnostic, &lt;i&gt;still&lt;/i&gt; gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how &lt;i&gt;crazy&lt;/i&gt; is that?&lt;p&gt;I can understand ARM not having a serious chance on Windows laptops because of all the legacy x86 programs, but at worst it should be equal with x86 running an OS such as Chrome OS.</text></item></parent_chain></comment><story><title>Massive: The asm.js Benchmark</title><url>https://hacks.mozilla.org/2014/11/massive-the-asm-js-benchmark/</url></story>