This technical blog post from Mozilla explains WebAssembly compilation improvements released in Firefox 58, focusing on streaming compilation and tiered compilation architecture. The article strongly engages with the right to education (Article 26) through structured, accessible teaching of complex concepts; the right to participate in scientific advancement (Article 27) by publishing quantified research results with researcher attribution; and freedom of expression through open knowledge sharing (Article 19). The content exemplifies human rights values through transparent authorship, accessible explanation, open publication, and reader community engagement, though the underlying domain structure impedes privacy rights through analytics tracking.
Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine.
As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it
Caching of compiled code! As i read it they want to cache the wasm bytecode at the client level. What if servers did the caching instead? Group clients by the architectures they use and serve the cached bytecode to the right 'groups' of clients.
Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!"
Out of curiosity, using just released versions of browsers on this 2015 mac pro:
Firefox 57: WebAssembly.instantiate took 2990.2ms (4.1mb/s)
Chrome 63: WebAssembly.instantiate took 8736.9ms (1.4mb/s)
Safari 11.0.2: WebAssembly.instantiate took 10341ms (1.2mb/s)
If more speed is about to arrive, wow.
I'm curious what optimisations are needed / valuable for wasm files to improve streaming performance. I'm assuming if, e.g.:
def foo(baz):
bar(baz)
...
def bar(baz):
baz = baz +1
Then compilation would start and get stuck until it had a definition for bar? If so, presumably the next build time optimisations for a website will be to shuffle the code around in to as optimal an order as possible so as to improve streaming compilation speed?
does someone here, familiar with webassembly semantics, know if it’s theoretically possible to start streaming execution of code? I.e. as soon as the “main” (?) function is in, and block on every function call which is not yet compiled, recursively? Or could the last block of webassembly bytecode potentially change the semantics of the first?
Sooner or later, that’s an avenue people will want to explore, I assume?
No offense to Yehuda in general (he is doing great work), but Ember.js so ignorant of any js-size recommendations, that it seems weird to quote Yehuda in that context.
A two-tier JIT. Interesting to see tiered JIT compilation catch on the way it has. I seem to remember a few years ago reading that the Java HotSpot team had given up on tiered JIT compilation as being not worthwhile.
How far we've come. A whirlwind tour of todays JITs (apologies for the million links):
I'm not familiar with Web Assembly, but the recent trend is that as the downloads become faster, web performance in a vanilla browser becomes slower, because websites just send more stuff to you. Pages grow toward infinity. Also, if, like @sjrd mentioned, this code can't manipulate DOM or can use only a restricted set of JS objects, the where will the gain be? Is this intended to be used for number crunching code in the browser runtime? Help bitcoin miner scripts? What's the purpose then?
That's great news. On http://8bitworkshop.com/ I'd like to offer some additional WASM modules on-demand but they take 15+ seconds to load. (It seems 50% of the time is parsing and 50% module instantiation)
Total Aside. As a compiler and runtimes guy, I'm super excited for streaming compilation. I think stuff like this and ethereum for distributed computation is really cool stuff! :D
Does wasm do runtime code specialization? I wonder if there will end up being a way to do to timing attacks against the optimizing wasm compiler/linker step ... Is it possible to setup code such that the optimization time depends on the runtime inferred type of an 'x' that you aren't supposed to have access to ...?
Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power that was used to compile very same code on millions of computers every day?
> But there’s no good reason to keep the compiler waiting. It’s technically possible to compile WebAssembly line by line. This means you should be able to start as soon as the first chunk comes in.
Maybe they can optimize further by speculating what the next line will be...
That would assume you trust the server not to give you malicious machine code (which you of course cannot!). wasm is specified in such a way that it is still sandboxed by the VM that compiles it. If you fetch arbitrary machine code, you cannot verify it and that leads to huge security holes!
Well, the difference between "interpreted" and "compiled" has become very blurry during the last 20 years. These days, most "interpreted" programming languages are actually compiled to machine code on the client system.
This includes the JVML, of course, but also JavaScript, Python (with PyPy), etc. PHP isn't quite there yet, but it's coming.
> As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it
It's slightly different, but native code is typically compiled concurrently, too. The meat of it is often handled by the build system rather than the compiler itself, but that's not so different.
I don't think that's absurd at all. WebASM really should be the ASM of the web, everything should be compiled to it. A little pre-compilation of JS to WebASM makes sense to me
Function declarations are independent from function bodies. So think C/C++ headers/source file splits. You don't need to know what code is in bar if you know it takes 1 argument of type int and returns an int. That's all you needed to know how to call it successfully, so you can compile foo in your example perfectly fine. You just need to patch up the call location later when bar is resolved to actual address (this is the "link" step in a typical AOT compilation chain, or done by the loader if it's a dynamic dependency)
> I believe that's not even using the streaming compilation mentioned in the article
That's correct. Streaming compilation would finish earlier, but might actually benchmark more slowly because you'd be adding in the time that the compiler is idle and waiting for the network to catch up.
Preloading the .wasm file in the test lets us measure just the speed of the compiler, independent of the network.
> As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it
Well, that's because typically all cores are maxed out during a parallel build of large-scale C++ software, so there's no need to go any further.
With link-time optimization it's a different story…hence the work some compilers (like rustc for Rust) are doing to parallelize builds of single compilation units.
.NET focus always was native code, either AOT with NGEN or JIT on load.
The only variants of .NET with interpreter support were from 3rd party implementations, and the .NET Micro Framework, used in NETduino.
And now their focus seems to be to improve their AOT story.
Another interesting evolution was Android, with Dalvik and its basic JIT, ART with AOT on installation, to ART reboot with an interpreter in Assembly, followed by JIT and AOT code cache with PGO.
Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more optimized versions makes it a JIT? Or does the definition of JIT require recompiling in response to information about which code would benefit most?
No one is saying you should do your whole application in WASM though, it's really just like native extensions in any dynamic language: of course, you're not going to get GC or interaction with dynamic parts of the language in your extension, but the reason might be:
- libraries written in another language, such as SQL.js
- hot spots of an application that can benefit from fast number crunching (e.g., gaming, visualization)
- truly cross-platform at native performance
etc.
I don't think anyone serious enough to use WASM in their application is making the assumption of using wasm will make all your stuff faster. It won't. It's just another performance tool, with its benefits subject to performance methodologies.
Sidebar: Google Doc is an interesting application in this perspective, given they render the entire application in a canvas, and the application itself is probably not written in JS. I'm excited what the future holds for tools like Google Doc.
Unsurprising, considering that browsers load code on demand and despite the original vision for Java, the JVM and CRL tend to be used for apps for which it's acceptable to have slow startup time.
>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.).
DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs.
There's a simple-but-useful WebAssembly Explorer at https://mbebenita.github.io/WasmExplorer/ that interactively shows the C/C++ -> WASM Text -> x86 ASM path that WebAssembly takes.
DOM manipulation is already on the cards, should be out soon. This is likely a separate sub-team of people just working on making it as fast as possible.
The only downside I'm aware of is that it increases the pressure on the code cache. If your code cache is not large enough, it will thrash as methods are discarded then recompiled. We had significant performance problems with a server and it took quite awhile until we realized that was the cause. A cache of 256 mb was more than enough for us running a 2 million LOC monolith under Tomcat, so the absolute memory use isn't that significant. (Reference we found while researching: http://engineering.indeedblog.com/blog/2016/09/job-search-we...).
Once you know this is an issue, it's easy to monitor, but it is one more thing that can go wrong in the JVM.
> I did not realize that the WASM needs to be compiled into machine code on the client system
It doesn't need to be. This is a choice they've made. Other implementations of WASM could interpret it they wanted.
The Church-Turing thesis tells us that any program you can compile to machine code can also be interpreted, so it is not possible that any language needs to be compiled into machine code.
Could someone explain how Edge is performing so well or any references to what they have done in this regard? Has the Edge team already implemented this streaming and tiering compiler technique?
To wit, as described in their blog post:
https://blogs.windows.com/msedgedev/2017/04/20/improved-
Edge validates and compiles wasm code lazily. Thus, this simplistic benchmark isn't really measuring compile time on Edge. In contrast, Firefox, Chrome and Safari are doing some amount of AOT compilation before WebAssembly.instantiate() resolves.
Streaming compilation is the way it was always historically done. One reason is that computers used to not have enough RAM to store whole non-trivial programs in it in AST or another intermediate form.
Second reason is that this approach matches how the underlying theory of languages and automatons works. One can view modern AST producing compiler frontend as compiler that compiles it's input into program that builds the resulting AST.
On the other hand many modern optimalization passes simply cannot be done in streaming manner or even by any pushdown automaton.
@sjrd is talking about limitations for JS not other languages.
C, C++, Rust and others already have their own DOM/JS support.
WASM is exciting for statically typed languages especially. JS is not the target. It might eventually benefit from faster parsing but that's not the motive now.
Editorial Channel
What the content says
+0.70
Article 27Cultural Participation
High A=Advocacy (scientific progress, developer innovation participation) F=Framing (WebAssembly as 'game changer' enabling scientific advancement) P=Practice (open-source tools, community development support)
Editorial
+0.70
SETL
+0.46
Content strongly advocates for scientific advancement, celebrating WebAssembly as breakthrough technology enabling developers to participate in innovation. Emphasizes developer agency and community participation in technical standards ('developers to control how eagerly or lazily optimization is done'). Quotes respected technologists (Yehuda Katz, Steve Souders, Addy Osmani, Alex Russell) validating scientific progress narrative. Discusses multiple open-source tools supporting community participation.
FW Ratio: 55%
Observable Facts
Article uses phrase 'game changer' three times to emphasize scientific breakthrough character.
Quotes Yehuda Katz: 'this is a game changer' to validate scientific significance.
References open-source tools: Emscripten with 'shrinking initiative,' Rust with wasm32-unknown-unknown target, wasm-gc, wasm-snip.
Discusses developer control: 'In the future, we may add more options for developers to control how eagerly or lazily optimization is done.'
Cites multiple authority figures (Steve Souders, Addy Osmani, Alex Russell) to support scientific advancement framing.
Frames WebAssembly as enabling participation: 'gives it a try on your own device' invites developers to engage in innovation.
Inferences
Celebration of WebAssembly breakthrough empowers developers as active participants in scientific advancement rather than passive consumers.
Developer control language supports participation in decisions about technical implementation details.
Open-source tools emphasis demonstrates scientific progress through community contribution rather than proprietary development.
Citation of diverse expert voices validates inclusive participation in standards advancement.
Mozilla's role as facilitator (rather than exclusive proprietor) of innovation supports broader scientific participation.
+0.50
Article 19Freedom of Expression
High A=Advocacy (freely published technical knowledge) P=Practice (open access, author attribution, transparent authorship)
Editorial
+0.50
SETL
+0.22
Content is freely published without paywall, censorship, or authentication. Promotes understanding of web technologies through educational explanation. Clear author attribution (Lin Clark) and date (January 17, 2018) support editorial transparency. Comment section enables reader voice and discussion.
FW Ratio: 56%
Observable Facts
Article published without paywall, authentication, or access restriction.
Clear byline: 'By Lin Clark' with author bio and social media link provided.
Publication date clearly stated: 'Posted on January 17, 2018'.
Comment section displays reader discussion and participation with attributed usernames.
Content educates readers about open-source technologies (Rust, Emscripten) and web standards without proprietary gating.
Inferences
Free publication supports freedom of expression and universal access to information about web technology.
Author attribution and transparency establish editorial integrity and accountability.
Open comment section demonstrates structural support for reader voice and association.
Educational framing democratizes technical knowledge typically restricted to specialized training.
+0.50
Article 26Education
High A=Advocacy (free technical education) P=Practice (open-access educational platform, no paywall)
Editorial
+0.50
SETL
+0.22
Content is clearly educational, explaining complex WebAssembly concepts with accessible language and analogies ('like loading an image'). Detailed technical instruction supports developer learning. Author expertise (Lin Clark from Mozilla Advanced Development) adds educational authority.
FW Ratio: 56%
Observable Facts
Article uses analogies and progressive explanation ('Why is this important?') to teach complex concepts accessibly.
Content provides detailed technical education about streaming compilation, tiering, parallelization.
Author attribution identifies Lin Clark as Mozilla researcher ('Advanced Development at Mozilla, with a focus on Rust and WebAssembly').
Publication date and article metadata support educational transparency and verifiability.
No registration, authentication, or payment required for access.
Inferences
Free, clear technical education democratizes knowledge typically available only through formal education or corporate training.
Structured explanation ('Why is this important? ... How does this work?') demonstrates educational pedagogy.
Expert author position supports educational credibility and quality.
Open-access model removes barriers to education for developers regardless of economic status.
+0.30
Article 2Non-Discrimination
Medium F=Framing (explicit parity across device types) P=Practice (WordPress accessibility structure)
Editorial
+0.30
SETL
+0.24
Content explicitly addresses performance parity: 'even on a pretty average mobile device, we can compile at 8 megabytes per second—which is faster than the average download speed for pretty much any mobile network.' No discrimination in benefit allocation across devices.
FW Ratio: 50%
Observable Facts
Article states 'even on a pretty average mobile device' performance is superior to mobile network speeds.
Content draws explicit comparison: desktop 30-60 MB/s vs mobile 8 MB/s, framing mobile performance as sufficient.
Inferences
Explicit device parity framing demonstrates commitment to non-discrimination in performance access.
Accessibility infrastructure on domain supports inclusive access across technical capabilities.
+0.20
Article 1Freedom, Equality, Brotherhood
Medium F=Framing (equal benefit across developer classes)
Editorial
+0.20
SETL
ND
Content frames WebAssembly and compiler improvements as enabling equal capability for all web developers regardless of expertise level or device.
FW Ratio: 67%
Observable Facts
Article emphasizes benefits apply equally to experienced and average developers.
Performance improvements framed as universal advantage, not tiered by skill level.
Inferences
Equal benefit framing supports principle that all developers have equal capacity to participate in web innovation.
+0.20
Article 17Property
Low F=Framing (open-source property rights approach) P=Practice (non-profit ownership supporting community contribution)
Editorial
+0.20
SETL
+0.14
Content discusses intellectual property through open-source framing (Emscripten, Rust, wasm-gc, wasm-snip), emphasizing community development and shared property ownership models.
Content frames these tools as community contributions available to all developers.
Inferences
Open-source property model supports developer rights to use, modify, and contribute to shared tools.
Emphasis on community-driven tools demonstrates property rights through participation rather than ownership restriction.
+0.20
Article 20Assembly & Association
Low P=Practice (comment section facilitates assembly and discussion)
Editorial
+0.20
SETL
+0.14
Content invites reader participation through community discussion: 'If you use Firefox Nightly or Beta, you can give it a try.' Comment section demonstrates editorial openness to diverse perspectives.
FW Ratio: 50%
Observable Facts
Article invites reader participation: 'If you use Firefox Nightly or Beta, you can give it a try on your own device.'
Comment section displays 22 user comments with attributed usernames, demonstrating community discussion space.
Inferences
Invitation to participate supports reader agency in community around technology adoption.
Comment section provides structural infrastructure for peaceful assembly and association of technical community.
+0.10
PreamblePreamble
Medium F=Framing (technological progress as shared human advancement)
Editorial
+0.10
SETL
+0.10
Content frames WebAssembly advancement as progress benefiting humanity through faster, more efficient web access. Emphasizes shared technical innovation rather than individual rights.
FW Ratio: 50%
Observable Facts
Article repeatedly uses 'game changer' language to describe WebAssembly improvements.
Content emphasizes benefits that apply universally across user types and device classes.
Inferences
Framing of technological progress suggests implicit commitment to human advancement through innovation.
Universal benefit language aligns with preamble's collective dignity concept.
+0.10
Article 7Equality Before Law
Low F=Framing (equal protection through universal technical standards)
Editorial
+0.10
SETL
+0.07
Content discusses equal benefit of WebAssembly standards and Mozilla's commitment to equitable web standards; Mozilla's non-profit model (per DCP) supports equal protection rather than profit-driven inequality.
FW Ratio: 50%
Observable Facts
Content emphasizes WebAssembly as open standard available to all developers.
Mozilla's non-profit status (noted in DCP) structures ownership toward public rather than shareholder interest.
Inferences
Open standards framing supports equal protection under shared technical infrastructure.
Non-profit organizational structure reduces profit-driven incentives to discriminate in access.
+0.10
Article 23Work & Equal Pay
Low F=Framing (development tools support professional capability)
Editorial
+0.10
SETL
+0.10
Content discusses web developer tools and compiler performance that enhance developer productivity and professional capability. Faster compilation supports efficient work processes.
FW Ratio: 50%
Observable Facts
Article addresses 'web developers' as primary audience with capability-enhancing tools.
Performance improvements (10-15x faster compilation) directly reduce developer work time.
Inferences
Development tool improvements support developer right to work efficiently and professionally.
Performance optimization reduces labor time required for compilation tasks.
+0.10
Article 25Standard of Living
Low F=Framing (free education as standard of living component)
Editorial
+0.10
SETL
+0.10
Content provides free technical education that contributes to standard of living through knowledge access and professional development opportunity.
FW Ratio: 50%
Observable Facts
Article published without payment barrier, making technical education universally accessible.
Inferences
Free technical education supports development of human capital contributing to adequate standard of living.
+0.10
Article 28Social & International Order
Low F=Framing (universal benefit for international web)
Editorial
+0.10
SETL
+0.10
Content frames performance improvements as universal benefit applicable globally ('web developers,' 'web performance advocates,' no geographic limitation). This supports just conditions for international web order.
FW Ratio: 67%
Observable Facts
Article emphasizes benefits apply universally: 'on a desktop, we compile 30-60 megabytes... Even on a pretty average mobile device.'
No geographic or nationalistic framing; benefits presented as universal.
Inferences
Universal benefit framing supports equitable conditions for web access across international boundaries.
0.00
Article 12Privacy
Medium P=Practice (tracking systems reduce privacy protection)
Editorial
0.00
SETL
+0.10
Article content does not address privacy; neutral on the provision.
FW Ratio: 50%
Observable Facts
DCP indicates Google Analytics and GTM tracking systems deployed on hacks.mozilla.org.
Inferences
Tracking systems create structural privacy risk in tension with Mozilla's public privacy advocacy.
Site implements Google Analytics and GTM tracking with UTM parameter removal utility, indicating awareness of privacy concerns but continued analytics deployment.
Terms of Service
—
Terms of service not observable in provided content.
Mozilla's stated mission around open web and developer empowerment aligns with knowledge-sharing and technical security education.
Editorial Code
+0.05
Article 19
Technical blog format with clear author attribution and date stamps supports editorial transparency.
Ownership
+0.10
Article 19
Mozilla Foundation ownership as non-profit organization supports commitment to public interest over profit-driven content.
Access Model
+0.15
Article 26
Open access technical content published without paywall or registration barrier.
Ad/Tracking
-0.10
Article 12
Google Analytics and GTM tracking present on page reduces privacy score despite Mozilla's privacy advocacy.
+0.40
Article 19Freedom of Expression
High A=Advocacy (freely published technical knowledge) P=Practice (open access, author attribution, transparent authorship)
Structural
+0.40
Context Modifier
ND
SETL
+0.22
Open-access platform with no registration barrier. Author clearly identified. Mozilla's commitment to open web (per DCP) and accessible WordPress structure support structural freedom of expression.
+0.40
Article 26Education
High A=Advocacy (free technical education) P=Practice (open-access educational platform, no paywall)
Structural
+0.40
Context Modifier
ND
SETL
+0.22
Published without registration, paywall, or access restriction. Mozilla's stated educational mission (per DCP) supports commitment to knowledge-sharing. WordPress accessibility structure supports inclusive learning.
+0.40
Article 27Cultural Participation
High A=Advocacy (scientific progress, developer innovation participation) F=Framing (WebAssembly as 'game changer' enabling scientific advancement) P=Practice (open-source tools, community development support)
Structural
+0.40
Context Modifier
ND
SETL
+0.46
Mozilla non-profit model (per DCP) commits to developer empowerment and open web standards. Open-source tools (Emscripten, Rust, wasm-gc) discussed as community-driven scientific advancement. Firefox development as collaborative advancement demonstrates structural support for scientific participation.
+0.10
Article 2Non-Discrimination
Medium F=Framing (explicit parity across device types) P=Practice (WordPress accessibility structure)
build 016f8e2+yecc · deployed 2026-02-28 13:29 UTC · evaluated 2026-02-28 13:29:16 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.