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