I coded new kind of front-end generator. You can "kaizen" into your HTML frontend/website with at least 40% less typing. It allows separation of concerns and you can code using HTMX and AlpineJS (or equivalent tech) Been planning this for a long time -- finally coded it on Christmas day. https://cullfront.com/ The website is sparse. But do read the documentation -- it explains everything. This is fresh off the oven. So kindly let me know your thoughts.
Let me thank everyone here for their comments/feedback. I had forgotten that I had posted here too -- I was looking at the conversation on Reddit (link below) Maybe some of the points are being addressed there
https://www.reddit.com/r/htmx/comments/1hmtdsz/a_new_fronten...
I like the idea of a separate tree, but would prefer something other than a child-list for building the tree. I find building a graph with an outward-edge list (which is what this does) to be more error prone and less clear than a either the braces or indentation based approach that is more common; IMO the only advantage to an edge-list is to make circular graphs, which isn't needed here.
[edit]
Also, if you are going to have lists that will be edited a lot, don't require commas for separating items; splicing lists with only whitespace for separators is a much faster operation in many editors.
i had a moment of awe in fact, because that way of describing html maps 1:1 with how i think while typing tedious html tags or js/json arrays. it is like a pure mind dump.
...and not using commas is just asking for trouble for zero benefit.
> ...and not using commas is just asking for trouble for zero benefit.
Have you ever worked with a source format that elides the commas? I work with one (Common Lisp) regularly and am telling you that it's not zero benefit. Clojure takes a middle ground by treating commas as whitespace.
This is awesome. Can't help but be reminded of linker step -> compiler step. Hm I wonder what the analogy of static versus shared libraries would feel like here. Or LD_PRELOAD ;)
Splitting code into multiple files and lowering cohesion is quite far from "separation of concerns". It makes changes, navigation and reasoning artificially harder. It's like tearing building blueprint into random pieces.
The nested structure of HTML makes building a mental model of the content very intuitive. This is entirely lost by having to develop in a CSV file, and by building this tree out by manually referencing elements. This, along with the order not being significant in the CSV files, seems like a hindrance rather than a benefit.
Kudos to the author for trying something new, but I'd rather work with the raw HTML than this system.
Sidenote: I'm not really a fan of htmx or Alpine.js, which might be another reason for disliking this. The real separation of concerns is already achieved by the vanilla HTML/JS/CSS separation, yet most modern web frameworks intentionally blur this. So we end up with libraries on top of frameworks on top of libraries, ad infinitum, just to undo the mess each abstraction introduces.
> I think they believe that the only separation is styling/not-styling, because behaviour is very tied to structure anyway.
I "believe" even harder :) CSS could be used as a completely separate thing. But from practical standpoint it's quite beneficial to tie it to html structure.
UI component is a single entity defined by highly cohesive set of structure, behavior and style. The reason to change often touches two of them and sometimes all three.
IMHO the only easily safely separable styling is color and almost safe are font and base scaling.
I would have liked to see a brief example of what this does. I found a wall of text instead. I'm not interested in spending 20 minutes only to understand if this could potentially bring me any value in addition to the tool I already use.
I coded new kind of front-end generator. You can "kaizen" into your HTML frontend/website with at least 40% less typing. It allows separation of concerns and you can code using HTMX and AlpineJS (or equivalent tech) Been planning this for a long time -- finally coded it on Christmas day. https://cullfront.com/ The website is sparse. But do read the documentation -- it explains everything. This is fresh off the oven. So kindly let me know your thoughts.
Let me thank everyone here for their comments/feedback. I had forgotten that I had posted here too -- I was looking at the conversation on Reddit (link below) Maybe some of the points are being addressed there https://www.reddit.com/r/htmx/comments/1hmtdsz/a_new_fronten...
Thank you once again. Grateful.
I like the idea of a separate tree, but would prefer something other than a child-list for building the tree. I find building a graph with an outward-edge list (which is what this does) to be more error prone and less clear than a either the braces or indentation based approach that is more common; IMO the only advantage to an edge-list is to make circular graphs, which isn't needed here.
[edit]
Also, if you are going to have lists that will be edited a lot, don't require commas for separating items; splicing lists with only whitespace for separators is a much faster operation in many editors.
it's all opinion. i actually like the choices.
i had a moment of awe in fact, because that way of describing html maps 1:1 with how i think while typing tedious html tags or js/json arrays. it is like a pure mind dump.
...and not using commas is just asking for trouble for zero benefit.
> ...and not using commas is just asking for trouble for zero benefit.
Have you ever worked with a source format that elides the commas? I work with one (Common Lisp) regularly and am telling you that it's not zero benefit. Clojure takes a middle ground by treating commas as whitespace.
It is a Windows, no source provided executable. No idea what response you expected but it is what I expected ;)
This is awesome. Can't help but be reminded of linker step -> compiler step. Hm I wonder what the analogy of static versus shared libraries would feel like here. Or LD_PRELOAD ;)
Splitting code into multiple files and lowering cohesion is quite far from "separation of concerns". It makes changes, navigation and reasoning artificially harder. It's like tearing building blueprint into random pieces.
I got the same impression from the example.
The nested structure of HTML makes building a mental model of the content very intuitive. This is entirely lost by having to develop in a CSV file, and by building this tree out by manually referencing elements. This, along with the order not being significant in the CSV files, seems like a hindrance rather than a benefit.
Kudos to the author for trying something new, but I'd rather work with the raw HTML than this system.
Sidenote: I'm not really a fan of htmx or Alpine.js, which might be another reason for disliking this. The real separation of concerns is already achieved by the vanilla HTML/JS/CSS separation, yet most modern web frameworks intentionally blur this. So we end up with libraries on top of frameworks on top of libraries, ad infinitum, just to undo the mess each abstraction introduces.
> The real separation of concerns is already achieved by the vanilla HTML/JS/CSS separation, yet most modern web frameworks intentionally blur this
I think they believe that the only separation is styling/not-styling, because behaviour is very tied to structure anyway.
> I think they believe that the only separation is styling/not-styling, because behaviour is very tied to structure anyway.
I "believe" even harder :) CSS could be used as a completely separate thing. But from practical standpoint it's quite beneficial to tie it to html structure.
UI component is a single entity defined by highly cohesive set of structure, behavior and style. The reason to change often touches two of them and sometimes all three.
IMHO the only easily safely separable styling is color and almost safe are font and base scaling.
I would have liked to see a brief example of what this does. I found a wall of text instead. I'm not interested in spending 20 minutes only to understand if this could potentially bring me any value in addition to the tool I already use.
https://docs.cullfront.com/an-example
Yeah, no, that looks awful. At least three times more complicated that just writing HTML