The cost of parsing JSON
The dominant costs of processing JavaScript are download and CPU execution time.
V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++.
Visit v8.dev → RSS feedOn Hacker News Dec 2018 – Aug 2025
Web & Frontend 11Systems & Performance 10Software Engineering 8Security & Privacy 3Math & Algorithms 1
The dominant costs of processing JavaScript are download and CPU execution time.
The V8 Lite project dramatically reduced the memory overhead of V8 on typical websites, this is how we did it.
This post explains our recent effort to improve JSON.stringify performance
Faster JavaScript calls by removing the arguments adaptor frame
A recent article on WebAssembly Garbage Collection (WasmGC) explains at a high level how the Garbage Collection (GC) proposal aims to better support GC languages in Wasm, which is very important given their popularity. In this article, we will get into the technical details of how GC languages such as Java, Kotlin…
The V8 team details their analysis and mitigation strategy for Spectre, one of the top computer security issues of 2018.
V8 v7.4 supports JavaScript execution without allocating executable memory at runtime.
The Explicit Resource Management proposal empowers developers to explicitly manage the lifecycle of resources.
In V8 v9.1 we’re improving V8 performance by 5–15% with Sparkplug: a new, non-optimizing JavaScript compiler.
V8 features a lightweight, in-process sandbox to limit the impact of memory corruption bugs
WABT gains a new decompilation tool that can make it easier to read the contents of Wasm modules.
V8 v7.2 features high-speed JavaScript parsing, faster async-await, reduced memory consumption on ia32, public class fields, and much more!
This document explains the WebAssembly tail calls proposal and demonstrates it with some examples.
V8’s Math.random implementation now uses an algorithm called xorshift128+, improving the randomness compared to the old MWC1616 implementation.
Eliminating use-after-frees vulnerabilities in Chrome with heap scanning.
Thanks to recent work in Chrome and Emscripten, you can now use up to 4GB of memory in WebAssembly applications. That’s up from the previous limit of 2GB. It might seem odd that there was ever a limit - after all, no work was needed to allow people to use 512MB or 1GB of memory! - but it turns out that there are some…
This technical deep-dive explains how V8 handles JavaScript properties behind the scenes.