[HN Gopher] Show HN: Hibiki HTML - New frontend framework - no s...
___________________________________________________________________
Show HN: Hibiki HTML - New frontend framework - no scaffolding, no
Webpack
Source https://github.com/dashborg/hibiki | Interactive Tutorial
https://playground.hibikihtml.com/tutorial/ 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).
Author : sawka
Score : 27 points
Date : 2022-01-27 18:09 UTC (4 hours ago)
(HTM) web link (playground.hibikihtml.com)
(TXT) w3m dump (playground.hibikihtml.com)
| rezonant wrote:
| 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?
| sawka wrote:
| 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.
| lf-non wrote:
| This is not quite true. You can easily use react/vue/solid
| along with unpkg to build fairly complex applications.
| Waterluvian wrote:
| 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.
| sawka wrote:
| 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.
| rezonant wrote:
| 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)
| pjgalbraith wrote:
| 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/
| sawka wrote:
| 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.
| [deleted]
| lf-non wrote:
| 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 ?
| sawka wrote:
| 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 .
| SahAssar wrote:
| > 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.
| sawka wrote:
| 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).
| Waterluvian wrote:
| 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.
| sawka wrote:
| 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.
| harryvederci wrote:
| 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
___________________________________________________________________
(page generated 2022-01-27 23:00 UTC)