Hibiki is built for the backend/devops/data engineer, who knows say, Python, flask, and HTML, but isn't a JavaScript expert, and isn't a frontend framework expert. Using Hibiki they can now import some good looking controls, add some AJAX functionality and dynamic content to their tools without having to set up a JS stack (and assorted configuration) or pull in a dedicated frontend engineer. For internal tools / prototypes / scripts it can be a huge time saver.
The examples make it appear to be a DSL around JS, without server interactions beyond what you'd accomplished with a `fetch` request. I understand your comparison to a webpack-based JS setup; I'm wondering about comparison to HTML and JS.
With vanilla JS you'd have to gather your parameters, encode them, call fetch, resolve the promise (and handle errors), and decode the result. Then you still need some sort of frontend data model to "set" the fetched data in. Now you need functions to update the DOM. It isn't like it can't be done, but it ends up being 10-15 lines of code, when you can do it in Hibiki in 1-2 (with a UI that looks more declarative).
So for Python/Flask, you can just write standard AJAX handlers that return JSON. You can also write special JSON payloads called hibiki "actions" that can set data directly into the data model, update HTML, fire events, or even call other handlers. People knock this approach because it tightly binds your backend to your frontend. But for simple tools, that logic has to exist somewhere -- if you're a Python programmer, it can be simpler to write it in Python than in JavaScript. Whatever gets the job done.
