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.

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.

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.

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).

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).

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 :))

(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.

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

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.

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!

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)

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.

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

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.

Yet the website is a blank white page, without JavaScript.

[0] https://github.com/vuejs/petite-vue

The 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.

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.

Angular.js: https://angularjs.org/ Angular: https://angular.io

(PS: Thanks Google)

Because of the standard data-model, the components can all fit together really nicely.

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.

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.

That being said, I'm definitely open to bringing web components into Hibiki -- having all the Hibiki infrastructure could help manage some of those weird interactions. On paper at least, I think I could make them play nice together. Once I clear my current todos, I'll dig a bit deeper into Lit / web components again.

hahahaha dude. you just drastically limited your market. lawyers have already vetted the other licenses, but now anyone who uses your code in any official capacity MUST hire a lawyer to dig into just what modifications you're talking about and what the implications are. Thus, a non-starter. On top of that, if you made these changes yourself, it's very likely you missed something (which could also increase YOUR liability!) and need to hire a lawyer yourself to review it. So consider heading back over to https://choosealicense.com/ and pick something more restrictive than MIT if you want. For example, I used EUPL 1.2 for mine.

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.

Definitely dislike how everything requires a ton of tools to build, I miss writing single-page angular pages.

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.

.vue files are bullshit

> 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_).

[0]: https://turbo.hotwired.dev/

I remember using something that worked exactly like that back in the jQuery era. I can’t remember the name though..

> 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 ?

How about being able to put markdown between the “<template hibiki/>” things and have hibiki render a beautiful page for me?

How does it interact with Python and Flask?

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.

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.

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.