The Great CoffeeScript to Typescript Migration of 2017
> This post is longer than most. We wanted to capture the massive scope of migrating hundreds of thousands of lines of CoffeeScript to TypeScript. We share how we picked TypeScript in the first place, how we mapped out the migration, and when things didn’t go according to plan.
is-promise post mortem
> I had been intending to set up more of my projects to be automatically published via CI, instead of manually published from my local machine, but because is-promise is such a tiny library, I figured it probably wasn’t worth the effort. This was definitely a mistake. However, even if I had setup publishing via CI is-promise may not have had sufficiently thorough tests.
Porting to TypeScript Solved Our API Woes
> With the Ruby backend, we sometimes forgot that a particular API property held an array of strings, not a single string. Sometimes we changed a piece of the API that was referenced in multiple places but forgot to update one of those places. These are normal dynamic language problems in any system whose tests don’t have 100% test coverage. (And it will still happen even with 100% coverage; it’s just less likely.)
Fixing memory leaks in web applications
> Part of the bargain we struck when we switched from building server-rendered websites to client-rendered SPAs is that we suddenly had to take a lot more care with the resources on the user’s device. Don’t block the UI thread, don’t make the laptop’s fan spin, don’t drain the phone’s battery, etc. We traded better interactivity and “app-like” behavior for a new class of problems that don’t really exist in the server-rendered world.
> One of these problems is memory leaks. A poorly-coded SPA can easily eat up megabytes or even gigabytes of memory, continuing to gobble up more and more resources, even as it’s sitting innocently in a background tab. At this point, the page might start to slow to a crawl, or the browser may just terminate the tab and you’ll see Chrome’s familiar “Aw, snap!” page.
Don't touch my clipboard
> You can (but shouldn’t) change how people copy text from your website.
The Curious Case of WebCrypto Diffie-Hellman on Firefox - Small Subgroups Key Recovery Attack on DH
> Mozilla Firefox prior to version 72 suffers from Small Subgroups Key Recovery Attack on DH in the WebCrypto’s API. The Firefox’s team fixed the issue removing completely support for DH over finite fields (that is not in the WebCrypto standard). If you find this interesting read further below.
Unintuitive JSON Parsing
Based on the title, could be just about anything...
> The parser will not complain about leading zeros because JSON has no concept of leading zeros.
Unexpectedly a parse error, not a lex error.
Remote Code Execution in Firefox beyond memory corruptions
> Browsers are complicated enough to have attack surface beyond memory safety issues. This talk will look into injection flaws in the user interface of Mozilla Firefox, which is implemented in JS, HTML, and an XML-dialect called XUL. With an Cross-Site Scripting (XSS) in the user interface attackers can execute arbitrary code in the context of the main browser application process. This allows for cross-platform exploits of high reliability. The talk discusses past vulnerabilities and will also suggest mitigations that benefit Single Page Applications and other platforms that may suffer from DOM-based XSS, like Electron.
And it was Uphill Both Ways
> In fact, shortly after I made my own personal home page, full of <marquee> tags, creative abuse of the <font> tag, and a color scheme which was hot pink and neon green, I showed it to a friend, who condescendingly said, “What, you didn’t even use frames?” He made me mad enough that I almost deleted my Geocities account.
Nice look back at how we used to do things.
> In this era, we’d call stuff like this “DHTML” (the D is for “dynamic”), and we traversed the DOM as a chain of properties, doing things like document.forms.inputs to access fields on the form.
An introduction to D3.js
> So, you want to create amazing data visualizations on the web and you keep hearing about D3.js. But what is D3.js, and how can you learn it? Let’s start with the question: What is D3? While it might seem like D3.js is an all-encompassing framework, it’s really just a collection of small modules.
The Baseline Interpreter: a faster JS interpreter in Firefox 70
> The Baseline Interpreter sits between the C++ interpreter and the Baseline JIT and has elements from both. It executes all bytecode instructions with a fixed interpreter loop (like the C++ interpreter). In addition, it uses Inline Caches to improve performance and collect type information (like the Baseline JIT).
The story of a V8 performance cliff in React
High-performance input handling on the web
> There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.
> In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.
Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/
Getting Into Browser Exploitation
Last post in series, toc at the top.
> 0x00: New Series: Getting Into Browser Exploitation
> 0x02: The Butterfly of JSObject
> 0x04: WebKit RegExp Exploit addrof() walk-through
> 0x05: The fakeobj() Primitive: Turning an Address Leak into a Memory Corruption
> 0x07: Preparing for Stage 2 of a WebKit exploit
> 0x08: Arbitrary Read and Write in WebKit Exploit
Bringing service workers to Google Search
> The story of what shipped, how the impact was measured, and the tradeoffs that were made.
Quite long. Considers a variety of aspects.
Trash talk: the Orinoco garbage collector
> Over the past years the V8 garbage collector (GC) has changed a lot. The Orinoco project has taken a sequential, stop-the-world garbage collector and transformed it into a mostly parallel and concurrent collector with incremental fallback.
How 2 TypeScript: Get the last item type from a tuple of types
> Kinda like a normal array lookup!
> But what if you don’t know the length of the tuple? Hmm... how do we get TypeScript to tell us the length and then let us use that length to pick out the last item, all at compile time?