Hi HN,
I’ve been exploring a language design where structure, style, and logic live in one authoring unit — to reduce token fragmentation when AI models generate frontend code.
HJX is a compiled UI language that unifies *structure*, *style*, and logic into a single `.hjx` file. It compiles to clean, dependency-free HTML + CSS + JavaScript — no virtual DOM, no runtime overhead, no framework lock-in. :contentReference[oaicite:1]{index=1}
Here’s a real example from the README:
```hjx component Counter state: count = 0 layout: view#root.card: text.title: "Count: {{count}}" button.primary (on click -> inc): "Increase" style: .card { padding: 16px; border: 1px solid #ddd; border-radius: 12px; } .primary { padding: 10px 14px; border-radius: 10px; cursor: pointer; } handlers: inc: set count = count + 1 ```
Happy to answer questions about the hjx and open for pr -Loaii abdalslam
loayabdalslam•1h ago
A bit of backstory: I started building this after noticing how much context switching LLMs do when generating UIs across HTML, CSS, and JS. Instead of three syntactic domains, HJX tries to unify structure, style, and interactivity into a single block-based syntax that still compiles down to plain HTML/CSS/JS.
Right now it’s an early prototype with a basic compiler design. I’d love to hear: - Does this unified syntax reduce token/context fragmentation for AI models? - Any suggestions on grammar design or compiler targets? - Use cases you’d want to see supported?
Happy to iterate based on feedback.
verdverm•52m ago
If I use something bespoke, then I have to do in-context learning, so am I really saving tokens in the long-run? (before we even get to more frequent failures / hallucinations that come with the bespoke)