Lennar Lead Software Engineer Oleksandr Moskalenko on Knowing What the Standard Library Already Does Before You Reach for a Package

A full-stack engineer who has shipped production software in TypeScript, Node.js, C#, PHP and Rust, and who spends his working life trimming bloat out of web applications, brought a simple question to the Zero Dependency 2026 hackathon: how much of what developers install could they have written with the platform they already had?

String.prototype.padStart() has been part of JavaScript since 2017. In 2016, the year before it arrived, a developer unpublished left-pad, an npm package of eleven lines that did the same job, and broke Babel, React and thousands of builds across the internet. The lesson most of the industry took was that packages should not be allowed to vanish. The lesson the Zero Dependency 2026 organisers wanted to draw out was a different one: a string-padding function should never have needed to be a package in the first place.

Ten years later the scale of that habit is easy to measure. The average npm project carries 49 direct and 79 transitive dependencies, according to figures the organisers cited, and a modern web application can pull in 1,200 or more once the full tree is counted. Roughly 16.8 percent of npm packages are trivial one-liners. Every one of them is code that ships to a user’s browser or runs on a server, and every one of them is a dependency somebody could compromise.

Oleksandr Moskalenko works inside that ecosystem every day. He is a Lead Software Engineer at Lennar, working full-stack across TypeScript, Node.js, React, Next.js and Rust, and the founder of Video-Audit.com. Over his career he has shipped software in TypeScript, Node.js, C#/.NET, PHP and Rust, and he has spent nearly a decade in web engineering. At Lennar he leads workshops and code reviews for a team of more than 20 developers. His focus, in his own description, is trimming web bloat and optimising raw browser execution, and he has spent years building custom client-side analytics tools, vector search backends and full-stack e-commerce migrations by preferring low overhead and native implementation over large third-party dependency trees.

Zero Dependency 2026, organised by Hackathon Raptors, ran for 72 hours from August 28 to 31 with one rule: ship something genuinely useful with an empty dependency manifest, using only the standard library of the chosen language. 295 projects were submitted and judged. The event’s own summary described what Moskalenko brought to the panel as a working knowledge of what each runtime’s standard library covers natively, which is exactly what the event’s Zero-Dependency Craft criterion, worth 30 percent of the score, set out to measure.

Five runtimes, five standard libraries

Most engineers know one standard library well and the others by reputation. Moskalenko’s career has taken him through several, and in his judge statement he said that working across multiple runtime environments had given him a concrete understanding of what each standard library can handle natively before anyone touches a package manager.

That knowledge matters because the gap between languages is large and not always where people expect it. Node.js ships an HTTP server, a file watcher, streaming compression, cryptographic primitives and, in recent versions, built-in styling for terminal text. Rust’s standard library is deliberately small: it has no HTTP client and no JSON parser, which is why the event’s rules spelled out that a Rust entry could not use any crates, including serde. Go sits in between, with a strong networking and encoding library and a firm line between the standard library and the extended golang.org/x packages, which the event’s rules treated as off limits. C# and .NET ship a large base class library. PHP was built for the web and includes much of what a web application needs in the runtime itself.

An engineer who has worked across all of these can read a zero-dependency submission and tell quickly whether a team rebuilt something the platform already provided, or whether it did the harder work of replacing something the platform lacks. The first is wasted effort. The second is the craft the event was designed to reward.

Web bloat as a cost you can measure

Moskalenko’s day job turns that knowledge into numbers. At Lennar he recently reworked rendering workflows and network interactions on search results pages, improving their Core Web Vitals by 150 percent. He built the company’s Guided Search platform, which loads 2.5 times faster than the legacy pages it replaced, and pioneered Lennar’s migration to Next.js 15 and React 19 Server Components without downtime. He also led the rollout of a semantic search system built on vector search and a fine-tuned language model that cut operational costs by 99 percent and improved response speed by 50 percent.

Before Lennar, he spent five years at Mira Commerce leading headless e-commerce migrations, work that drove a 30.5 percent increase in orders and a 120 percent improvement in mobile Core Web Vitals.

Those numbers describe a specific discipline. Core Web Vitals measure how quickly a page renders its main content, how fast it responds to input, and how stable its layout stays while loading. Every kilobyte of JavaScript a browser has to download, parse and execute pushes those measures in the wrong direction. A dependency tree is not only a security question for a front-end engineer. It is a performance budget, and every package spends part of it. That is why the Zero Dependency question reads to someone in his position less as a purity exercise and more as an extension of what performance work already demands: know what the platform does, and only ship what the platform cannot.

A Rust kernel in the browser with nothing uploaded

The project that most directly anticipates the event’s constraint is his own. At Video-Audit.com, Moskalenko built a custom analysis kernel in Rust, compiled to WebAssembly, that audits video for photosensitive epilepsy hazards entirely in the browser, with zero server uploads.

That design choice removes a whole category of supplier from the system. There is no server to host, no upload pipeline to secure, and no third-party processing service holding a user’s footage. The video never leaves the device. The trade is that the analysis has to run within what a browser and a compiled Rust module can do on their own, which is the same kind of trade every Zero Dependency team made: accept a narrower toolbox in return for a system with fewer moving parts and fewer places for trust to break.

The event’s rules pointed participants toward exactly this kind of work. Its Developer Tools track asked for single runnable artifacts with a clean command-line surface built on standard-library argument parsing, file walking and output. Its Open track asked for “anything genuinely useful that a reasonable engineer would assume needs packages.” A browser-side media kernel in Rust fits the second description closely.

