Show HN: Hibiki HTML – New frontend framework – no scaffolding, no Webpack(playground.hibikihtml.com)
playground.hibikihtml.com
Show HN: Hibiki HTML – New frontend framework – no scaffolding, no Webpack
https://playground.hibikihtml.com/tutorial/
150 comments
I really, really want to use this -- but I urge you to put under a regular MIT or (A)GPL license. Something that's proper F/OSS, please!
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
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
Well, I'm obviously not a lawyer, but that definitely was not my intent when I said offer "hosted version of Hibiki HTML" :/ . I meant hosted, like offering a service like Netlify, Next.js, or Heroku or as an integrated development experience (not like a CDN). Also it is 100% fine for anyone to use Hibiki on Netlify or Heroku or any generic hosting service.
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.
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.
Just a general tip, for all time-- you should treat custom modifications of OSI licenses exactly the same as HN would treat custom modifications to cryptographic primitives. In both cases, don't do them, for the same reasons-- you don't have the domain expertise to understand the implications of what you're doing. And for any case that truly matters, you're almost guaranteed to find out the hard way that the real-life implications are different than what you were aiming for.[1]
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.
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.
There was a recent link posted exactly about this... https://news.ycombinator.com/item?id=30068020
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.
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.
Even if it wasn't your intent, it does read that way. Writing precise, clear and enforceable software licenses is very, very hard work. I've worked with lawyers who do it in the past, and it takes forever.
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.
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.
To expand on this: Even if your custom license is concise and theoretically great, there are legal departments in companies that will disallow using your software because they aren't fully certain about the implications of the terms.
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.
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.
ElasticSearch basically had the same problem so you could consider adopting their license (or adapting it in extremely well defined way):
https://www.elastic.co/blog/elastic-license-v2
At least you will have a chance of not scaring off anyone with a legal department.
https://www.elastic.co/blog/elastic-license-v2
At least you will have a chance of not scaring off anyone with a legal department.
Cool, thanks, I'll check this out
As a fellow dev who is in a similar situation but scared of jumping there, thanks for writing a non-standard license. I think the licenses like MIT, while great for many, many projects, some times they are not the best for other projects that are either "larger/complex" (in a very abstract sense, think a DB) or more product-like.
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 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.
If you think there’s a new kind of license that should exist, that’s one thing. Maybe other people agree, and you can start (or better, join) a movement around getting that license recognition and usage.
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).
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).
Yes I'd love for a new license to exist and join that, but with 2-3 alterations; a bit like how with copyright you have the CC and multiple alternatives.
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.
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.
Ooooh boy. Alright let’s go through these (IANAL, but I’ve studied some IP law, others can chime in if I fuck something up):
- 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.
- 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.
I avoided saying just "host" because it's confusing.
- 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.
- 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.
> individuals won't touch that AGPL
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.
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.
> Yes I'd love for a new license to exist and join that, but with 2-3 alterations;
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 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.
> Newer licenses like ISC
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'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).
Be prepared to test your license in court.
> Well, I'm obviously not a lawyer, but that definitely was not my intent
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).
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).
If you're going to create a custom license, please hire a lawyer to do so.
or better yet just use some already written by lawyers.
Check out the polyform licenses
https://polyformproject.org/licenses/
Check out the polyform licenses
https://polyformproject.org/licenses/
[deleted]
[deleted]
wow good catch, thanks, just fixed it! Is your concern more ideologically or are you worried about actually getting in trouble for using it? happy to assuage your fears if it is the latter.
It's both, honestly.
(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?
(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?
Fair enough. I realize the AGPL integration is a deal breaker. For point 3, true, which is why I could offer a proprietary license that does say you'd be 100% okay (although it still wouldn't work for point 1).
The problem is -- everything that I write is FOSS! So I can neither use your current license, nor a proprietary license I purchase from you!
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.
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.
Don’t try to please everyone. If someone is a FOSS purist, they aren’t going to accept a license with any of the restrictions that prevent companies from offering a hosted service.
I think you should just avoid associating your project with open source or free software. It comes off bad when you see it's not really.
Just make the license free to use except for a saas. And you'll accomplish what you want without being misleading.
Just make the license free to use except for a saas. And you'll accomplish what you want without being misleading.
Okay, I'll definitely consider that -- didn't mean to be misleading. I really intended that the license should not be encumbering for 99% of use cases. I'm actually happy if SaaS companies use the product for dashboards, configuration screens, or admin tools, etc. I just don't want them offering a service that allows 3rd parties to write and host Hibiki code.
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.
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.
What is the problem with the AGPL?
One of the best parts of Hibiki is how you can encapsulate functionality easily into libraries (even 3rd party JS like D3). Even if the library requires JavaScript to create, using it looks just like HTML with custom tags. Once more functionality and components are wrapped into Hibiki libraries, writing simple dashboards, forms, and tools will look more and more like simple, clean HTML.
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"
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"
Isn't that the promise too of React, Angular?
Yes, except you have to be a JavaScript dev to make apps with them. They are great tools, but not great for all apps and all developers. Hibiki is built as an easy to integrate alternative when you just want to get a tool built quickly, or if you aren't a JS expert.
On licensing:
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.
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.
Thanks for this, I'll check these out, Shield is interesting. The internal-use license also looks good - https://polyformproject.org/licenses/internal-use/1.0.0/ . Could add that as an alternate license.
I admit that Blue Oak’s goals are noble, but why oh why would you recommend a license that has not been vetted by say OSI? As far as I know, Blue Oak is not [1].
[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
[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]
I’m not certain exactly why the Blue Oak Model License is not OSI- or FSF-approved, but here’s one mailing list post on OSI’s license-discuss list from one of its creators at about the time of its release: <https://lists.opensource.org/pipermail/license-discuss_lists...>. As part of this complaint about the terrible pain of the process (and it looks from other things like Luis had been involved with OSI as an invited expert for years, so he was familiar with this process from the inside): “I have no current plans to submit the license primarily because I am too busy to have a massively inefficient discussion on license-review. But I'd be willing to make that time commitment if I thought it was helping prototype something new and better.”
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.
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.
Create website without Javascript. Step 1: Include this Javascript.
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
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
That's like complaining that so-called 'No Code' web platforms are actually using code behind the scenes!
«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.
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.
That's a good complaint though. Abstraction can be a very good thing, making things that are difficult more accessible. But a level of abstraction that tries to hide the fact that lower levels actually exist creates confusion, widens the gap between people who know one level from the lower one, and leaches marketing language from the business world into common speak. When "Full Self Driving" doesn't mean what it literally means, and "Without JavaScript" means "With JavaScript", words become meaningless.
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.
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.
> But a level of abstraction that tries to hide the fact that lower levels actually exist creates confusion
Do you think about microcode when you program? Because I enjoy programming 'without microcode'.
Do you think about microcode when you program? Because I enjoy programming 'without microcode'.
Yes, I think about microcode. Not always, but wen I need performant code. Problem is, modern CPU implementations (micro-ISA, like Intel Golden Cove, AMD Zen3 or Apple Firestorm) is hugely different from «modern» (really, 20+ years old, not modern, and it is the root of the problem) architectures they implement (macro-ISA, like x86_64 or ARMv8.2, though with ARM situation is slightly better). Maybe not microcode, but branch prediction, number of ALUs, size of caches and size of one line of cache, etc. — you need to think about these «abstracted-away» details if you need to squeeze all performance from hardware you pay you big buck for.
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!
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!
And yet, you know that it's there, and nobody called it "without microcode".
Look, web development is complicated, full of dependencies, 1000s of packages.
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!
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!
Sounds similar to htmx[0], which I like!
I wonder if someone has worked with both htmx and Hibiki, and can compare the two experiences?
[0] https://htmx.org
I wonder if someone has worked with both htmx and Hibiki, and can compare the two experiences?
[0] https://htmx.org
htmx is really cool, but definitely different.
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.
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.
It looks most similar in scope to petite-vue or alpine.js
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)
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)
Yup, had to solve a lot of issues around corner cases like these. So Hibiki HTML is built on top of React, so react / virtual DOM handles all of the DOM repaints and synthetic events, etc.
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.
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.
It's a mix of old and new. Mostly old though.
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!
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!
Data sorting and data paging are top of mind for me. I wanted to get the APIs / tags for that right before committing them to the core. Hope to add them soon. Without those tags, you'll need to write an escape hatch :/, or sort and page the data on the backend and just have the frontend be a viewer.
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.
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.
Given the atypical license, I would recommend the author to get some sort of system in place in case he gets pull requests from the public, where they explicitly give them the rights to relicense. There are github plugins for this kind of thing.
This is cool and definitely something I'm going to look into!
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/
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/
There's no one solution. The kind of solution you're talking about is great for many purposes, maybe the majority, and it's kind of a shame so many sites and apps went to heavy JS, SPA type frameworks. But on the other hand, a true app like Google Spreadsheets would be completely insane to implement in jQuery.
It all goes back to the release of Gmail in 2004. It changed the web forever. Since then if your frontend isn't "dynamic" or AJAX-y, it feels "old" or only for engineers.
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.
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.
As far as I know, Google Spreadsheets isn't implemented in web tech anyway. It's implemented in GWT [0] (Java transpiled to JavaScript)
[0] https://support.google.com/code/answer/54830?hl=en
[0] https://support.google.com/code/answer/54830?hl=en
A couple of problems that are hard to solve with server side rendering are: modals, data tables (sorting, pagination, etc.), form validation, dropdowns, etc. htmx can you get you a lot of those use cases. But, once there are Hibiki libraries that offer that type of functionality, the Hibiki code should be more encapsulated and easier to just plug-n-play.
IME, scaffolding/config is overkill only if it complicates the developer experience. I stayed away from Angular, React, Vue, etc. because there were too many ways to scaffold and you had to essentially learn how to configure them.
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
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
Vite [0] configures React, Vue and more perfectly out of the box
[0] https://github.com/vitejs/vite
[0] https://github.com/vitejs/vite
I think your missing the point. Having n+1 tools to do the same thing (compile/run a React/Vue app) makes things more complicated, not less.
That only makes the process of choosing tooling more complicated, not using it once you've made that decision.
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.
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.
[deleted]
> Hibiki [..] lets you create [..] frontend applications without JavaScript
Yet the website is a blank white page, without JavaScript.
Yet the website is a blank white page, without JavaScript.
Your project seems to do more but, for a small framework that only needs a small script to work, petite-vue[0] is an alternative.
[0] https://github.com/vuejs/petite-vue
[0] https://github.com/vuejs/petite-vue
What's old is new again-- this very much resembles Angular.js (ie Angular 1)'s strategy (not to say this isn't a valid approach given the constraints). Any notable differences you'd like to emphasize?
React, Angular, Vue, all require you to set up a JavaScript environment -- npm, webpack, babel, etc. to use beyond any trivial examples (you'll need webpack to pull libraries). Hibiki is designed so that it works without all that set up.
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.
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.
He's talking about AngularJS (v1). It is very different to modern frameworks like Angular (v2+), React, et.al. Frameworks from that era didn't involve setting up any build process.
Have a look at https://angularjs.org/ or https://knockoutjs.com/
Have a look at https://angularjs.org/ or https://knockoutjs.com/
You still have to know a lot of JavaScript to get Angular working. The hope for Hibiki is for backend/devops engineers and data scientists who aren't JS experts (I've worked with many of these types in the past). Hibiki provides the glue to call to your backend processes. You can write "frontend" functionality in your backend code (Python, Go, Rust, Java, etc.) instead of having to write that in a language you're not familiar with.
This implies the intent is to be usable by people who aren't proficient in JS. Yet, it requires proficiency in Hibiki's DSL.
Ya, kinda like how all template languages (go-template, handlebars, jade, TT, JSX, etc.) have their own DSL. With Hibiki you can get by with only understanding the basics and then calling backend AJAX handlers to do the rest of the work.
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 :)
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 :)
> React, Angular, Vue, all require you to set up a JavaScript environment -- npm, webpack, babel, etc.
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 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 does not require you to set up a Javascript environment. Note that I'm talking about the original version of Angular, not "Angular" (2+)
Angular.js: https://angularjs.org/ Angular: https://angular.io
(PS: Thanks Google)
Angular.js: https://angularjs.org/ Angular: https://angular.io
(PS: Thanks Google)
This is not quite true. You can easily use react/vue/solid along with unpkg to build fairly complex applications.
I have gotten ridiculously far with ParcelJS without any configuration. It’s an amazing product. I consider it to be my go-to when I don’t want to deal with Webpack.
That's true. It isn't just webpack though, it is for engineers who know HTML or have a backend set up (Django, PHP, Flask, etc.) and just want to add some quick frontend functionality without diving into the JavaScript universe.
This is exactly me. I want to add some simple things but I won't touch Webpack if I can help it. Usually I get by with vanilla JS, and I've been liking Unpoly lately, so I'll give Hibiki a try.
I'm hoping to wrap some of the big UI libraries, like bootstrap, bulma, semantic ui, etc. into Hibiki libraries. Hopefully also get some nice tables, charts, data viewers, and dashboard widgets as well. Once this happens, the hope is that writing simple apps and dashboards in Hibiki will be really easy.
Because of the standard data-model, the components can all fit together really nicely.
Because of the standard data-model, the components can all fit together really nicely.
I appreciate React and Angular are difficult to get going without some sort of build step (React can do it, but not JSX, so it's not optimal), but Vue has always made it very easy to start right in the browser. AlpineJS[0] is newer on the scene, but it also focusses on doing exactly what Hibiki is trying to do with a much smaller API surface area.
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
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
My first thought was exactly this -- a re-invention of the original AngularJS, which aimed to combine elements of scripting with HTML. I was attracted to the original AngularJS, but not so much the later "Angular".
Would love to see an insiders view on what killed angularjs. Technically there were limitations with that approach but by that point that had such marketshare. Did they consider that everyone would flee or did they feel like the developers would just be pulled along?
As far as I've seen, what killed it was the issue that Angular "v2" was so different from Angular.js (v1) that the upgrade path simply wasn't there. Eventually an upgrade path emerged where a page ran both a bulky Angular.js app AND an Angular v2 app, but it wasn't good enough. By then, React (and to a lesser extent Vue) were looking far more interesting so many teams made the decision that if they had to rewrite their app, they may as well write it in something that has a large community around it and was seen as the "latest and greatest".
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.
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.
I still like it myself the 1.x branch. The latest AngularJS version I used was 4 and the boilerplate was heavy.
Without an upgrade path I wondered why they didn't wait.
Without an upgrade path I wondered why they didn't wait.
Will certainly dig into this. Nice work.
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.
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.
Have you considered basing your work on standard web components? They also don't require any scaffolding or building to be used. Sprinkle some binding sugar on top using Lit and you don't have to invent yet another template language but can just use standard JS template strings.
Ya, I've played around with web components quite a bit last year while building Dashborg. They seem great, but I found them quite frustrating, especially around styling, events, and getting them to work with other libraries. The fact that "rem" affects them, and they can't load their own fonts was a huge issue (at least for me).
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.
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.
> a modified form of the MIT License
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.
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 "modified MIT" license is a dealbreaker.
not for most people I'd guesss. The use-case he's excluding is so narrow, and if you're doing something like that, there are probably better ways of handling this.
The license is fine for all projects (commercial or private) that I'd be interested in using it for.
The license is fine for all projects (commercial or private) that I'd be interested in using it for.
I've spoken with enough lawyers at various companies to know that they will never touch this. Which might be the reason why it was licensed this way, but it also means I'm not going to touch it for my own project because the "modified terms" are so purposefully vague I can't guarantee that if I build something that becomes notable that they won't try to extract something from me with the obscure language in that second clause.
> 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.
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.
reminds me of classic AngularJS. Love it.
Definitely dislike how everything requires a ton of tools to build, I miss writing single-page angular pages.
Definitely dislike how everything requires a ton of tools to build, I miss writing single-page angular pages.
> You may not use this Software to make any product (commercial,
free, or open-source), software-as-a-service (SaaS),
platform-as-a-service (PaaS), or infrastructure-as-a-service (IaaS),
cloud marketplace offering, or similar product or service which allows
a 3rd-party user or customer to build UI, customize UI, build
functionality, or customize functionality within your offered product
or service using the Hibiki HTML language or tags.
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.
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.
Lots of comments about this already, but the intent was that if you are writing Hibiki code then you are 100% ok. If you are using it for an internal tool, then you are 100% ok. The only part that is restricted is if you write a service that allows your customers to write Hibiki code (and you aren't a generic hosting service or cdn) that's not ok.
What if I'm something like shopify and I want to allow my customers to be able to use this in the website builder, is that okay?
If you're Shopify, please contact me :)
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.
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.
I'm curious--why all the weird license stuff? I mean, I understand what it allows and doesn't allow, but why did you decide to do it that way? I don't honestly know if a non-open-source framework has a legitimate chance of success in 2022 with so many strong open source competitors. From the response here on HN I think you can see that this is a pretty major issue.
I’m sure this is already mentioned elsewhere, but are you sure the nonstandard license is pulling its weight? IMO it’s a distraction. In many ways a license is very much part of a frameworks API.
No it isn't pulling its weight, it is a distraction, in that half the comments are about the license :)
[deleted]
No, don't follow the VUE path, don't add your own invented format. Let us just write standard js/html.
> It is licensed under a modified form of the MIT license (similar in spirit to the Confluent open source license) which allows you to use Hibiki HTML without restrictions for almost all personal or commercial projects.
> 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.
> 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.
Let's not kid ourselves, "larger corps" are at least as good a position as anyone else to decide whether they can work with the license, and plenty of them do it semi-routinely as part of B2B procurement. Optimizing your licensing to make things easier for them is like leaving your keys on the porch to save burglars the trouble of breaking in—there are decent enough reasons to do it, but this is one of the worst, and I have no idea how it became so ... popular.
Totally understand. I went back and forth many times around the license. I figured I could always open it up more in the future. Happy to clarify use cases or write a proprietary license if need be if a particular corp is worried. Also, it is unencumbered if you use it for internal facing applications (the use case I was most focused on).
Why make it so complicated? I would just use a vanilla AGPLv3.
This project spun out of my startup https://dashborg.net and I'm hoping to create a hosted SaaS service out of it with security/authentication and maybe some other premium features. I don't have that service yet, and I didn't want to get "cloud-poached" before I even had a chance to launch. That being said, I get the concerns. I'll likely re-license the core as vanilla MIT in the future.
Couldn't a cloud service just get a team to do some clean room reverse engineering to make a similar or even compatible tool without violating copyright?
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_).
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_).
Sure they could, but projects at big companies move so slowly, it would take them months just to staff the team, get a manager, a designer, and project-manager, and engineers assigned :) . Not really trying to restrict it, I want people to use it (even for free)! I just also want to be able to launch my startup
Ironic, because getting "cloud-poached" would be one of my end goals.
Why? It seems like they can easily get a proprietary license. Or do you mean that no larger corp will use it for free?
Looks great! Reminds me a bit of Stimulus (https://stimulus.hotwired.dev/handbook/introduction) in terms of philosophy and motivation, which I love using.
Cool, ya I'd love your feedback if you get a chance to play around with it! Hibiki aims to be a lot heavier than the hotwire / htmx type frameworks. It also aims to be accessible to devs who know HTML, but aren't JS experts.
Cool! Yeah, I'll sure to give you feedback if I get to try it in the future. I don't hav a use case yet, but I'll keep it mind =)
I've tried to play around with Turbo[0] from the Hotwired project, and've always struggled to get off the ground with it. Whenever I've gone to do anything with it, the documentation has always seemed lacking, and it seemed like their stance was mainly "just use our Ruby Gem!", which isn't so appealing as a Go dev.
[0]: https://turbo.hotwired.dev/
[0]: https://turbo.hotwired.dev/
Yeah I can see how Turbo is more geared towards Rails. I feel like Stimulus is easier to combine with non Rails backends. I found this starter project for Stimulus and Go, if you're interested: https://github.com/narup/go-stimulus
> Anything that Hibiki HTML can do on the frontend can be done with a remote handler by returning specially formatted JSON actions.
I remember using something that worked exactly like that back in the jQuery era. I can’t remember the name though..
I remember using something that worked exactly like that back in the jQuery era. I can’t remember the name though..
The Open-Source-ish license is a bit of danger zone.
> 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 ?
> 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 ?
Ya, I understand your concern, and I may change the license going forward if it causes too much confusion. The intent is that those use cases would be totally fine (unless 3rd party users are literally writing Hibiki HTML code). My intent is more of a temporary anti-cloud-poaching license because I intend to integrate Hibiki into my hosted internal tools platform - https://github.com/sawka/dashborg-go-sdk .
it's already causing too much confusion
Looks great!
How about being able to put markdown between the “<template hibiki/>” things and have hibiki render a beautiful page for me?
How about being able to put markdown between the “<template hibiki/>” things and have hibiki render a beautiful page for me?
I read the intro page and skimmed the rest of the tutorial, and am left this this: What does this provide over HTML/JS?
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.
How does it interact with Python and Flask?
How does it interact with Python and Flask?
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.
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.
Your explanation makes sense - thanks!
I know this isn’t core to your project (which looks very creative and interesting), and I don’t have a strong opinion on this, but I want to throw it out there to get some thoughts:
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.
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.
You can download the script and host it yourself, or serve it locally. I just put it on CloudFlare so it is easy if you don't want to host it yourself.
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.
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.
kudos for putting some stuff out there, but not really seeing a real benefit over more established libs like intercooler, htmx, alpine or petite vue. also seems like your anchor tags in the intro section of your docs aren't working correctly
hmm :/ you're right they weren't working, just fixed them, thanks for pointing that out.
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.
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.
Excellent license, +1 for that!
[deleted]
When did Webpack become a bad thing?
I think most of the problem with Webpack is that it gets complicated and no one is comfortable to touch it. With a little bit of rotation in a team and then most folks are not comfortable to touch. There are also man ways to configure and every project is so different that if you are touching Webpack only once a year that you never get totally expert with it. Hence, at the end, from my experience, people do not enjoy configuring Webpack.
Depending on what your metric is, whenever it came out.
It's amazing! Another JavaScript framework which tries to self sell as something new.
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).