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).
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
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.
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.
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.
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.
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).
Deleted Comment
Deleted Comment
(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?
Just make the license free to use except for a saas. And you'll accomplish what you want without being misleading.
Dead Comment
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"
I recommend taking a look at the PolyForm Project’s form licenses: https://polyformproject.org/licenses/. PolyForm Shield <https://polyformproject.org/licenses/shield/1.0.0/> is pretty much exactly what you were aiming for (permissive, except for competition with things you reckon you might be able to make a business out of), but drafted by experts in international software and business law.
(There’s also PolyForm Perimeter, https://polyformproject.org/licenses/perimeter/1.0.0/, which limits the competition clause to competition with the software rather than other related business.)
Consider choosing one of these, rather than going to plain MIT.
If you’re willing to go fully permissive, consider choosing BlueOak-1.0.0 <https://blueoakcouncil.org/license/1.0.0> rather than MIT, as it’s easier to read and more complete, the work of the same people as the PolyForm Project; https://blueoakcouncil.org/2019/03/06/model.html has some more explanation on why to choose it.
[1]: https://opensource.org/licenses/alphabetical
Furthermore, reading things like: “Q: Is the model license compatible with GPL? A: The Council doesn’t see any reason why software licensed under the Blue Oak Model License 1.0.0 can’t be used, combined, and distributed with software under GPLv2, LGPLv2.1, GPLv3, LGPLv3, or AGPLv3.” [2], hardly fills me with confidence. Rather I would hold off until the group of people behind the license takes the time to engage with the wider FLOSS community to iron out any quirks – preferably by having it approved by OSI.
[2]: https://blueoakcouncil.org/license-faq
Deleted Comment
The people who made Blue Oak Model License have been involved with the open source community and with OSI. I think that the fact that it’s not currently OSI approved is more an indictment of OSI’s broken process, rather than anything about BlueOak-1.0.0.
CC0-1.0 is an example of a license that was submitted to OSI but withdrawn after a week because the mailing list ruined everything, people getting all het up about implications of the fact that it explicitly declared patents out of scope; <https://en.wikipedia.org/wiki/Creative_Commons_license#Zero_...> has a decent summary with links. Mind you, plenty of OSI-approved licenses make no mention of patents, and as a non-lawyer I find it difficult to imagine that any court would ever actually interpret a “patents are out of scope” any different from a non-mention of patents—the only way I can see it doing so is if ignorance actually is a defence. And of course they’re out of scope in a public domain dedication, a patent grant can only belong to a license, which a public domain dedication is not. (The fallback license could include a patent grant, but it would only apply in places where the public domain dedication failed, and would thus be futile. No, any patent grant needs to be a separate document.)
Well, when Creative Commons Zero lingers not OSI-approved, something’s at least a little broken about the process. When Unlicense can then be finally rubber-stamped in 2020 despite being acknowledgedly badly-drafted (quite apart from its atrocious name where “Unlicensed” means the exact opposite of “unlicensed”)—and Unlicense simply makes no mention of patents, and so should be in the same boat as CC0—something’s rotten about the process.
Yeah, it might be nice if BlueOak-1.0.0 were approved by OSI, but I personally am not going to fret much about it. As it stands, I’m currently tending to release my Rust libraries trial-licensed (two is dual, three is trial!), BlueOak-1.0.0 OR MIT OR Apache-2.0 because of the greater recognition of MIT and Apache-2.0 and their prevalent use in the Rust ecosystem. If I were making Node.js stuff, I’d go BlueOak-1.0.0 OR ISC because of ISC’s popularity in that ecosystem.
—⁂—
As for the GPL-compatibility question: their answer is very deliberately worded and perfectly accurate. They believe BlueOak-1.0.0 to be GPL-compatible (as I, a layman with his head screwed on fairly well and emphatically not a lawyer let alone your lawyer, am perfectly content to say it is also), but do not have the standing to declare it factually so without potentially incurring liability if a court ever decides it disagrees (for courts are the final arbiters of all licensing matters), and FSF have established themselves as the general arbiters of GPL-compatibility, so it would be somewhat impolite to declare something GPL-compatible without their approval of the matter.
—⁂—
I want to clarify that this comment is based only on my casual observations from outside any of these things, and is my opinions of something I don’t know all details of. I could easily be wrong on any point, and easily have erred in any conclusion from any point.
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
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.
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.
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!
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)
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.
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/
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.
[0] https://support.google.com/code/answer/54830?hl=en