ScreamJS: explicit boundaries in a TypeScript framework

Mon, 01 Jan 0001 00:00:00 +0000

What I am building

ScreamJS is my TypeScript framework project for server-rendered, database-backed web applications. It is actively developed and intended for education and testing; it is not production-ready.

The design question is how to provide useful framework behavior while keeping application dependencies and assembly explicit. The current project favors constructor injection and module boundaries, with additional layers introduced when they solve a concrete problem.

One decision: separate template compilation from rendering

The template compiler loads named views, tokenizes and parses source, and resolves layout inheritance. The renderer consumes the compiled representation and a render context to produce HTML through its evaluator and generator.

This separates structural template work from rendering with request-specific data. It also creates places to report errors such as missing templates, unknown block overrides, and inheritance cycles.

Why keep the boundaries explicit?

The compiler receives its loader, tokenizer, and parser through its constructor. The renderer receives its evaluator and generator. A reader can see those collaborators without a dependency container or runtime discovery.

That clarity has a cost: I maintain more small contracts and compose them explicitly. I would not claim that this makes every application faster or that building a framework is the best choice for every product. Here, the framework itself is the subject of the work.

Evidence and limits

The public repository contains the compiler, renderer, and tests at the template-engine boundary. The tests demonstrate expected behavior; this note does not claim the entire current test suite has been run or independently audited.

The useful outcome to inspect is the implementation and its boundaries. I have no production-adoption or benchmark result to claim here.

Explore ScreamJS on GitHub · Read the interface-method article · Resume

Bandgrid: discovering and managing cultural events

Mon, 01 Jan 0001 00:00:00 +0000

The product

Bandgrid brings bands, venues, and events into one application. Visitors can browse public content, while authenticated workflows support management and subscriptions.

My work spans the application’s data model, web experience, deployment, and maintenance. This is an example of the broader application ownership described on my resume.

The current application uses AdonisJS, TypeScript, PostgreSQL, and server-rendered Edge views, with browser assets built through Vite. Public pages and authenticated workflows live in the same application.

That keeps ordinary product changes close to the data and server-rendered interface they affect. It also means boundaries and authorization rules need to be clear inside the application; a single deployment does not remove that responsibility.

Data relationships support the experience

An event relates to the artists and venue involved. Public discovery needs to respect whether content is visible, while management workflows need to distinguish the people allowed to change it.

The engineering work is therefore more than presenting an event card: it involves consistent relationships, input validation, visibility, and authorization across different entry points.

Scope and limits

This note describes an event-discovery and management product. It does not claim that Bandgrid processes ticket payments, has a particular number of customers, or achieves a measured performance improvement.

Visit Bandgrid · Read my resume · Contact me on LinkedIn

Selected work on Jovan Djukic