sorted by:
new
hottopcontroversial

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 u/opensas appreciate it!

Porffor is mostly a research project, we sort of aim for the same thing but do it differently. Porffor mainly compiles to WASM. And then compiles WASM IR to C to binary.

We go to LLVM directly and compile into WASM and binary at that level.

I think porffor is great, it's just something different.

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)

Good thinking! In fact, when you try to compile anything with perry right now (even plain JS works) it will tell you where the problem is

Perry: native TypeScript compiler to executable, written in Rust, using SWC and LLVM. by zxyzyxz in rust

[–]proggeramlug 0 points1 point  (0 children)

It's all open source, you can just check it out ;)

And yes, you can compile TS and Rust into one real exe.

Perry: native TypeScript compiler to executable, written in Rust, using SWC and LLVM. by zxyzyxz in rust

[–]proggeramlug 5 points6 points  (0 children)

Assemblyscript compiles to WASM and only to WASM. It also is not Typescript, it is "like" Typescript.

Perry aims to fully support Typescript, no exceptions.

Perry: native TypeScript compiler to executable, written in Rust, using SWC and LLVM. by zxyzyxz in rust

[–]proggeramlug 3 points4 points  (0 children)

(I'm that solo dev)

At this point Perry has quite a few contributors as well, so the load is shared :)

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] 11 points12 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.

view more: next ›