Top all-time · #2975
Alon Zakai
Personal blog · mozakai.blogspot.comprogrammingweb
Alon Zakai writes azakai's blog, a personal blog at mozakai.blogspot.com about programming and web. Since 2010, 25 different Hacker News readers have linked it 44 times, most often “The elusive universal Web bytecode”. The last post was in 2015, but the archive is still widely read.
Alon Zakai aka kripken | Compiling to the Web: Emscripten, Binaryen, asm.js, WebAssembly, etc. New posts at: https://kripken.github.io/blog/
Most-linked posts?
- /2011/11/code-size-when-compiling-to-javascript.html5 people · 12 mentions · first linked 2013-02-15
- The elusive universal Web bytecode3 people · 6 mentions · first linked 2013-05-14
- Experiments with 'Static' JavaScript (using PyPy)2 people · 2 mentions · first linked 2010-07-14
- Debugging JavaScript is Awesome 2 people · 2 mentions · first linked 2012-06-17
- Running Lua in a browser via Emscripten2 people · 2 mentions · first linked 2013-05-30
- Emscripten - An LLVM-to-Javascript compiler2 people · 2 mentions · first linked 2010-08-29
- Reloop All The Blocks [in Emscripten]2 people · 2 mentions · first linked 2012-05-30
- What asm.js is and isn't2 people · 2 mentions · first linked 2013-06-20
What Hacker News says?
Personally, as someone who works with LLVM IR on a daily basis, the idea of standardizing LLVM IR as it exists today worries me a lot for several reasons: * Most importantly: LLVM IR is a compiler IR. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... * LLVM IR is really big compared to asm.js. http://mozakai.blogspot.com/2011/11/code-size-when-compiling... * LLVM IR wasn't really designed to be portabl…
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Mozilla and Epic Announce Unreal Engine for the Web”Submitted What asm.js is and isn't as a story · 167 points
HN discussionApps could feature detect threading and fall back to single-threaded mode for compatibility with non-asm browsers if it's not supported. Regarding the claim that asm.js is "bloated": http://mozakai.blogspot.com/2011/11/code-size-when-compiling...
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Mozilla and Epic Announce Unreal Engine for the Web”Submitted Running Lua in a browser via Emscripten as a story · 91 points
HN discussionLLVM bytecode was not designed to be a universal bytecode; it still contains architecture-specific information for code generation. How long would it take for Mozilla, Google, Apple, and Microsoft to standardize on a common bytecode and then write compatible implementations for x86, ARM, and other platforms? NaCL or PNaCL are contender bytecodes, but Google is the only browser vendor that is interested. JS is a stan…
Comment linking /2013/05/the-elusive-universal-web-bytecode.html
on “Mozilla Research Projects”Submitted The elusive universal Web bytecode as a story · 64 points
HN discussion> http://mozakai.blogspot.com/p/about.html researcher at Mozilla
Comment linking /p/about.html
on “Firefox, you're supposed to be in my pocket, not the other way around”Submitted Experiments with 'Static' JavaScript: As Fast As Native Code? as a story · 52 points
HN discussionasm.js is a cross-platform bytecode; it just happens to be ASCII and look like JS. :) Arguments against asm.js as a bytecode are mostly about aesthetics and "elegance". http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
Comment linking /2013/05/the-elusive-universal-web-bytecode.html
on “Bringing asm.js to the Chakra JavaScript engine in Windows 10”Submitted The Elusive Universal Web Bytecode as a story · 32 points
HN discussionSee http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Comparable with native after you gzip. Note that this wasn't asm.js, however, just vanilla Emscripten output. asm.js output will be somewhat larger due to the strict type system.
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Asm.js in Firefox Nightly”Submitted Emscripten - An LLVM-to-Javascript compiler as a story · 22 points
HN discussionThis is a feature, not a drawback. Aggregate types for C-like languages tend to bloat the code for no real optimization benefit. See the comparison between LLVM IR and Emscripten-generated JavaScript here: http://mozakai.blogspot.com/2011/11/code-size-when-compiling... (Of course, for GC'd languages, we will need aggregate types.)
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Why Asm.js Bothers Me”Submitted C++ to JavaScript: Emscripten, Mandreel, and now Duetto as a story · 12 points
HN discussion> I have seen something like that already. Let me tell you, you don't want to download 20 MB for some simple web Tetris-clone. http://mozakai.blogspot.com/2011/11/code-size-when-compiling... > asm.js is useless for pretty much any modern language which relies on garbage collection. That is being worked on with the Binary Data spec: http://asmjs.org/faq.html
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Firefox Nightly Gets New Baseline JIT Compiler”Submitted The Elusive Universal Web Bytecode as a story · 3 points
HN discussionFor file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “On Asm.js”Submitted HOWTO: Port a C/C++ Library to JavaScript (xml.js) as a story · 3 points
HN discussion(Luke Wagner from Mozilla here.) > This seems very much targeted at emscripten and not to cross-compilers that start with GC'ed languages like GWT, Dart, ClojureScript, et al. That's correct, although one could implement a garbage collector on top of the typedarray heap (we have working examples of this). There are some limitations to GCing the typed array manually, though, such as not taking advantage of the browse…
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “Asm.js: a strict subset of js for compilers – working draft”Submitted Experiments with 'Static' JavaScript (using PyPy) as a story · 3 points
HN discussionWe've had other languages running in browsers for quite a while now. eg.: http://mozakai.blogspot.com/2013/05/lua-in-javascript-runnin...
Comment linking /2013/05/lua-in-javascript-running-vm-in-vm.html
on “Portable Native Client”Submitted 2 recent Emscripten stories as a story · 2 points
HN discussion> However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading…
Comment linking /2013/05/the-elusive-universal-web-bytecode.html
on “Asm.js AOT compilation and startup performance”Submitted Looking through Emscripten output as a story · 2 points
HN discussionIronically, StatCounter's response commits some statistical fallacies, details here http://mozakai.blogspot.com/2012/06/statcounter-and-statisti... I don't know which source of browser market share is more reliable - no one does, really - and StatCounter made some valid points as well in their rebuttal. But to see them misunderstand statistics like that is cause for doubt.
Comment linking /2012/06/statcounter-and-statistics.html
on “Chrome now the most popular browser”Submitted Reloop All The Blocks [in Emscripten] as a story · 2 points
HN discussionText parsing isn't the bottleneck: https://mozakai.blogspot.com/2013/05/the-elusive-universal-w... (this blog post is pre-WASM, but the main advantage of WASM vs asm.js isn't that WASM is a binary format or even better performance than JS, but that Javascript can focus on being a language again, while WASM can focus on being a compile target)
Comment linking /2013/05/the-elusive-universal-web-bytecode.html
on “What We Need Instead of "Web Components"”Submitted Massive, a new work-in-progress asm.js benchmark as a story · 1 points
HN discussion> JavaScript and HTML are a lot more bloat than machine language code written to the wire. http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web). And if you're talking platform-dependent machine code, that's likely _wor…
Comment linking /2011/11/code-size-when-compiling-to-javascript.html
on “The JavaScript Problem”Submitted "Outlining": a workaround for JITs and big functions as a story · 1 points
HN discussion