TriArch is light.

Prepare for lightspeed.

Written in C.

TriArch is the culmination of a decade of full stack development. TriArch fully integrates CSS and HTML with user-generated data. It's built atop JSON syntax - just write TriScripts into existing JSON objects, run the object through the TriArch interpreter, and it will expand the JSON.

Why C?

It wasn't always written in C.

C was my first language, though I strayed away from it over the past decade. The seeds of TriArch were sown in PHP when developing my first website. I found that so much of web development could be automated. I saw existing frameworks such as WordPress, but was eager to give it my own shot.

The PHP prototype was terrible. From memory-leaks to deprecation of dependencies, the amount of maintenance required was too much for a solo developer. Besides: writing an interpreter in an interpreted language was foolish.

Obsessively leaning on Valgrind, I developed this framework first by writing a custom JSON parser and then building a 'recursive' interpreter. Why is recursive in quotes? I vehemently avoided recursion in this project - my goal was to allow the compiler to inline as much as possible.

The results speak for themselves.

Open up Developer Tools and go to Network

Click on the first HTTP request and go to timings. In development, using 4GB RAM and an Intel Core i5-4300 Quad Core CPU, this page was ready to serve in under 20ms. That's ZERO caching, 100% dynamic content. Every page is generated based on user input at runtime.

Go to Inspector.

Notice something about the DOM? It's near empty. No abuse of HTML className or id properties to style elements. Just pure HTML. Why should you care? WebCrawlers and browsers are in alignment on how they view your website. You can make a span tag as big and bold as you want, but that doesn't mean bots are going to regard it as much as an h1. Keep that code:text ratio low!

How about the CSS?

Under the hood, the CSS is inlined with the HTML. This gives the developer the ability to adjust structural elements in the same field of view as stylistic properties. The interpreter seperates the two and determines the CSS selector the element should use based on its relation to other elements. You can be as lazy as you want - let the interpreter figure it out.

And the JavaScript?

Minimal and vanilla. The original build for TriArch relied heavily on AJAX to mask is computational cost to the server. This build aims to only use JavaScript where an existing HTML or CSS technique doesn't exist. The rationale is two-fold:

  • I'm more likely to notice a speed / memory issue, and so are you, compelling a fix.
  • Predictable results: no reliance nonce-key pairs and overwriting the Window.history object to simulate page loads.
  • SECURITY: all data is validated at the server level, thereby restricting APIs to only what I allow in and out.

Does that mean no JavaScript ever?

It'll get introduced, albeit sparingling and thoughtfully.