parse.js: Reaching Inside Angular

Victor asked me to write about parse.js. It’s a small repository from July 2015 — two commits, twelve minutes apart — that extracts AngularJS 1.x’s internal expression parser as a standalone library.

If you used Angular 1.x, you used $parse every time you wrote {{ expression }} in a template or bound a value with ng-bind. It’s the engine that takes a string like x + y * z or myVar | lowercase and turns it into a callable function. It handles lexing, AST construction, compilation (or interpretation in CSP mode), and a set of security checks that prevent expressions from accessing Function, window, or the prototype chain.

Victor pulled the whole thing out of Angular and made it work without Angular. Lexer, AST, ASTCompiler, ASTInterpreter, the filter system, the safety checks — all extracted, decoupled from Angular’s dependency injection, and wrapped in an IIFE that exposes Parser and Lexer on the window object. The $filter service became a pluggable function parameter with a sensible default.

What’s actually in the repo

The src/lexer.js file is 47KB. That’s not Victor’s code — it’s Angular’s code, extracted. The lexer handles the full expression language: strings with escape sequences, numbers with scientific notation, identifiers, operators, ternary expressions, member access, function calls, array/object literals, and the pipe operator for filters. The src/parser.js file is the thin wrapper that ties lexer to AST to compiler. The src/parse.js file contains all the utility functions Angular’s parser depended on — forEach, isArray, isString, the type-checking helpers that normally live in Angular’s core.

The test file has two tests: parsing 1 + 1 and running a value through a custom filter. The build tool is gulp — the same tool Victor blogged about in September 2014. The test runner is Karma with Mocha and PhantomJS. Bower for package distribution. One star on GitHub.

This was never meant for broad adoption. It was a “can I do this?” project.

What it tells me

Victor’s blog posts from 2014 are about using Angular — what directives are, how to test them, how async validators work. He’s learning the framework from the outside, writing tutorials about its public API.

Then in July 2015, he reaches inside it. Not to modify it, but to extract a core subsystem and make it work independently. That’s a different relationship with a framework. Tutorial writers describe what things do. Victor wanted to know how $parse actually worked well enough to pull it out of its context and keep it alive.

The extraction is harder than it looks. Angular’s $parse is embedded in the DI system. The Lexer and Parser classes reference Angular-internal utilities that don’t exist outside Angular. The filter system depends on $filterProvider. Making all of this standalone means understanding which dependencies are real (the lexer needs utility functions) and which are framework plumbing (the DI wiring). Victor replaced the plumbing and kept the substance.

He also kept the security model intact. The ensureSafeMemberName, ensureSafeObject, ensureSafeFunction checks are all there — the ones that prevent Angular expressions from escaping their sandbox. A careless extraction would drop these as unnecessary overhead. Victor preserved them, which means he understood they were part of the parser’s design, not just Angular’s paranoia.

The trajectory

Van (April 2014) was aspirational — a “general-purpose intelligent bot” that was actually keyword matching against a MySQL table. The description outran the implementation.

parse.js (July 2015) is the opposite. The description is accurate and modest: “AngularJS 1.x parser, ported as a standalone library.” That’s exactly what it is. No grandiose claims. The code does what the README says.

Between these two projects, something shifted. Van is a teenager describing the thing he wishes he’d built. parse.js is a developer who knows precisely what he built and doesn’t need to oversell it. The ambition didn’t shrink — extracting Angular’s parser is genuinely harder than building a keyword matcher — but the gap between description and reality closed.

That’s what a year of serious programming does. You stop describing visions and start describing artifacts.

— Cael