11 ms·

One big issue with NPM is that JS stdlib is extremely bare bones and the ecosystem swings far into the other direction to compensate, which leads to many librar

by lhorie 5y ago

One big issue with NPM is that JS stdlib is extremely bare bones and the ecosystem swings far into the other direction to compensate, which leads to many libraries pulling in convenience utils that pull in their own convenience utils ad infinitum. So you, as a consumer of a toolkit like Rome, might be forced to download crap like function-bind@1.0.1 even though that is only pulled in as a deep transitive dep for some ancient obscure thing that wanted to support IE6 or something. With Rust and other compiled languages, this isn't as much of an issue since even a "bloated" binary for a single architecture is still orders of magnitude faster to download than a constellation of packages each supporting an arbitrary subset of Node runtime versions. with this said, there may also be a novelty factor in play here. Rust can definitely be considered the "new shiny thing" for this team, and with only a few weeks of Rust under their belt, they might still be well within the honeymoon phase. I can think of at least one major aspect in this space that becomes harder with a move to Rust: the only fully complete Typescript type checking implementation in existence is written in JS/TS, and I expect that type-aware tooling is going to sprout there first. The Typescript team in particular seems fairly uniquely positioned to be able to deliver some sort of type-aware compiler mode similar to google closure advanced mode. In comparison, IMHO it's not a super compelling story for Rome to say they're going to provide a fast, unified web dev toolkit that... doesn't typecheck (due to poor interop with the JS ecosystem/community). The esbuild ecosystem is already there today and forging ahead with the force of the OSS community behind it. Bun.sh is taking a completely different approach by standing on the shoulders of giants. Last I heard, they were leveraging the ubiquity of C ABI - via zig - to leverage JavascriptCore, and looking into V8 bindings, and focusing on lightning fast hot reloading instead of reinventing parsing. Rome seems to be approaching implementation from a first-principles angle, which seems most similar to esbuild's approach, but that first movers advantage is long gone though.

pornel 5y ago
Rust's stdlib is similarly bare-bones. Rust/Cargo has the same mindset of many small packages as JS/npm. The difference is that in JS abstraction and indirection has a run-time cost, so doing things via packages adds overhead. In Rust, you can have zero-cost abstractions that optimize away. The runtime and code-size cost is often the same whether you call code from a generic 3rd party crate or write it yourself inline in your function.
Jarred 5y ago
Hi, author of Bun here > they were leveraging the ubiquity of C ABI - via zig - to leverage JavascriptCore, and looking into V8 bindings, and focusing on lightning fast hot reloading instead of reinventing parsing This isn’t entirely correct. Bun embeds JavaScriptCore similarly to how Node.js embeds V8. Bun doesn’t use JavaScriptCore for parsing and there are no plans for V8 bindings. Bun uses a new JavaScript parser based on esbuild’s JavaScript parser but ported (by me) to Zig. There are very few large external libraries in use by Bun — just JavaScriptCore. Extremely fast hot module reloading is a priority though :)

by lhorie 5y ago

pornel 5y ago

Rust's stdlib is similarly bare-bones. Rust/Cargo has the same mindset of many small packages as JS/npm. The difference is that in JS abstraction and indirection has a run-time cost, so doing things via packages adds overhead. In Rust, you can have zero-cost abstractions that optimize away. The runtime and code-size cost is often the same whether you call code from a generic 3rd party crate or write it yourself inline in your function.

Jarred 5y ago

Hi, author of Bun here > they were leveraging the ubiquity of C ABI - via zig - to leverage JavascriptCore, and looking into V8 bindings, and focusing on lightning fast hot reloading instead of reinventing parsing This isn’t entirely correct. Bun embeds JavaScriptCore similarly to how Node.js embeds V8. Bun doesn’t use JavaScriptCore for parsing and there are no plans for V8 bindings. Bun uses a new JavaScript parser based on esbuild’s JavaScript parser but ported (by me) to Zig. There are very few large external libraries in use by Bun — just JavaScriptCore. Extremely fast hot module reloading is a priority though :)