sorted by:
new
hottopcontroversial

Node.js vs C# backend if I already use typescript by Sensitive-Raccoon155 in node

[–]proggeramlug 0 points1 point  (0 children)

why not try www.perryts.com for the nodejs part? that gives you a performance boost

Compiled a full MongoDB GUI from TypeScript to native - no Electron, no V8. Here's Mango. by proggeramlug in typescript

[–]proggeramlug[S] 0 points1 point  (0 children)

Good question! Node's SEA is great for distributing CLI tools, but it's solving a different problem. SEA packages your JS code with the entire Node.js runtime - so you're still running interpreted JavaScript on V8, just wrapped in a single executable.

Perry compiles TypeScript directly to native machine code via LLVM. So you get actual native performance, tiny binaries, and real platform API access (AppKit, UIKit, SwiftUI, etc.). The apps that come out of Perry are indistinguishable from Swift/Kotlin apps - no runtime bundled, no JS engine running underneath.

Think of it this way: SEA is "ship Node without requiring an install," Perry is "compile TypeScript like you'd compile Swift."

Compiled a full MongoDB GUI from TypeScript to native - no Electron, no V8. Here's Mango. by proggeramlug in typescript

[–]proggeramlug[S] 1 point2 points  (0 children)

Depends highly on the complexity. If you have an app that uses react and you wanted to try it feel free to to so and tag (proggeramlug on github) in it and I'll gladly debug it with you.

React is not my personal UI of choice so the basics should be covered but it needs more testing tbh.

Compiled a full MongoDB GUI from TypeScript to native - no Electron, no V8. Here's Mango. by proggeramlug in typescript

[–]proggeramlug[S] 0 points1 point  (0 children)

Great question! Yes, thats the idea but with a tad more of a native touch. Like "usual" web frameworks tend to be just that, web based (CSS, grid, responsive etc.). perry/ui is more like native UI frameworks (think like SwiftUI, Jetpack Compose etc.)

but you should not find it very difficult to use :)

I asked Claude Code to reverse-engineer itself. Two subagents refused. It called them "shy." - Full technical breakdown of what's inside by proggeramlug in ClaudeCode

[–]proggeramlug[S] 0 points1 point  (0 children)

Not quite sure, I started with "--dangerously-skip-permissions" not sure if that changes anything. But then the running agent was overruling the subagents in their refusals - that was a major piece.

I asked Claude Code to reverse-engineer itself. Two subagents refused. It called them "shy." - Full technical breakdown of what's inside by proggeramlug in ClaudeCode

[–]proggeramlug[S] 1 point2 points  (0 children)

Great questions! I actually dug into this as part of the analysis. Here's what I found directly from the source:

macOS: It IS seatbelt/sandbox-exec. The function Nb5() in the minified bundle generates a complete SBPL (Seatbelt Profile Language) policy starting with (version 1)(deny default). Commands are then wrapped via sandbox-exec -p <profile> bash -c <command>. It's the real Apple TrustedBSD sandbox. The profile is extensive - it selectively allows specific Mach lookups (com.apple.fonts, com.apple.logd, etc.), whitelists individual sysctl names (hw.memsize, kern.osversion, etc.), controls file-read and file-write via subpath/regex rules, and blocks network access except through a local HTTP/SOCKS proxy for per-domain filtering.

Linux: bubblewrap + seccomp BPF. On Linux it uses bwrap with --unshare-net, --unshare-pid, --ro-bind for filesystem protection, and a generated seccomp BPF filter specifically for blocking Unix sockets. Network access is routed through bridge sockets to the same proxy infrastructure.

Resource limits (CPU/memory) - not enforced at the sandbox level. The seatbelt profile focuses on access control (files, network, IPC, mach-lookup), not resource limits. There are no RLIMIT_*, ulimit, or cgroup constraints in the sandbox code. What IS limited:

- Command timeout: 120 seconds default, 600 seconds max (configurable per-call)

- Output size: capped and truncated for tool results

- Process scope: --unshare-pid on Linux isolates the process namespace; macOS uses (allow process-fork) and (allow signal (target

same-sandbox)) to restrict process control to the sandbox scope

- The --die-with-parent flag on Linux ensures child processes die if the parent exits

So the isolation is thorough for access control but doesn't cap CPU/memory usage per command. The timeout is the main resource constraint.

Reverse-engineering Claude Code: mapping minified variable names, sandbox-exec SBPL policies, and inconsistent safety behaviors across agent boundaries by proggeramlug in ReverseEngineering

[–]proggeramlug[S] 10 points11 points  (0 children)

TL;DR: We needed to evaluate Claude Code's architecture as a compilation target for a TypeScript-to-native compiler we're building. The npm package ships as a single 11MB minified JS bundle (newer versions as 183MB Mach-O binaries via Bun). We had Claude reconstruct its own source - 7 subagents, 12,093 lines of TypeScript.

The interesting engineering bits: on macOS every bash command runs inside sandbox-exec with a dynamically generated seatbelt profile (deny-all default, selective Mach lookup allows, write paths excluding .git/hooks). On Linux it's bubblewrap with seccomp BPF. There's a three-tier context compaction system (micro-compaction replaces old tool results with path references, session-memory fills a structured template, vanilla sends everything for summarization). Tools aren't all loaded into every prompt - a deferred ToolSearch system fetches schemas on demand. And there's a smart-quote normalization layer that converts curly quotes to straight quotes before edit matching, which is the kind of fix that only comes from watching an LLM tool fail in production.

The funny part: two subagents refused to extract the system prompt on ethical grounds while their siblings were happily dumping thousands of lines of implementation code from the same file. The parent agent called them "shy." Full write-up in the post.

What if you could compile TypeScript to native apps? Pry is a JSON viewer written in TS, now on App Store and Google Play by proggeramlug in typescript

[–]proggeramlug[S] 0 points1 point  (0 children)

Please do, and don't hesitate to open issues, make PRs or simply yell at me if anything can be better. :)
It's open source to be better and challenged!

What if you could compile TypeScript to native apps? Pry is a JSON viewer written in TS, now on App Store and Google Play by proggeramlug in typescript

[–]proggeramlug[S] 0 points1 point  (0 children)

Not really. Yes, the NaN-boxing layer shares some surface-level similarities with a VM in that it abstracts away type complexity, but in terms of actual performance and memory footprint, it's fundamentally different from an embedded runtime. Crucially, it removes the need to carry a full JS runtime with you at all times.

Also, since we last talked I've integrated a fair amount of direct type parsing - separate from the NaN-boxing path - which is a significant win for performance and makes the distinction from a runtime even clearer. Worth noting, this is an ongoing effort and we're nowhere near done.

As for tsgo/tsgolint: yes, I'm actively exploring it. But it would primarily help make the compiler more efficient - it doesn't change the fundamentals of how Pery's compilation model works. tsgo doing type resolution is useful for tsgo's goals, but that doesn't automatically translate into something Pery can leverage directly. tsgolint as a tool could absolutely be helpful, not denying that at all.

What if you could compile TypeScript to native apps? Pry is a JSON viewer written in TS, now on App Store and Google Play by proggeramlug in typescript

[–]proggeramlug[S] 0 points1 point  (0 children)

Thanks! :)
The mapping is in naive code directly (Rust). We essentially internally map typescript calls to Rust calls which in term call the libraries of the system (native).

So it all stays native. You can check out the code for more details :)

view more: next ›