LOOK: A Web Programming Language Built Around the Web
Modern web development has become incredibly capable — but it has also become increasingly layered.
A typical application may involve a programming language, a web framework, a package manager, database drivers, middleware libraries, authentication libraries, a process manager, a reverse proxy, build tools, configuration files, and a large dependency tree.
LOOK takes a different approach.
LOOK is a web scripting language written in C++23, designed specifically around web application development.
Instead of being a general-purpose language with web capabilities added later, LOOK puts the web at the center of the language.
Routing, databases, sessions, JWT, validation, caching, WebSockets, SSE, concurrency, testing and other web-oriented capabilities are integrated into the LOOK runtime.
The goal is simple:
Make building and deploying web applications simpler without giving up performance, security or control.
What is LOOK?
LOOK is not a web framework for another language.
It is a programming language and runtime designed for web applications.
A minimal LOOK application can look like this:
use jwt
app::set("db", db::connect("mysql://root:@127.0.0.1/mydb"))
route("GET", "/products", function() {
$rows = db::query(app::db(), "SELECT * FROM products", [])
response::json(["ok" => true, "data" => $rows])
})
route("GET", "/ping", fn() => response::json(["ok" => true]))
route("POST", "/login", function() {
$body = request::json()
$token = jwt_sign(["id" => $body.id], env("JWT_SECRET"))
response::json(["token" => $token])
})
The syntax is deliberately compact.
LOOK supports:
-
fn() => ...arrow functions - optional semicolons
-
$row.colproperty access - modules with
use - route groups
- middleware
- path parameters
- JSON APIs
- HTML templates
- database access
- authentication
- WebSockets
- SSE
For example:
route("GET", "/ping", fn() => response::json(["ok" => true]))
is enough to expose an HTTP endpoint.
Not Just a One-File Language
One important misconception about LOOK is that it is designed only for tiny one-file applications.
It is not.
A .lk file can run independently, which makes scripts and CLI tools convenient.
But real applications are structured into multiple files.
A typical project can look like:
myapp/
├── index.lk
├── config/
│ └── app.json
├── views/
│ ├── layout.html
│ └── product.html
└── ~/.look/modules/
├── model/
│ └── model.lk
└── util/
└── util.lk
The entry file wires the application together.
Configuration, templates and reusable modules can remain separate.
This makes LOOK suitable for applications that grow beyond a prototype.
A Language Designed Around the Web
Many programming languages started as general-purpose languages and later developed large web ecosystems.
LOOK starts from the opposite direction.
The web is one of its primary design targets.
That means common web requirements are treated as language/runtime capabilities rather than a collection of unrelated framework components.
For example:
route("GET", "/users/{id}", function($id) {
$user = db::query(
app::db(),
"SELECT * FROM users WHERE id = ?",
[$id]
)
response::json([
"ok" => true,
"data" => $user
])
})
The route, database interaction and HTTP response are all part of the same environment.
Databases Without a Traditional Driver Stack
LOOK supports:
- MySQL
- MariaDB
- PostgreSQL
- SQLite
The relational database protocols are implemented inside the LOOK core rather than depending on separate external database drivers.
The project's CI tests database compatibility against multiple real database versions.
The current documented matrix includes MySQL 5.7 through 9.x, MariaDB 10.11 through 12.x, PostgreSQL 14 and 18, and SQLite 3.47.2.
For example:
app::set("db", db::connect(env("DB_DSN")))
route("GET", "/products", function() {
$products = db::query(
app::db(),
"SELECT id, name, price FROM products ORDER BY id DESC",
[]
)
response::json([
"ok" => true,
"data" => $products
])
})
Parameterized queries are part of the normal database API.
This reduces the amount of infrastructure an application needs to assemble before it can start serving requests.
Authentication and Web APIs
LOOK includes functionality for common API applications such as:
- JWT
- sessions
- cookies
- request validation
- middleware
- rate limiting
- JSON responses
A route group can share authentication middleware:
$auth = function() {
if (request::header("X-Api-Key") != env("API_KEY")) {
response::json(["error" => "forbidden"], 403)
stop()
}
}
route::group("/admin", [$auth], function() {
route("GET", "/users", function() {
response::json(["ok" => true])
})
route("DELETE", "/users/{id}", function($id) {
response::json(["deleted" => $id])
})
})
The objective is to make common API patterns part of the language's natural development model.
WebSockets and Server-Sent Events
Modern applications are not limited to request/response APIs.
Real-time functionality is increasingly common:
- dashboards
- chat systems
- notifications
- monitoring
- live status pages
- collaborative interfaces
LOOK includes WebSocket and Server-Sent Events support.
This means applications can use the same runtime for conventional HTTP endpoints and real-time communication instead of introducing an entirely separate service for every communication model.
Concurrency
LOOK also provides concurrency primitives including:
parallel()- channels
- FastCGI multi-worker execution
The runtime is designed around a persistent process model rather than starting a completely fresh interpreter for every request.
That design has an important performance benefit, but it also creates responsibilities for developers.
Global state must be handled carefully, and code must be thread-safe where concurrency is involved.
LOOK documents this trade-off explicitly rather than hiding it.
Performance
Performance is one of the reasons LOOK was created.
The project includes its own benchmarks.
According to the current repository benchmark:
- direct-port HTTP throughput is around 9,800 requests/second in the documented test
- a database-heavy QR-menu JOIN benchmark over 50,000 rows reached 2,837 req/s
- the comparison was against PHP 8.3 + JIT + FPM at 2,184 req/s
- LOOK used approximately 9–29 MB RAM
- PHP used approximately 43–47 MB RAM
The database benchmark used the same host, schema and query, with controlled CPU and memory limits and equal pool sizes. The repository also explicitly notes that individual runs can be noisy, so these numbers should be treated as project benchmark results rather than universal performance guarantees.
That distinction matters.
A benchmark number without methodology is not particularly useful.
The more interesting question is:
Can a web language maintain low overhead while performing realistic application work?
LOOK is attempting to answer that question through repeatable project benchmarks.
Runtime Architecture
LOOK is implemented in C++23.
Its architecture includes:
Source (.lk)
│
▼
Lexer
│
▼
Parser
│
▼
AST
│
▼
Bytecode / Execution Engine
│
▼
LOOK Runtime
│
├── HTTP
├── WebSocket
├── SSE
├── Database
├── Sessions
├── JWT
├── Cache
├── Concurrency
└── Other Web Services
The project contains both execution paths and supporting infrastructure for its runtime and test systems.
The persistent runtime model is an important architectural decision.
It avoids treating every HTTP request as an entirely new process/interpreter lifecycle.
But this also means that LOOK applications need to be written with persistent state and concurrency in mind.
Single-Binary Deployment
One of the strongest ideas behind LOOK is deployment simplicity.
A LOOK application can be deployed as a binary rather than requiring a large runtime installation and dependency tree.
The official repository documents deployment through:
- Linux
- Windows
- Docker
- CGI
- FastCGI
- Plesk
A Docker installation can start a LOOK server with:
docker run -p 8080:7400 codlook/look
And an application can be mounted into /app.
This creates a particularly simple deployment model:
Application
│
▼
LOOK binary
│
├── HTTP
├── Database
├── WebSocket
├── Sessions
└── Runtime
Instead of:
Application
+
Framework
+
Runtime
+
Package manager
+
Database drivers
+
Multiple libraries
+
Process configuration
the goal is to make the runtime itself provide the common foundation.
Security Is Part of the Runtime
Performance without security is not useful.
LOOK includes security-oriented functionality such as:
- parameterized SQL
- request body limits
- secure session token generation
- HttpOnly/SameSite cookie defaults
- PBKDF2-SHA256
- upload magic-byte validation
- SHA-256
- HMAC
- secure random generation
- WebSocket masking enforcement
- rate limiting
- file sandboxing
- parser depth protection
The project also reports using:
- AddressSanitizer
- UndefinedBehaviorSanitizer
- ThreadSanitizer
- fuzzing
- regression testing
The protocol parsers are implemented in the project itself and kept in a centralized area to make the attack surface easier to inspect.
This is particularly important for a language whose runtime handles networking protocols directly.
The Trade-Offs
LOOK is still an evolving language.
It is important to talk about what it does not solve yet.
The current project documentation explicitly identifies several limitations.
For example, the module system currently uses the LOOK module directory rather than arbitrary relative imports such as:
include "./lib/foo.lk"
The persistent-process architecture also means that global state and thread safety require more discipline than in a request-reset model such as traditional PHP-FPM.
The embedded mail server is still an evolving part of the project.
SMTP has substantially more functionality, while the current IMAP implementation is explicitly a Milestone 1 implementation and does not yet provide the persistent UID behavior required by common desktop and mobile mail clients.
These are not hidden limitations.
They are documented engineering constraints.
That is important for an emerging programming language.
Compatibility and the 1.x Line
LOOK also has a compatibility policy for its 1.x series.
The documented mod::fn API is intended to remain stable throughout 1.x.
Breaking changes are intended for a future major version rather than being silently introduced into a 1.x release.
At the same time, the project distinguishes between true breaking changes and bug fixes.
Security-default hardening can also be introduced within the 1.x line when the previous default is considered unsafe, with an explicit opt-out documented where appropriate.
This is a practical approach for a young language that is still defining some semantic edge cases.
Real Applications
LOOK is not limited to benchmark examples.
The project currently demonstrates several applications running through a single LOOK process, including:
Blog
Posts, administration, categories and cover image uploads.
QR Menu
A restaurant menu with a REST API and route listing.
Chat
Nickname, emoji and near-real-time messaging.
Products
Products, categories, brands, variants and additional attributes.
AI
An API integration with in-memory conversation state.
These examples demonstrate an important aspect of the project:
LOOK is intended to be used for complete web applications, not only isolated API benchmarks.
The Ecosystem
The LOOK core is intentionally kept separate from optional integrations.
The project maintains separate repositories for modules and packages.
The current package ecosystem includes integrations such as:
- Firebase
- iyzico
- PayTR
- Stripe
- S3
- Sentry
- Netgsm
- QR
- image processing
- monitoring
- TCMB
This allows the core language to remain focused while application-specific integrations can evolve independently.
Why Build Another Programming Language?
This is probably the most important question.
Why not simply use PHP, Go, Node.js, Python, Rust or another established language?
Because the goal is not simply to create another syntax.
The goal is to explore a different architecture for web development.
LOOK asks:
What happens if the web is treated as a first-class environment of the programming language instead of a collection of frameworks and libraries around it?
That question affects everything:
- syntax
- runtime
- deployment
- database access
- HTTP
- concurrency
- security
- testing
- package architecture
- application structure
The result is intentionally different from simply adding another web framework.
LOOK vs. Traditional Web Stacks
A conventional stack might look like:
Language
+
Web Framework
+
ORM / DB Driver
+
Authentication Library
+
HTTP Library
+
WebSocket Library
+
Cache Library
+
Package Manager
+
Process Manager
LOOK attempts to move much of that foundation into the language/runtime itself:
LOOK
│
┌──────────┼──────────┐
│ │ │
HTTP DB Security
│ │ │
WebSocket Sessions JWT
│ │ │
SSE Cache Validation
│ │ │
└──────────┼──────────┘
│
Runtime
This does not mean external libraries disappear.
It means the foundation becomes smaller and more integrated.
Where LOOK Could Fit
LOOK is particularly interesting for applications such as:
- REST APIs
- SaaS backends
- admin panels
- dashboards
- internal systems
- CRUD applications
- real-time applications
- lightweight web services
- API gateways
- database-driven applications
- small and medium business applications
- self-hosted applications
- applications where deployment simplicity matters
It can also be interesting for developers who want a language that feels closer to application-level web development than traditional systems programming.
What Makes the Project Interesting
The most interesting aspect of LOOK is not any single feature.
It is the combination.
A language implemented in C++23.
A persistent runtime.
Native HTTP functionality.
Built-in database protocols.
WebSocket and SSE support.
Built-in authentication primitives.
Low deployment overhead.
A relatively compact syntax.
A single-binary deployment model.
And an explicit focus on security and testing.
Those decisions reinforce each other.
LOOK Is Still an R&D Project
LOOK should not be presented as a finished replacement for every existing programming language.
That would be neither accurate nor useful.
It is an evolving programming language and runtime.
There are still areas that require development:
- language semantics
- ecosystem growth
- module ergonomics
- tooling
- IDE support
- documentation
- platform maturity
- deeper database functionality
- mail protocol maturity
- broader independent benchmarking
- larger-scale production adoption
That is exactly what makes the project interesting from an engineering perspective.
The important question is not:
"Has LOOK already replaced everything?"
It clearly has not.
The better question is:
"Can a web-focused language reduce the complexity of modern web development while maintaining strong performance and control?"
LOOK is an attempt to explore that question seriously.
Getting Started
The fastest way to try LOOK is Docker:
docker run -p 8080:7400 codlook/look
Then:
curl localhost:8080
For a local source build, LOOK currently requires:
- C++23
- CMake 3.20+
The project provides CLI, CGI and FastCGI binaries.
The official repository also provides documentation for Linux, Windows, Docker and Plesk deployment.
Final Thoughts
The web development ecosystem has spent decades adding layers around programming languages.
Frameworks became larger.
Dependency trees became larger.
Build systems became more complicated.
Deployment became increasingly dependent on infrastructure knowledge.
LOOK explores the opposite direction:
What if the language itself provided more of the web stack?
Not through magic.
Not through an enormous framework.
But through a runtime designed specifically for web applications.
LOOK is still evolving, and its limitations should be taken seriously.
But the architecture is interesting enough to experiment with.
If the project continues to mature, the most valuable result may not be another framework.
It may be a different way of thinking about what a web programming language should provide by default.
Explore LOOK
GitHub:
https://github.com/codlook/look
Official website:
https://look.codlook.com
Documentation:
https://look.codlook.com/docs.html
Package ecosystem:
https://github.com/Codlook/look-packages
If you are interested in programming languages, web runtimes, C++ systems programming or alternative approaches to web development, LOOK is an interesting project to watch.
Top comments (0)