LOOK: Rethinking Web Backend Architecture with a Single-Binary Programming Language Modern web backend development has become increasingly dependent on layers of frameworks, packages, configuration files, runtime components, and deployment infrastructure. A simple REST API endpoint can require a programming language, a web framework, a package manager, database drivers, authentication libraries, caching systems, queue systems, a web server, and multiple configuration layers before the actual application logic even begins. This raises a fundamental question: What if the web backend runtime itself provided most of these building blocks? That question led us to create LOOK — a web-focused programming language and runtime built from scratch using modern C++23. LOOK is designed around a simple idea: Don't add another framework to the web stack. Reduce the stack itself. What Is LOOK? LOOK is a programming language specifically designed for web backend development. It is distributed as a single binary, with HTTP, routing, WebSocket, SSE, database connectivity, sessions, authentication, validation, caching, queues, concurrency primitives, templates, and other web-oriented capabilities integrated into the runtime. The goal is not simply to create another scripting language. The goal is to reduce the number of independent components required to build and deploy a modern web application. Instead of: Language + Framework + HTTP Server + Database Drivers + Authentication Packages + Cache + Queue + Realtime Library + Template Engine + Deployment Configuration LOOK aims for: LOOK ├── Language ├── Runtime ├── HTTP ├── Routing ├── WebSocket ├── SSE ├── Database ├── Sessions ├── Authentication ├── Cache ├── Queue ├── Templates └── Concurrency This is the architectural idea behind the project. The Core Philosophy LOOK follows three simple principles: 1. Drop it, run it The runtime is distributed as a portable binary. The objective is to avoid requiring a large runtime installation or a complicated dependency tree just to start a web application. 2. Explicit scope LOOK favors explicit modules and service access instead of hidden application-wide behavior. The module system and APIs are designed to make dependencies visible and understandable. 3. No framework required LOOK does not require developers to install a separate web framework before building a web application. Routing, HTTP handling, WebSocket, SSE, database access and other core web capabilities are part of the runtime. Built for the Web from the Beginning Many programming languages are general-purpose languages that later acquire web frameworks. LOOK takes the opposite direction. Web development is one of the primary design targets of the language. A route can be defined directly in LOOK: route("GET", "/users/{id}", function($req) { return response::json([ "id" => $req.params["id"] ]) }) The same runtime can handle: HTTP REST APIs WebSocket Server-Sent Events FastCGI database access sessions authentication background jobs caching This reduces the conceptual distance between application code and the web runtime. The Runtime Architecture LOOK is implemented in C++23. Its execution pipeline is designed around a bytecode-based virtual machine. At a high level: LOOK Source (.lk) │ ▼ Lexer │ ▼ Parser │ ▼ AST │ ▼ Register Bytecode │ ▼ LOOK VM │ ▼ Persistent Runtime │ ├── HTTP ├── WebSocket ├── SSE ├── Database ├── Cache ├── Queue └── Application Logic LOOK also contains a tree-walking execution path, which provides a useful baseline for runtime development and performance comparison. Project benchmarks report that the bytecode VM can provide approximately 41× speed improvement over tree-walking execution for the tested CLI workload. The VM benchmark is an implementation measurement rather than a universal language benchmark, but it demonstrates why the runtime architecture matters. Single-Binary Deployment One of the most important LOOK features is its deployment model. A typical application can be deployed with the LOOK runtime as a binary rather than requiring a large collection of runtime components. LOOK supports: Linux Windows Docker Plesk CGI FastCGI Direct HTTP serving The idea is straightforward: Build ↓ Copy binary ↓ Run This can significantly simplify deployment for small servers, internal applications, VPS environments and controlled production infrastructures. FastCGI and Persistent Runtime LOOK supports a persistent FastCGI execution model. Instead of rebuilding the runtime environment for every request, the application can remain loaded inside long-running workers. This enables resources such as database connections and runtime structures to be reused through connection pooling. Conceptually: Application startup ↓ Load LOOK application ↓ Initialize runtime ↓ Initialize connection pools ↓ Worker │ ┌────┼────┐ ↓ ↓ ↓ Req1 Req2 Req3 The result is a persistent web runtime where per-request startup work can be reduced. This is particularly important for high-throughput APIs and applications with database access. Native Database Connectivity LOOK provides direct support for: MySQL MariaDB PostgreSQL SQLite Redis / RESP2 A notable part of the architecture is that several protocol implementations are handled directly inside the runtime instead of relying entirely on external database driver packages. This gives the project greater control over: connection management protocol behavior pooling error handling performance characteristics dependency management LOOK also provides a database API with operations for queries, execution, scalar values and transactions. For example: $rows = db::query( app::db(), "SELECT id, name FROM users WHERE active = ?", [1] ) The result can then be returned through the HTTP layer. The goal is not to eliminate every external database tool. The goal is to make the common backend path available directly from the runtime. No ORM Required LOOK does not require an ORM for basic database operations. A developer can work directly with SQL and the native database API. For many backend services, this can remove an additional abstraction layer between: Application ↓ ORM ↓ Database Driver ↓ Database and instead provide: Application ↓ LOOK Database Runtime ↓ Database This does not mean ORMs are inherently bad. It means that LOOK does not make an ORM a prerequisite for productive database development. Native Real-Time Communication Modern applications increasingly require real-time communication. Chat applications, live dashboards, monitoring systems, notifications and device platforms commonly require additional realtime infrastructure. LOOK provides: WebSocket Server-Sent Events (SSE) directly through the runtime. This allows applications to build realtime functionality without installing a separate WebSocket framework. For example: Client │ │ WebSocket ▼ LOOK Runtime │ ├── Application Logic ├── Database ├── Cache └── Events This makes realtime communication a first-class backend capability. Concurrency LOOK includes concurrency primitives designed for server applications. These include: ThreadPool Connection Pool parallel() channel() The runtime also supports worker-based execution. This is important because a web language designed for production cannot only optimize the execution of a single function. It must also efficiently manage: connections concurrent requests database operations background work network I/O LOOK therefore treats concurrency as part of the runtime architecture rather than something entirely delegated to external libraries. Sessions, Authentication and Validation Backend applications commonly require the same security mechanisms again and again. LOOK includes built-in support for capabilities such as: sessions cookies JWT validation rate limiting file sandboxing The goal is to provide secure primitives without forcing developers to assemble the entire security layer from unrelated packages. Security as a Runtime Concern One of LOOK's design principles is that security should not depend entirely on developers remembering to install the correct package. The runtime includes multiple security-oriented mechanisms, including: parameterized SQL queries secure cookie attributes password hashing with PBKDF2-SHA256 HTTP request body limits HTTP request validation WebSocket masking enforcement parser depth protection upload validation rate limiting file sandboxing The project also uses security-oriented testing such as: AddressSanitizer UndefinedBehaviorSanitizer ThreadSanitizer fuzzing regression testing Project documentation reports more than 16,000 fuzzing rounds and extensive cross-request leak testing. These are project-reported verification results, not independent certification. Independent security auditing remains an important part of the project's long-term roadmap. Server-Side Templates LOOK also provides a server-side template engine for web applications. The template system supports features such as: layouts partials loops conditions HTML escaping A simple architecture can therefore remain entirely server-side: Browser │ ▼ LOOK HTTP Runtime │ ├── Application ├── Database └── Template │ ▼ HTML There is no requirement to introduce a client-side virtual DOM or another frontend runtime simply to render server-generated pages. Developer Tooling A programming language is more than its syntax. LOOK includes a growing developer toolchain: lk CLI REPL lk --check lk fmt test runner VS Code extension autocomplete hover information run/service shortcuts The goal is to make the language practical from the first line of code through deployment. The Ecosystem The LOOK project also separates the core runtime from an ecosystem of modules and packages. The package ecosystem currently includes integrations such as: iyzico PayTR Stripe Firebase S3 Sentry QR PDF Netgsm image processing This separation allows the core language to remain focused while application-specific integrations can evolve independently. The ecosystem is still young, but it provides an important foundation for future growth. Real Applications LOOK is not limited to isolated syntax examples. The project currently demonstrates applications such as: Blog QR Menu Chat Products AI integration These applications are important because a programming language should ultimately be evaluated by what developers can build with it. The objective is to move from: Language Demo to: Production Application Performance Performance is one of LOOK's goals, but performance claims should always be interpreted within their test environment. Project benchmarks report: approximately 9,800–10,500 requests/sec in direct HTTP workloads, depending on the documented benchmark approximately 41× VM speedup over tree-walking in a tested CLI workload approximately 28 MB of memory usage remaining broadly flat across a long-running 1.75 million request test a database-bound benchmark of 2,837 req/s for LOOK versus 2,184 req/s for PHP 8.3 + JIT + FPM under the documented test configuration These results are project benchmarks, not independent laboratory measurements. The next stage of the project should therefore include reproducible and independently verifiable benchmark suites covering: CPU-bound workloads database workloads network workloads WebSocket workloads concurrency memory usage startup time latency TLS ARM64 containerized deployments That distinction matters. A serious language project should make performance measurable rather than simply claim that it is fast. Why Single-Binary Architecture Matters The single-binary approach is not only about convenience. It changes the deployment model. Traditional application deployment often looks like: Operating System ↓ Runtime ↓ Package Manager ↓ Dependencies ↓ Framework ↓ Web Server ↓ Application LOOK attempts to reduce this to: Operating System ↓ LOOK Runtime ↓ Application This does not eliminate the operating system, database or infrastructure. Instead, it reduces the amount of software that must be assembled before the application itself can run. For small teams and infrastructure-heavy environments, that architectural reduction can be significant. What Can Be Built with LOOK? LOOK is designed for a broad range of backend applications. Examples include: REST APIs Authentication services, mobile APIs, internal APIs and public APIs. SaaS Multi-user web platforms with authentication, database access, billing integrations and realtime functionality. E-Commerce Products, orders, payments, inventory, administration and customer systems. CRM / ERP Internal enterprise systems where predictable deployment and backend simplicity are important. CMS Content management systems and server-rendered websites. Education Platforms School management systems, attendance systems, parent communication platforms and realtime notification systems. Realtime Applications Chat, dashboards, monitoring and live notification systems. IoT Device APIs, telemetry ingestion and realtime device status. AI Backends Streaming AI APIs and application backends that communicate with external AI services. Edge Services Small backend services where low deployment complexity and controlled resource usage are valuable. LOOK Is Not Trying to Replace Everything LOOK is not positioned as: "PHP is dead." or: "Go is obsolete." or: "Node.js should disappear." That is not the purpose of the project. PHP has an enormous ecosystem. Go has excellent tooling and a strong server-side ecosystem. Rust provides exceptional control and memory safety. Node.js has one of the world's largest package ecosystems. LOOK takes a different architectural position: What if web development started with a web-native runtime instead of assembling a web stack from many independent components? That is the problem LOOK is attempting to solve. Current State LOOK has reached v1.0.0 and already contains a functional language and runtime with: HTTP routing REST APIs WebSocket SSE MySQL MariaDB PostgreSQL SQLite Redis/RESP2 sessions JWT validation cache queues concurrency templates SMTP experimental IMAP CLI tooling testing formatting security hardening FastCGI Docker Windows support Linux support At the same time, LOOK is still a young programming language. The project does not have the ecosystem maturity of PHP, JavaScript, Go or Rust. That is expected for a new language. The important point is that the project has moved beyond syntax design into a working runtime, protocol implementations, tooling, benchmarks and real applications. What Still Needs to Be Solved? For LOOK to become suitable for very large and mission-critical projects, several areas require continued research and engineering. Language Specification A complete, formal and stable language specification should become a central reference. Tooling Advanced debugging and profiling tools should be developed. Observability Native integrations for metrics, tracing and OpenTelemetry should be expanded. Platform Support ARM64 and additional environments should receive stronger official support. Package Security The ecosystem can be strengthened with: package signing lockfiles SBOM vulnerability advisories dependency verification Performance Research Further research can explore: JIT compilation profile-guided optimization memory allocation networking scheduling database performance Ecosystem A programming language ultimately needs developers. Documentation, tutorials, libraries, examples, package registries and community contributions will therefore be critical. The Long-Term Research Direction The current LOOK architecture opens several interesting research directions. JIT and Native Optimization The existing bytecode architecture provides a foundation for investigating more advanced execution strategies. Edge Computing A compact runtime and single-binary deployment model are suitable areas for research into edge-oriented services. AI Infrastructure LOOK's HTTP and streaming capabilities can be extended toward AI service orchestration and streaming inference APIs. IoT The combination of networking, concurrency and compact deployment makes IoT backend development a natural research direction. Realtime Infrastructure WebSocket, SSE, channels and persistent workers provide a foundation for more advanced realtime architectures. Runtime-Level Security Security policies could increasingly become configurable at the runtime level rather than being implemented independently inside every application. The Bigger Idea The most interesting part of LOOK is not its syntax. It is the architectural question behind it. Modern software development has benefited enormously from frameworks and package ecosystems. But abstraction also creates complexity. Every additional dependency introduces another: version configuration security update compatibility concern deployment requirement failure point LOOK asks whether some of that complexity can be moved back into a controlled runtime. Instead of developers assembling hundreds of independent pieces, the runtime itself can provide a carefully integrated foundation. That is the experiment. Conclusion LOOK is an attempt to rethink how web backend software is built. It combines a programming language, bytecode virtual machine, HTTP server, realtime communication, database connectivity, concurrency, security primitives, templates, caching, queues and deployment capabilities into a single web-focused runtime. Its most important idea can be summarized in one sentence: LOOK is not trying to add another framework to the web stack — it is trying to reduce the stack itself. The project is still young, and there is substantial work ahead. But the core runtime exists. The language exists. The web infrastructure exists. The database layer exists. The security mechanisms exist. The tooling exists. The benchmarks exist. And real applications are already being built with it. The next challenge is no longer proving that a web-focused language can be built. The challenge is proving how far this architecture can go. Get Involved LOOK is open source and actively evolving. Source Code: github.com/codlook/look Documentation: look.codlook.com Package Ecosystem: github.com/Codlook/look-packages We would especially like feedback from developers working on: high-performance APIs low-resource servers realtime systems SaaS platforms database-heavy applications IoT backends developer tooling programming language runtimes If you are interested in single-binary web architectures, we'd love to hear your thoughts: What would you want your web runtime to provide natively?