Work in progress: 82,651 of 181,233 sites checked so far, more every week · updated 2 Nov 2026Missing a blog? Tell us

Top all-time · #2975

A

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.

Visit the blog
44mentions?
25HN people?
2010–2025first – last linked?
Links on Hacker News per year · peak 20 in 2013

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?

  1. /2011/11/code-size-when-compiling-to-javascript.html
    5 people · 12 mentions · first linked 2013-02-15
  2. The elusive universal Web bytecode
    3 people · 6 mentions · first linked 2013-05-14
  3. Experiments with 'Static' JavaScript (using PyPy)
    2 people · 2 mentions · first linked 2010-07-14
  4. Debugging JavaScript is Awesome
    2 people · 2 mentions · first linked 2012-06-17
  5. Running Lua in a browser via Emscripten
    2 people · 2 mentions · first linked 2013-05-30
  6. Emscripten - An LLVM-to-Javascript compiler
    2 people · 2 mentions · first linked 2010-08-29
  7. Reloop All The Blocks [in Emscripten]
    2 people · 2 mentions · first linked 2012-05-30
  8. What asm.js is and isn't
    2 people · 2 mentions · first linked 2013-06-20

What Hacker News says?

  1. 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”
  2. Submitted What asm.js is and isn't as a story · 167 points

    HN discussion
  3. Apps 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”
  4. Submitted Running Lua in a browser via Emscripten as a story · 91 points

    HN discussion
  5. LLVM 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”
  6. Submitted The elusive universal Web bytecode as a story · 64 points

    HN discussion
  7. > 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”
  8. Submitted Experiments with 'Static' JavaScript: As Fast As Native Code? as a story · 52 points

    HN discussion
  9. asm.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”
  10. Submitted The Elusive Universal Web Bytecode as a story · 32 points

    HN discussion
  11. See 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”
  12. Submitted Emscripten - An LLVM-to-Javascript compiler as a story · 22 points

    HN discussion
  13. This 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”
  14. Submitted C++ to JavaScript: Emscripten, Mandreel, and now Duetto as a story · 12 points

    HN discussion
  15. > 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”
  16. Submitted The Elusive Universal Web Bytecode as a story · 3 points

    HN discussion
  17. For 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”
  18. Submitted HOWTO: Port a C/C++ Library to JavaScript (xml.js) as a story · 3 points

    HN discussion
  19. (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”
  20. Submitted Experiments with 'Static' JavaScript (using PyPy) as a story · 3 points

    HN discussion
  21. We'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”
  22. Submitted 2 recent Emscripten stories as a story · 2 points

    HN discussion
  23. > 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”
  24. Submitted Looking through Emscripten output as a story · 2 points

    HN discussion
  25. Ironically, 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”
  26. Submitted Reloop All The Blocks [in Emscripten] as a story · 2 points

    HN discussion
  27. Text 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"”
  28. Submitted Massive, a new work-in-progress asm.js benchmark as a story · 1 points

    HN discussion
  29. > 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”
  30. Submitted "Outlining": a workaround for JITs and big functions as a story · 1 points

    HN discussion

Search all of HN for mozakai.blogspot.com

Linked by the same people?