Sockets, byte buffers and parsers written by hand

In his judge statement, Moskalenko said he would look at submissions from a pure systems and engineering perspective. He named the kinds of work he wanted to see: working directly with sockets and byte buffers to build a standalone server from scratch, writing a command-line interface without helper packages, and implementing precise string processing and parsing logic. He said he wanted teams to replace hidden abstractions with their own craft, and that he would weigh how effectively an entry pushed its language’s standard library to deliver a fast, useful tool that works with an empty manifest.

The projects that finished at the top of Zero Dependency 2026 did that kind of work. First place went to zql, from Team Rocket, a read-only SQL engine on the Rust standard library that speaks the PostgreSQL v3 wire protocol, so existing psql and Node clients connect to it unmodified. It shipped with 295 passing tests, a dependency tree of a single node, and a differential test suite that checks its answers against SQLite. Choosing to implement an existing wire protocol, rather than inventing a new one, meant every existing client became a test harness.

The Package Killer award went to zdh, from The Goated Duo, an HTTP/2 server on the Go standard library that replaces golang.org/x/net/http2 and its HPACK package outright: all ten frame types, hand-built Huffman tables, flow control and stream state, running over raw TCP with no net/http underneath. That is a standalone server built from sockets and byte buffers in the most literal sense.

In the event’s Excellence tier, bindery, from c0nfig, turned a folder of Markdown into a documentation site with search, dark mode, hand-rendered diagrams and a from-scratch RFC 6455 WebSocket for live reload. Anyone who has built documentation tooling in the JavaScript ecosystem knows how many packages that list usually implies: a Markdown parser, a syntax highlighter, a search index, a WebSocket library, a file watcher and a development server.

The STDLIB.md receipt

The event required every team to submit a STDLIB.md, a file naming each package they would normally have installed and the standard-library feature they used instead. It was the receipt that made the constraint judgeable, and it fed directly into Zero-Dependency Craft. For a reviewer who knows several runtimes, this document is where a submission either shows understanding or gives itself away. A thin list suggests a team avoided packages without thinking about them. A detailed one shows a team that knows which platform feature does which job, and what it gave up by using it.

The event’s Write-Up Side Quest produced some of the clearest examples of that thinking. The first-place write-up, by Sai Ram Dash, described replacing eleven everyday npm packages and running 856,168 differential checks against the originals, to the point of testing the package being replaced when the semver library’s intersects() function gave opposite answers depending on argument order. The second-place write-up, by Pal Ghevariya, described building the JSONTestSuite harness before writing a JSON parser in Rust, then watching 19 of 47 must-reject number fixtures slip through Rust’s f64::from_str and writing a number state machine by hand in response.

Both are stories about precise string processing and parsing, the area Moskalenko named in his statement. They are also stories about a standard library’s edges. Rust’s float parser is correct for its purpose, but it accepts inputs that the JSON specification rejects. An engineer who assumes the standard library is a validator ships a parser that accepts invalid JSON. An engineer who tests against the specification finds the gap and closes it.

Idiomatic, or a fight against the platform

The event’s Code Quality and Idiom criterion, worth 25 percent of the score, asked whether a submission read as idiomatic to a senior reviewer in its language, or as a fight against the standard library. For someone who runs code reviews across TypeScript and Rust for a team of more than 20 developers, that distinction is a daily judgement.

A hand-rolled implementation can fail that test in two directions. It can reinvent something the platform already provides, adding code that a reviewer has to maintain for no gain. Or it can work around the platform in ways that ignore how the language is meant to be used: ignoring Node’s streaming model, wrapping Rust’s ownership rules in unnecessary copies, or forcing a single-threaded design where the runtime offers a clear concurrency primitive. An engineer who knows several runtimes can tell the difference between code that uses a small standard library well and code that is struggling against it.

The event’s organisers drew a conclusion from the whole field that fits this reading. The empty manifest, they wrote, turned out to be a test of honesty more than cleverness. The teams that did well disclosed where a language forced a compromise, wrote a STDLIB.md that named every substitution and what it cost, and built tools that check the manifest on every build rather than claiming it once.

What front-end engineering can take from an empty manifest

Most production web applications will never ship with an empty manifest, and the Zero Dependency 2026 organisers said as much: the point was not to oppose libraries but to test whether developers still know what is underneath them. That is the habit Moskalenko’s career has been built on. A 150 percent improvement in Core Web Vitals does not come from adding another package. It comes from knowing what the browser does natively, what the framework does on top of it, and which layers can be removed without losing anything a user would notice.

The practical lesson for engineering teams is modest and specific. Before adding a dependency, check what the runtime already offers. When the runtime falls short, write down why the package is needed and what it costs in bytes, in maintenance and in trust. Review the list regularly, because runtimes keep growing. The function that needed a package in 2016 has been part of the language for years.

Zero Dependency 2026 asked teams to do that exercise in its most extreme form for 72 hours. The results showed that a standard library, in the hands of someone who knows it well, covers far more ground than most developers assume. For an engineer whose job is making web applications lighter and faster, that is less a surprise than a confirmation.

Zero Dependency 2026 was organized by Hackathon Raptors, a Community Interest Company supporting innovation in software development. The event ran for 72 hours from August 28 to 31, 2026, and 295 projects were submitted and judged, each built with an empty dependency manifest using only the standard library of its language. Oleksandr Moskalenko served as a judge evaluating submissions on Functionality & Usefulness, Zero-Dependency Craft, Code Quality & Idiom, and Innovation.