Show HN: Hibiki HTML – New frontend framework – no scaffolding, no Webpack (playground.hibikihtml.com)
I love JavaScript, but for many projects -- especially internal tools and prototypes -- setting up a full frontend JavaScript stack (npm, webpack, babel, create-react-app, redux) and all of their configuration files, folders, and scaffolding is overkill.
Hibiki HTML incrementally plugs into any backend, using any template language (even static HTML files) with a single script include. It includes a built-in frontend data model, Vue.js-like rendering, built-in AJAX integration, and a full component/library system.
It is also fully scriptable from your backend AJAX handlers. Anything that Hibiki HTML can do on the frontend can be done with a remote handler by returning specially formatted JSON actions. This allows you to write frontend logic (that would normally be JavaScript code) in your backend handlers.
Background -- Hibiki HTML is a standalone, open-source, more powerful version of the frontend language that I had built for my internal tools startup Dashborg over the past year. It is a reaction against the extreme amount of scaffolding and configuration required to set up a new frontend project, especially when you're a backend/devops/data engineer who isn't a JavaScript expert. As more Hibiki libraries are written, the advantages will hopefully become even more clear.
I'd love to get all of your feedback, questions, and comments. Would love a star on Github if you like the idea. Also, feel free to email me, and/or join the Slack workspace I set up (contact info on Github or the tutorial).
150 comments
[ 2.7 ms ] story [ 204 ms ] threadThe other really cool feature is that you can return "actions" (special JSON payloads) from your backend to actually script and update your frontend.
Put these two features together and you can have a full SPA in a single HTML file.
Because of the standard data-model, the components can all fit together really nicely.
Angular.js: https://angularjs.org/ Angular: https://angular.io
(PS: Thanks Google)
Have a look at https://angularjs.org/ or https://knockoutjs.com/
If you want to go deeper and put more functionality on the frontend or create advanced generic components, then ya, you'll have to invest more into learning the framework.
Most of the backend engineers I've worked with have no problem writing HTML, AJAX handlers, and using template languages. But they won't touch webpack/npm/babel with a 10-foot pole. Just trying to bridge the gap to get a little more pizzaz into their tools :)
This isn't true, all live examples in Vue's docs run in browser.
Lots of people share their Vue examples using codepen, jsfiddle, jsbin, etc that are just static .html,js,css file hosts.
Vue's also used a lot for progressive enhancement of SSR content which wont be using npm in non node server Apps.
There's also optimized variants like petite-vue & preact which are tiny subsets that's designed to be used directly in the browser without any build tools.
This demo[1] runs a similar template to the initial few in the Hibiki HTML tutorial via Vue. I've been able to use the full Vue templating features and I've used a minimal amount of JS to set it up. The script I've included is ~4x smaller than the minified prod build of Hibiki, and my data models are in a real JS script tag so my code editor will treat it as real JS, as are my event handling methods which interact with my data model. AlpineJS is actually half the size again of Vue's prod build, I just chose Vue as I work with it regularly.
In trying to save developers the trouble of learning JS where they're not familiar, Hibiki feels like a new, less known, less documented DSL wrapped in non-standard HTML tags and lots of esoteric naming conventions in order to connect logic, data and layout together (it gives me ColdFusion vibes). While I could see the idea with remote actions, replicating this kind of loop in JS is trivial and feels less "magic", with the benefit that a strict data structure isn't thrust on the developer that then leaks into their backend code.
If a developer doesn't want to learn JS, they can get by just fine with server rendered pages which need to update with every action. If they want interactive content without reload, it's probably best for them to learn the small amount JS required to do what they want.
I apologise for being so down on the idea, especially as I'm keen to see more projects embrace the approach of keeping it simple, and ridding themselves of painful build steps and huge node_modules folders. But I'm struggling to see the benefits of Hibiki over the incumbent frameworks available.
[0] https://alpinejs.dev [1] https://jsbin.com/mifiwabuqa/edit?html,output
It's a shame as I liked a lot of Angular.js but it still lags behind in size and performance these days so it's only attractive to teams that know they're making large, heavyweight web-based software from the start.
Without an upgrade path I wondered why they didn't wait.
> You just can't create a SaaS service offering a hosted version of Hibiki HTML or one that uses the Hibiki HTML language to offer 3rd party customizability for an existing product or service (see LICENSE).
Customizability in the context of UI is a very gray area. Does a form builder offer customizability ? Does a drag drop interface ? Does a search filter ?
> The Hibiki HTML license is not OSI approved. I know this is an ideological deal-breaker for some, but if you have a purely practical concern , I'm happy to offer a proprietary license that satisfies your legal department.
Even though the restrictions might be reasonable, by making it non-standard ensures that any larger corp will not be able to use it.
IIRC software licenses are copyright licenses (you can't use the code / make derivatives based on the code) not patents (you can't make a product based on this _idea_).
Something I don’t like about “no build system, just use this one CDN script” is that:
1. I now depend on two servers for my application.
2. It represents a worst case: you must ship and download the entire library even if I could tree shake most of it at build time.
Totally understand the Tree Shaking problem, but the intent is not to use this for high performance consumer facing sites. More for just getting internal tools / prototypes written quickly without overhead / scaffolding.
I wonder if someone has worked with both htmx and Hibiki, and can compare the two experiences?
[0] https://htmx.org
Hibiki is a lot heavier and so it is more appropriate for internal tools, prototypes, dashboards, etc. as opposed to fast/quick consumer facing sites. Also Hibiki "renders" data on the frontend, whereas htmx takes pre-rendered html from your backend and splices it into the dom.
The usage of <template> tags instead of a x-cloak, x-src and similar attributes feels nice and clean to me.
I'm curious if you've dogfooded known pitfalls of the dom-first approach. One kind of big one I recall from vue's earlier days had to do w/ perf hits from multiple repaints in recursive components (think HN comment trees). Another is related to dom edge cases when looping over a set of <tr>s (think tables w/ colspan/rowspan)
For tables and weird HTML syntax, there are two built in escape hatches. You can write any HTML element using the "html" prefix, so a table can look like <html-table><html-tr><html-td>...</html-td></html-tr></html-table>. You can then nest non-table tags inside of there without breaking the natural DOM parsing. You can also reference a component using the "component" attrribute. So <tr component="local-foo"> will render the "foo" component in place of the <tr> tag.
There was also a lot of dog-fooding for how to wrap <input> controls and how to make useful <table> abstractions. So there is functionality around merging attributes to children and injecting values into children (Hibiki's answer to "higher order components"). I was really focused on how to make a powerful enough component system to make using the components in HTML feel really natural.
The license is fine for all projects (commercial or private) that I'd be interested in using it for.
Unfortunately, it's not! It's very vaguely worded, and this means that a lot of things that you think might be okay technically aren't. See other comments in this thread.
Now I've settled on Svelte as it's layout and build/compile step is simple and I've never had to touch the config file
[0] https://github.com/vitejs/vite
The post you're replying to assumes you have chosen Vite, and it's arguing that Vite is as simple as Hibiki. Vite does a lot of config very well, and it really does "just work" for 95% of apps. You need to be doing something quite unusual to move past the automatically configured defaults.
The same is true of Parcel, Webpack 5, esbuild, etc really. Automatic zero-config bundlers are very good these days.
[0] https://github.com/vuejs/petite-vue
As it stands, I can't incorporate Hibiki into any of my existing projects because of the non-free and incompatible license, and that really sucks.
Further, in a comment in this thread [0] you say that:
> You can download the script and host it yourself
But the license page [1] says that:
> You Cannot:
> Offer a hosted version of Hibiki HTML.
...which is something I'd be inherently doing by putting a copy of the script on my server, because of how the web works.
You license makes using your library and incorporating it into projects very confusing and complicated. I totally understand the intent behind it, but it... just makes everything messy.
---
Also: Missing </h-text> close tag in this example on line 8: https://playground.hibikihtml.com/tutorial/?page=t-expr
---
[0]: https://news.ycombinator.com/item?id=30107918
[1]: https://www.dashborg.net/static/hibiki-license.html
(1) I can't incorporate Hibiki into anything (A)GPL licensed, which many of my projects are.
(2) Ideologically I can't get behind something non-free, even though I completely understand why you wrote the license the way that you did. Realistically all it's going to do is hinder adoption (see parent comment of mine).
(3) You can say I'm not going to get into trouble, but your license says otherwise, and I really can't use something unless I'm 100% sure I'll be in the okay, ya'know?
I am happy to pay for a FOSS license, but obviously that will then allow other people to use the code without paying for it, because of the nature of FOSS.
Just make the license free to use except for a saas. And you'll accomplish what you want without being misleading.
The intent was that if you're at a company and write Hibiki code, you're all good, no problem. If you're at a company and you're offering a service which lets your customers write Hibiki code that you then host, then that's no good.
Since it was already confusing, I'll work on clarifying that point specifically in the future. https://github.com/dashborg/hibiki/blob/main/LICENSE , tried to make it clear that any generic hosting was fine, and also 100% free if it is used for internal tools.
Please do consider just good ol' MIT or (A)GPL. It'll actually allow people to make use of this really cool code that you've written.
As for the SaaS concern: nothing will stop someone motivated enough from writing a compatible drop-in library that does the exact same thing with the exact same syntax. And honestly there's nothing that you can do about it.
While one of the standard licenses may not cover the exact terms you would like, I would still recommend to consider using one because it makes adoption so much easier.
Check out the polyform licenses
https://polyformproject.org/licenses/
(Just a question. I may add more comments to this, whether you reply or not. As I think about it :))
https://www.elastic.co/blog/elastic-license-v2
At least you will have a chance of not scaring off anyone with a legal department.
I also think this should become more common and developers should get used to read the licenses of the code they use, at least until few of these "don't copy all my work and just resell it" licenses catch on and some become standard.
But if you’re not talking about adding a new license to “the canon”, and are instead advocating that developers should write their own licenses, that’s not a good idea. It’s not that developers would need to “actually read the license”. The problem is that every time someone makes a new license they’re effectively putting untested legal code “into production”. Legal departments know what MIT, BSD and the GPL are (not just that they’ve heard of them, I mean they know them deeply). There’s decades of precedent and analysis around them. Newer licenses like ISC have to be carefully worded to make use of that precedent and are then scrutinized before being approved.
I’d also note that if the license you want doesn’t exist, it also might be because it’s legally impossible, unenforceable or just unappealing to users. “Don’t copy all my work and just resell it” sounds like CC Non-Commercial, which isn’t often used for open source libraries because the intent of open source libraries is for people to copy them (down to their hard drive) and resell them (integrated into a larger product).
So for all, as the author in this case, limit the ability to just host the project itself and charge for it. People would still be able to modify the software and use that themselves, and share the modified code/fixes, or contribute upstream. I'd argue that this still follows the ideals of open source/free software, just avoiding abuse in 2022.
Then for some other projects, just no forks. With this variant, you can only modify it for yourself and cannot publish modified/derivative projects. This is IMHO no longer in the spirit of free software, but users can still read the code, modify it themselves and fix bugs, which is waaay better than current proprietary code.
Alt: I believe some people might want to add am ethical clause and a big/small/indie developer clauses.
- For the first one, you’re going to need to define “modification”. If someone adds a single new function to the script, is that a modification? Can they now host the modified script? If not, what do you consider to be “modification”? If so, what if the new function is a no-op that was added to take advantage of the license? (Bear in mind that in cases like these, proving the infringing person’s intent is very difficult if not impossible)
- Regarding “no forks”: Mayyyybe this would work for some smart home projects? I wouldn’t touch anything with a license like this, too often my side projects become a thing I post on my website or use in a hobby thing that then gets intertwined with a work thing. You may say “fine, then stay away”, but if you want people to use your stuff, then it matters if people are scared of the license
- Regarding “ethics”: This just makes the code radioactive. JSLint is famously never used, even though it was written by the author of “JavaScript: The Good Parts” himself, because its license includes a “do no evil” clause. Does Doug Crockford think US Defense Contractors are evil? Will his opinion on them change in the future?
- big/small/indie developer clauses: Depending on what’s going on and how it’s defined, this could maybe work (someone who is a lawyer would need to say for sure). I know Unity, Unreal and GitKraken do a pretty good job with licensing terms that allow indies to check them about but then pay when their job makes money. But (with the exception of Unreal) they’re licensing you a product, you can’t see its source.
I honestly think if you’re a developer who doesn’t want their work exploited by corporations, do what the Janus team at meetEcho does: AGPL for everyone so no one can build on it without contributing back changes, and if you’re a corporation who wants to use it without the AGPL, prepare to cough up for a commercial license.
- You would not be able to host (SaaS style) the modified code either way; you would be able to host (store in your server) the modified code either way. Basically, if you use the project hosting the files and modifying them is fine. In this case, you would be able to modify Hibiki to your liking and _use_ it in your website. If you want to resell the project, that's a no-go either way. In this case, you would not be able to modify (or not!) Hibiki, possibly call it Yamazaki, and make an online editor for others to use.
> - Regarding “no forks”: Mayyyybe this would work for some smart home projects? I wouldn’t touch anything with a license like this, too often my side projects become a thing I post on my website or use in a hobby thing that then gets intertwined with a work thing. You may say “fine, then stay away”, but if you want people to use your stuff, then it matters if people are scared of the license
And yet people buy and use proprietary software everyday with licenses waaaaay more restrictive than this. Remember I'm not trying to say the "no forks" variant is open source at all, just saying that it should be better for the end user than proprietary since you can still fix your own bugs and make customizations.
- Sure the "ethics" and "indie" ones I haven't thought so much of since I'm not personally interested on.
> I honestly think if you’re a developer who doesn’t want their work exploited by corporations, do what the Janus team at meetEcho does: AGPL for everyone so no one can build on it without contributing back changes, and if you’re a corporation who wants to use it without the AGPL, prepare to cough up for a commercial license.
I really don't like this solution; I've used it in a couple of projects of mine, but it feels the worse of two worlds; individuals won't touch that AGPL, and for corporations it wouldn't matter if it's all just proprietary.
Why? If I am working on something with no intent on making a proprietary service out of it, I might as well make my own code GPL. And if I do have the interest in making a business out of it, then I'd inquire about the commercial license.
I once worked on a codebase that was "authored" by non-software-engineer founders based on the same principle: an actual SWE wrote the core, but to extend functionality (think adding a route and its handler), they'd copy the example and change a few lines. The result was as horrible and broken as one might expect - I wonder if lawyers will shudder at the brokenness when they look at such franken-licenses. Sure, it works on the happy-path, but the failure modes can be nasty.
I'm having trouble pinpointing an exact introduction date, but judging by the text of pre-MPL dhcpd and BIND licenses (https://gitlab.isc.org/isc-projects/dhcp/-/commit/5d0ff7ea7c... and https://gitlab.isc.org/isc-projects/bind9/-/commit/0c27b3fe7... respectively), I'd guess that the ISC license has been around since at least 1995. This predates the MPL 1.0 (let alone 2.0) by 3 years, every GPL-compatible version of the BSD license (i.e. every version that's not the problematic 4-clause BSD license) by 4 years, the Apache License 1.1 (let alone 2.0) by 5 years (Apache License 1.0 released the same year, but it was basically a modified 4-clause BSD anyway), and the GPLv3 and AGPL by 12 years.
Needless to say, calling the ISC license "newer" than more popular licenses is pretty misleading. Lawyers have had nearly three decades to scrutinize it (and scrutinize it they have - hence the move from "and" to "and/or" back in 2007).
Anyway, looks below like you're considering a regular 3-clause MIT, so good going on that. :)
1: Hell, even for long-standing OSI licenses the real-life legal implications may be different than what the OSI community assumed. But at least there you'd be in a billion dollar yacht with many others, as opposed to stranded on a desert island with your modified MIT.
Early versions of Creative Commons (CC) license had a bug in which the license would terminate on breach of terms. The terms were easy to mess up, like requiring attribution and linking to source. There is now a new form of copyright troll that is basically fishing for CC violations.
I think “don't roll your own licence (unless you have relevant legal expertise)” should be a regular mantra much like “don't roll your own crypto (unless you have significant cryptography expertise)”.
With the joint caveat of “unless it is for a personal project or plaything, for learning/practising/gaining that expertise, that you don't expect others to use” of course.
No matter how careful and well-intentioned your efforts are in either case, the chance of unintended consequences causing faf (for you in this case, needing to explain and/or reword in order to reclarify and smooth edge case interactions with other common licences).
Here's a simple example that displays a scatter plot of data: https://tests.hibikihtml.com/test-d3.html (source code here - https://github.com/dashborg/hibiki/blob/main/static/test-d3.... ). The plot is just written as <d3-scatter-plot data="*$.data"></d3-scatter-plot>, data is fetched with "GET https://testapi.hibikihtml.com/api/d3-test"
But I have a question for the frontend people.
Is server-side rendering + ~Bootstrap + ~jQuery really getting you into that much trouble? Even with peppering in some HTMX [0]?
I do all my projects with Django + Bootstrap + jQuery + (maybe HTMX if needed) and I've never heard any kind of feedback from anyone that suggests I should be doing anything else.
[0] https://htmx.org/
[0] https://support.google.com/code/answer/54830?hl=en
Hibiki is a reaction to the crazy amount of scaffolding and specific knowledge that is now required to make frontend apps! I had good engineers on my team that all know HTML and can write tables, forms, buttons, etc. but they don't know JS. It was such a PITA to hook them up with a frontend engineer to write a React app to make their frontend look pretty (so the non-technical folks could use their tools). Days were lost in the process. Hibiki is my solution to this problem. A simple framework that doesn't require in-depth JS knowledge but (with the right libraries) can get you good looking credible apps.
Scaffolding is crazy too. I can write a one file python script to output a heredoc with HTML to render some output data. To make that a 'modern' app with create-react-app I'd have to add a whole repository of files and tooling. Hibiki can get you most of what you want right inline.
Depending on how this is interpreted, it could be construed to mean something like a custom field feature that gives a user extra boxes to put stuff in violates this license.
But, for that example, it depends. So if Shopify adds Hibiki to their site, and then writes a custom module that integrates Hibiki into their API. And then they add a new tab to their webpage builder that says "write your form in Hibiki HTML", then no, that would not be okay.
If they just have a generic form that accepts HTML, and makes no mention of Hibiki , and you manually add your HTML which happens to include the Hibiki script and runs Hibiki code, then there is no issue.
One of the problematic pieces is the custom expression language: It's half a programming language incompatible with JavaScript that you will constantly battle with.
Consequently it has a fn:jseval escape hatch.
I couldn't find a way to sort data locally. Escape hatch it is.
Projects like this, when they mature, inevitably create a new programming language that might or might not be better than the host language.
Remote actions: Sounds like a good idea, but now you have the worst of worlds: Code managed separately on front-end and back-end that is tightly coupled via `"setpath" et. al.
The concerns of the back-end are now not just which data to get or check, but also how it is presented on the front-end.
One good thing though: The learning curve is tiny!
Remote actions are an option -- you don't need to use them, but they provide a great escape hatch when you do want your app logic to be implemented in your backend language, not on the frontend. This is great for people who might be python experts but don't want to touch frontend.
htmx and alpine are really cool. But, I think the data-model integration, AJAX handlers, and component/library system are what are going to set Hibiki apart. Being able to package up and reuse components (or use other people's components) should, in the long term, make Hibiki easier to use out of the box.
From the website: >create modern, dynamic, frontend applications without JavaScript
also:
You can create a Hibiki HTML app on any page in two steps. First add the Hibiki HTML JavaScript tag to your page
Not anymore. Not today. No more! – just add this dependency to the top of your file
On a serious note, I would be curious of a comparison of this and other js 'mini' frameworks.
Congrats on delivering OP!
Maybe I'm reading too much into this and making a mountain out of a molehill, but like OP, that was the first thing that caught my eye.
Do you think about microcode when you program? Because I enjoy programming 'without microcode'.
On the other hand, analogy with microcode is BAD. Because «Without JavaScript» (as opposed to «without thinking about JavaScript programming») means it should work in browsers without (or with turned off) JavaScript support. But it is not!
So, when platform is advertised as «No Code» I don't care how it is implemented (unless I'm afraid of vendor-lock), as I know that my site will be deployed on this exact platform. When framework is advertised as «Without JavaScript» I assume it will work in browsers without JavaScript, as I can not control which browsers will be installed on user side.
Yet the website is a blank white page, without JavaScript.
Respectfully, I think we’ve reached max abstractions and tooling with react and various tools. Feels cumbersome like j2ee circa 2000.
I can see the “it’s JS without JS” concept. HTML is declarative. Why not get back to that by writing it in a text editor. Simple. This and the various new frameworks and lighter techniques I think will catch on over the next decade or so.
Definitely dislike how everything requires a ton of tools to build, I miss writing single-page angular pages.