From the beginning of the web, and of UI Design in general, there existed the need to link the UI markup with its logic and states, making them coexist in the same realm.
Despite the dream of declaring UI in a high-level way, the original design paradigms existed on the opposite end. The options were writing in a verbose OOP style, or in a low-level draw call style, involving manually retrieving and updating the UI upon changes, or relying only on bare primitives of basic binding.
As time went on and ambitions grew, the need for a true solution for UI logic linking became more apparent, so template files and their respective frameworks began to rise.
Template files are big blobs of reusable UI chunks, written in their native HTML form, featuring specific attributes and content sections derived from embedded expressions that reevaluate implicitly when updates occur.
While template files were revolutionary in every sense, they had a lot of problems, mainly the remaining separation of markup from its logic, and having inputs coming from the global component scope, which created countless instances of hip-hopping between files.
The next step in the web's evolution was to bring markup and its logic together, starting primarily with React and its JSX expressions.
Template expressions, despite their countless variations, had one core existential goal: to be inlineable inside the logic, both locationally and relationally.
Template expressions are, true to their name, expressions, or try to be like that. Like template files, they are chunks of UI written in their natural form, having embedded expressions that reevaluate upon updates. However, template expressions can access the scope of their host logic, which eliminates the need for a middle layer and provides better encapsulation and type safety.
There is a reason why the new frameworks you find in the wild are using template expressions—from Angular to React to Solid to Lit. While the syntax and their form change from one framework to another, the core idea remains the same, whether you use tagged templates or custom syntax.
Template expressions formed the basis of a new era: the modern reactive web we know and live in, an era featuring limitless reactivity and unmatched declarativity. Yet unexpectedly, someone came up with an idea that made the peak of declarativity look verbose.
Lately, Dominic Gannaway (author of Inferno), came up with a new framework that will make ripples in the web world.
The revolutionary feature the Ripple framework invented is template statements. Apart from the unusual syntax noticeable in the example, you can see that the HTML structure is the main structure in the component, and the logic is defined normally inside the HTML structure—statements, not expressions. All of this occurs inside a JavaScript file; this is the essence of template statements.
Template expressions are HTML structures inside the logic that act as an expression; they return UI structure. They can have as many embedded expressions as desired, but at the end of the day, they are limited only to a subset of expressions, not declarations and statements.
Template statements, on the other hand, act like normal statements. They don't return structure; instead, each one defines a section of the structure, and together they form the entire structure. Like template expressions, they are embedded inside the logic and can access their scope. However, they can host their own localized logic and other template statements, utilizing all JavaScript features (variables, statements, functions, classes).
How far we can go depends on the framework, but theoretically, we are using JavaScript, so this is possible.
This paradigm in UI definition has outstanding abilities, primarily the ability to directly inline markup with its logic, complete with encapsulation, at any level. Since template statements are statements, they can host their own logic within a separate lexical scope.
In past approaches, you only had one scope per component for logic and state sharing. With template statements, however, you can split your component into smaller sections, each with its own logic and scope, and repeat this process at every level.
In addition, being multiple chunks not singleton blobs, template statements can use regular control flows (if, for, while, switch, etc.) and don't reinvent the wheel in every framework. This removes the need for directives, utility components, mixins, or whatever feature was previously used to hack conditional and list rendering.
NeoComp adopted the template statements paradigm, but with a philosophy opposite to Ripple's. Ripple adds new syntax to JavaScript and relies on a complex compilation step—things that violate NeoComp's core philosophy of simple, vanilla JavaScript enhanced with optional, simple transformations.
Templating in NeoComp is now composed of multiple fragments of UI called chunks. Each chunk is defined around its logic using regular HTML syntax.
Each chunk is formed of multiple parts, splittable at any point, defined around its logic through $temp tagged template literals. State can be set/bound to attributes and content sections through ${exp} embedded expressions.
Chunks on their own don't bring noticeable new features to the table. However, when combined with JavaScript features, the power of template statements starts to shine, as chunks are defined with vanilla JavaScript.
Other than the previously discussed features of template statements, from localized state/markup coexistence to native control flow usage, template statements have just made the biggest refactor to NeoComp ever.
Primarily, it drastically simplified the templating internals. What was before a series of reasonably sized systems for generation, walking, actions, and construction had turned into just a single function with some helper functions found in a single file.
This reduces the file size by 25% (from 10kb to around 7.5kb gzip). While chunks added many features, they also simplified the logic through deduplication and by removing the need for a middle layer.
In addition, because of the localized logic the chunks brought, the need for global state with naming support is gone, which enhanced the state management with localized state and deep state reactivity.
Template statements single-handedly transformed the templating experience in NeoComp, moving from old-day template files with modern features, to multilevel, chunked, localized, coexisting template statements that rival modern frameworks with superb flexibility and efficiency.
Template statements were the needed fourth pillar of NeoComp. Their flexibility complements the efficiency of fine-grained reactivity, the organization of object-oriented components, and the added performance of native transformations, further supporting NeoComp's core paradigm: native form UI design with direct implicit bindings, driven by imperative construction, the paradigm for static structure dynamic content, the structure of the web.
And don't forget, this is, at the end of the day, just a concept framework, a case study for an opinionated view on simplicity in UI design: simplicity in directness outperforms simplicity in declarativeness
. We don't need to eliminate the last character in the source; we only need implicit direct bindings in our inlined HTML templates.