Most Telegram bot projects start simple.
Then they grow.
A few commands become dozens. Event handlers spread across files. Configuration leaks into business logic. Simple automation scripts slowly turn into infrastructure projects.
After building enough Telegram bots and userbots, I noticed a pattern:
I was spending more time wiring frameworks together than actually building automation.
So I started building Haptic.
A DSL (Domain Specific Language) designed specifically for Telegram automation that transpiles directly into Node.js.
HexZoNetwork
/
Haptic-Streo
The programing language that for telegram userbot or telegraf bot developing
Haptic 🚀
A Telegram automation DSL that transpiles to Node.js.
Haptic is a domain-specific language (DSL) built for Telegram bots and userbots. It compiles directly to JavaScript, supports native Telegram-oriented syntax, and still allows you to write raw Node.js code whenever needed.
Tip: If you are indonesian read README.ID.md The goal is simple:
Write Telegram automation, not framework boilerplate.
Why Haptic?
Most Telegram projects eventually end up with:
- Framework-specific handlers
- Middleware chains
- Configuration files everywhere
- Repetitive command registration
- Boilerplate event routing
Haptic provides a higher-level syntax designed specifically for Telegram automation while keeping full access to the JavaScript ecosystem.
Example
bot "ExampleBot":
token = env("BOT_TOKEN")
end
command start:
reply "Hello World"
end
on message match /ping/i:
reply "pong"
end
Documentation
Start here:
What's New
Recent additions include:
import "./shared.haptic"export func ...- ESM and CommonJS output
- Package metadata support via
config.hpconf
Why Build a DSL?
A typical Telegram bot usually requires:
- Framework setup
- Command registration
- Event handlers
- Configuration management
- Middleware wiring
- Build tooling
None of those things are the actual automation you're trying to build.
I wanted something that felt closer to describing behavior than assembling infrastructure.
Instead of writing framework code:
bot.command("start", async (ctx) => {
await ctx.reply("Hello");
});
I wanted to write:
command start:
reply "Hello"
end
What Haptic Looks Like
Here's a real Haptic example:
bot "ExampleBot":
token = env("BOT_TOKEN")
end
func greet(name):
return "Hello " + name
end
command start:
let sample = [user.username]
for item in sample:
log item
end
if user.id == 1:
reply await greet(user.username)
else:
reply "access denied"
end
console.log("raw JavaScript works here too")
end
on message match /ping/i:
reply "pong"
end
A few things are happening here:
- Bot configuration
- Command definitions
- Event handlers
- Async operations
- Conditional logic
- Raw JavaScript interoperability
all inside a single source file.
Commands Feel Native
Commands are first-class language constructs.
command start:
reply "Hello World"
end
No decorators.
No registration functions.
No framework-specific APIs.
The language itself understands what a command is.
Built For Automation
Telegram automation typically needs a few recurring patterns.
Conditions
if user.id == 1:
reply "admin"
else:
reply "guest"
end
Loops
for item in users:
log item
end
Async Operations
let result = await fetchData()
reply result
Error Handling
try:
let result = dangerousOperation()
reply result
catch err:
reply err.message
end
These are built directly into the language syntax.
JavaScript Is Still Available
One of my design goals was avoiding what I call a language prison.
If Node.js can do it, Haptic should allow it.
For example:
console.log("still JavaScript")
works directly inside a Haptic source file.
That means developers can adopt the DSL gradually without giving up access to the JavaScript ecosystem.
Design Goals
The project is guided by four principles.
Telegram First
The language should feel natural for Telegram automation.
JavaScript Compatible
JavaScript remains the escape hatch whenever you need it.
Readability Over Cleverness
Automation code should describe behavior rather than framework plumbing.
Fast Iteration
Building a bot shouldn't require creating an entire backend architecture first.
Current Features
Today Haptic supports:
- Telegram Bots
- Telegram Userbots
- Functions
- Loops
- Conditions
- Async/Await
- Try/Catch
- Regex Event Matching
- ESM Output
- CommonJS Output
- Project Scaffolding
- Source Transformation
Getting Started
Install Haptic:
npm i -g https://github.com/HexZoNetwork/Haptic-Streo/releases/download/Haptic/haptic-streo-0.1.0.tgz
Create a new project:
haptic new bot mybot
cd mybot
npm install
haptic bot.haptic
Or transform an existing JavaScript project:
haptic transform .
What Surprised Me Most
I never planned to build a programming language.
The original goal was much smaller:
Reduce the amount of repetitive Telegram boilerplate I kept writing.
Over time, enough abstractions accumulated that the DSL became its own thing.
The interesting part is that many of the features weren't planned. They emerged naturally from solving the same Telegram automation problems repeatedly.
Final Thoughts
Haptic is still early, but it's already capable of building real Telegram bots and userbots while keeping source code focused on automation instead of framework plumbing.
I'm curious what other developers think:
What's the most annoying piece of Telegram bot boilerplate you find yourself writing over and over again?
And more importantly:
Would you rather build bots directly with a framework, or use a purpose-built DSL if it removed most of that boilerplate?
Note: i am not continue this project since 3 month ago so the module might be not latest also this DSL had so much minus that i cant fix alone
Top comments (0)