Overview

This documentation is for version 0.55

Cull Front is a simple generator for creating powerful HTML frontends with the capability to handle HTMX and AlpineJS* Or you can call it a "site builder".

This is NOT an editor but a data processor. It gives a very simple way to describe HTML elements declaratively and tersely, and separates areas of concerns that you have. You will have to prepare the files it uses using conventional text editor. I prefer "VS Codium".

IMPORTANT This tool is meant for those who clearly know how HTML works; and also how HTMX and AlpineJS* works — at least conceptually. If you are total beginner to such technology, then this tool may not be for you.

What made me write this?

I am an architect (of the building variety) and I look at software development quite the same way as that of designing buildings.

When designing the built-environment, I shift repeatedly from top-down and bottom-up view of a design. By top-down, I mean I need to get the overall, holistic idea of what is being designed. But I don't stay permanently in the top-down mode — looking down on the design like a bird flying high up there.

No — that would be just one way of looking at the design development. And if that is the only way I look the design process, I would surely get a poorly detailed design.

So I also need to shift to a bottom-up mode — What I mean by this is that I want to look at the evolving design by concentrating on specific parts of it. Such as, trying to figure out how someone may open a door and what would be that experience for different kinds of users. Again, I don't get stuck purely in the bottom-up mode — it will get me too entangled in the details. By shifting continually between top-down and bottom-up I force my mind to think of the evolving design from all angles. The holistic is thought of and respected. Not just that. Even the details that the design need to contain need to be well respected and handled. This is an agile, iterative process.

BTW, some may not know this: The "spiral development" is well discussed in the architecture (of the built-environment) community — I daresay, even before it got adopted in the software field. Read John Zeisel's book "Inquiry By Design".

What is wrong with frontend development tools?

a) I tried many: I got entangled with the looks of the front end along with the functioning of the design. Especially in case of WYSIWYG tools such as Bootstrap Studio or Pinegrow, etc. I would rather handle the looks quite separately as a task by itself — not along with the functionality. I need to separate the areas of concerns — such separation would also help me later delegate work to others and monitor their ongoing work.

b) As explained earlier; when I design, I want to move between "top-down" and "bottom-up" iteratively. Kind of a "push" and "pull" or "kneading the dough" kind of process. When in "top-down" mode, I need to quickly get an overall picture of the design being evolved. When in "bottom-up" mode, I need to be sharply focused on some fine detail (e.g. the way a door would open) and during that period I don't want my mind to get other inputs. I should be then like a sniper, aiming solely at my target. This type of iteration is one major reason I often dislike conventional method of developing HTML. I am presented with the whole thingamajig of the HTML elements all at once. It distracts me, and poses a heavy cognitive load.

c) As the design evolves, I need to quickly get to the part I need to work on really fast. Just the way an index at the end of a book helps me directly jump into the meat of the book and locate what I want; I wanted a designing system that allows me that kind of usage, rapidly. Conventional systems unfortunately keeps becoming heavier and heavier with more and more cognitive load as I proceed.

d) I want the system to be terse; without me writing verbose stuff such as tag starting/endings of HTML elements, and doing indentation to make things readable. In many cases, the entire HTML with all its various angle brackets, and tree structure etc. are thrown right at me. And the "looks" of the ongoing front-end also ends up as a distraction.

Even GUI development tools such as Figma, etc. did not attract me: I find that to be even one more additional step when designing a front end rapidly. I often tell my juniors (in my architects office) to not to keep looking at the evolving building — because the moment we visualize something, we tend to fall in love with it and get extremely biased visually. Visual examination of the evolving design is of course important — but it must be done with deliberate care. The mind must be told not to fall in love easily.

e) Though I do like the tree-structure of HTML, I find that the visual nesting of elements is often confusing to me. I often cannot locate the exact area I want to work on. I do nesting of HTML elements because it is logically suitable to achieve some functionality ...and at that point in time, I should not be drawn into indentation, match the start and end-tags and such details.

f) Technology such as HTMX and AlpineJS* are great -- the only draw back is that they both enforce a different kind of discipline: The various functionality happens by squirrelling away logic into attributes of different HTML elements at different locations. So the overall functionality of the holistic is cut up and distributed as attributes in various parts of the HTML. I would like to look at all the logic of the evolving HTMX/AlpineJS* together.

Of course, some of you readers may argue that their existing tool does not have the above deficiencies. I respectfully suspect that they may have kind of arm-twisted their minds to make that tool work in a suitable manner. Many of us do use tools in unexpected ways — ways that we are comfortable with and not really due to the capability of the tool in question.

The name: "Cull Front"

The name I chose for this tool "Cull Front" reflects this: This tool culls information from different files, and then puts them all together to generate the eventual HTML. It keeps different areas of concerns into different files. There is a "tree" file which declares the tree structure of the HTML in the front end — without presenting a tree shape to you. The tree is really described linearly. It gives you a lot of freedom. Then there is another file, where you declare each of the elements you happened to use in that tree (along with its attributes) Again, there are no angular brackets, etc. to distract you. Then there two more files (optional) that describes the HTMX and the AlpineJS* that you would be using in your frontend.

By separating these files, each file becomes rather pithy and easy to understand. I can easily go thru multiple iterations, as I flesh out the front end for my SaaS — (And of course, I can use this even for plain static HTML too)

*It does not just support AlpineJS but any other JS framework that take a similar approach to AlpineJS of using special attributes inside elements.