25 ms·

Show HN: Hibiki HTML – New frontend framework – no scaffolding, no Webpack

232 points by sawka 5y ago

Source https://github.com/dashborg/hibiki https://github.com/dashborg/hibiki | Interactive Tutorial https://playground.hibikihtml.com/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).

jozzy-james 5y ago
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
- sawka 5y ago
  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.
shafyy 5y ago
Looks great! Reminds me a bit of Stimulus (https://stimulus.hotwired.dev/handbook/introduction https://stimulus.hotwired.dev/handbook/introduction) in terms of philosophy and motivation, which I love using.
- sawka 5y ago
  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.
  - shafyy 5y ago
    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 =)
- akpa1 5y ago
  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/ https://turbo.hotwired.dev/
  - shafyy 5y ago
    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 https://github.com/narup/go-stimulus
ramesh31 5y ago
When did Webpack become a bad thing?
- recursive 5y ago
  Depending on what your metric is, whenever it came out.
- daok 5y ago
  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.
- cortexio 5y ago
deleted 5y ago
[deleted]
rezonant 5y ago
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 5y ago
  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 5y ago
    This is not quite true. You can easily use react/vue/solid along with unpkg to build fairly complex applications.
    - Waterluvian 5y ago
      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 5y ago
        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.
        stavros 5y ago
        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.
lf-non 5y ago
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 5y ago
  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 https://github.com/sawka/dashborg-go-sdk .
  - kyleee 5y ago
    it's already causing too much confusion
SahAssar 5y ago
> 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 5y ago
  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).
  - netr0ute 5y ago
    Why make it so complicated? I would just use a vanilla AGPLv3.
    - sawka 5y ago
      This project spun out of my startup https://dashborg.net 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.
      - jabbany 5y ago
        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_).
Waterluvian 5y ago
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 5y ago
  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 5y ago
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 https://htmx.org
- sawka 5y ago
  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.
  - lhorie 5y ago
    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)
    - sawka 5y ago
      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.
rubyist5eva 5y ago
The "modified MIT" license is a dealbreaker.
- dark-star 5y ago
  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.
  - notRobot 5y ago
    > 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.
  - rubyist5eva 5y ago
    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.
n3df 5y ago
turtlebits 5y ago
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
- lyncro 5y ago
  Vite [0] configures React, Vue and more perfectly out of the box [0] https://github.com/vitejs/vite https://github.com/vitejs/vite
  - PetahNZ 5y ago
    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.
    - onion2k 5y ago
      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.
- deleted 5y ago
  [deleted]
conradfr 5y ago
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 https://github.com/vuejs/petite-vue
otikik 5y ago
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.
notRobot 5y ago
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 https://playground.hibikihtml.com/tutorial/?page=t-expr --- [0]: https://news.ycombinator.com/item?id=30107918 https://news.ycombinator.com/item?id=30107918 [1]: https://www.dashborg.net/static/hibiki-license.html https://www.dashborg.net/static/hibiki-license.html
- sawka 5y ago
  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.
  - notRobot 5y ago
    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?
    - sawka 5y ago
      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).
paxcoder 5y ago
sawka 5y ago
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 https://tests.hibikihtml.com/test-d3.html (source code here - https://github.com/dashborg/hibiki/blob/main/static/test-d3.html 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 https://testapi.hibikihtml.com/api/d3-test"
- sverhagen 5y ago
  Isn't that the promise too of React, Angular?
  - sawka 5y ago
    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.
phpisatrash 5y ago
It's amazing! Another JavaScript framework which tries to self sell as something new.
VWWHFSfQ 5y ago
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/ https://htmx.org/
- sawka 5y ago
  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.
- svachalek 5y ago
  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.
  - VWWHFSfQ 5y ago
    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 https://support.google.com/code/answer/54830?hl=en
  - sawka 5y ago
    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.
henning 5y ago
> 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.
- sawka 5y ago
  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.
  - KaoruAoiShiho 5y ago
    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?
    - sawka 5y ago
      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.
      - electroly 5y ago
        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.
beders 5y ago
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!
- sawka 5y ago
  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.
delgaudm 5y ago
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
- boffinism 5y ago
  That's like complaining that so-called 'No Code' web platforms are actually using code behind the scenes!
  - idop 5y ago
    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.
    - dkjaudyeqooe 5y ago
      > 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'.
      - idop 5y ago
        And yet, you know that it's there, and nobody called it "without microcode".
      - blacklion 5y ago
        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!
lunch 5y ago
> Hibiki [..] lets you create [..] frontend applications without JavaScript Yet the website is a blank white page, without JavaScript.
dpweb 5y ago
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.
ehsankia 5y ago
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.
deleted 5y ago
[deleted]
pmarreck 5y ago
> 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/ https://choosealicense.com/ and pick something more restrictive than MIT if you want. For example, I used EUPL 1.2 for mine.
sergiotapia 5y ago
Excellent license, +1 for that!
chrismorgan 5y ago
On licensing: I recommend taking a look at the PolyForm Project’s form licenses: https://polyformproject.org/licenses/ https://polyformproject.org/licenses/. PolyForm Shield <https://polyformproject.org/licenses/shield/1.0.0/ 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/ 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 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 https://blueoakcouncil.org/2019/03/06/model.html has some more explanation on why to choose it.
- sawka 5y ago
  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/ https://polyformproject.org/licenses/internal-use/1.0.0/ . Could add that as an alternate license.
- ninjin 5y ago
  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 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 https://blueoakcouncil.org/license-faq
tigrezno 5y ago
No, don't follow the VUE path, don't add your own invented format. Let us just write standard js/html.
- Zababa 5y ago
  Add React to that, JSX is not standard JS/HTML.
  - tigrezno 5y ago
    at least, all files in react are js/ts. .vue files are bullshit
    - Zababa 5y ago
      They're not, they're usually .jsx/.tsx files that needs to be compiled.
- rk06 5y ago
  Vue supports standard js/html/css. It is react which reinventing everything
  - tigrezno 5y ago
    <template>/<script>/options api/... want a word with you. Such a bad framework.
the__alchemist 5y ago
I read the intro page and skimmed the rest of the tutorial, and am left this this: What does this provide over HTML/JS?
- sawka 5y ago
  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__alchemist 5y ago
    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?
    - sawka 5y ago
      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.
sgdesign 5y ago
> 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..
difosfor 5y ago
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.
- sawka 5y ago
  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.
kseistrup 5y ago
Looks great! How about being able to put markdown between the “<template hibiki/>” things and have hibiki render a beautiful page for me?

232 points by sawka 5y ago

jozzy-james 5y ago

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

sawka 5y ago
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.

shafyy 5y ago

Looks great! Reminds me a bit of Stimulus (https://stimulus.hotwired.dev/handbook/introduction https://stimulus.hotwired.dev/handbook/introduction) in terms of philosophy and motivation, which I love using.

sawka 5y ago
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.
- shafyy 5y ago
  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 =)
akpa1 5y ago
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/ https://turbo.hotwired.dev/
- shafyy 5y ago
  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 https://github.com/narup/go-stimulus

ramesh31 5y ago

When did Webpack become a bad thing?

recursive 5y ago
Depending on what your metric is, whenever it came out.
daok 5y ago
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.
cortexio 5y ago

deleted 5y ago

[deleted]

rezonant 5y ago

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 5y ago
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 5y ago
  This is not quite true. You can easily use react/vue/solid along with unpkg to build fairly complex applications.
  - Waterluvian 5y ago
    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 5y ago
      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.
      - stavros 5y ago
        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.

lf-non 5y ago

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 5y ago
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 https://github.com/sawka/dashborg-go-sdk .
- kyleee 5y ago
  it's already causing too much confusion

SahAssar 5y ago

> 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 5y ago
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).
- netr0ute 5y ago
  Why make it so complicated? I would just use a vanilla AGPLv3.
  - sawka 5y ago
    This project spun out of my startup https://dashborg.net 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.
    - jabbany 5y ago
      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_).

Waterluvian 5y ago

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 5y ago
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 5y ago

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 https://htmx.org

sawka 5y ago
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.
- lhorie 5y ago
  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)
  - sawka 5y ago
    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.

rubyist5eva 5y ago

The "modified MIT" license is a dealbreaker.

dark-star 5y ago
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.
- notRobot 5y ago
  > 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.
- rubyist5eva 5y ago
  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.

n3df 5y ago

turtlebits 5y ago

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

lyncro 5y ago
Vite [0] configures React, Vue and more perfectly out of the box [0] https://github.com/vitejs/vite https://github.com/vitejs/vite
- PetahNZ 5y ago
  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.
  - onion2k 5y ago
    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.
deleted 5y ago
[deleted]

conradfr 5y ago

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 https://github.com/vuejs/petite-vue

otikik 5y ago

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.

notRobot 5y ago

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 https://playground.hibikihtml.com/tutorial/?page=t-expr --- [0]: https://news.ycombinator.com/item?id=30107918 https://news.ycombinator.com/item?id=30107918 [1]: https://www.dashborg.net/static/hibiki-license.html https://www.dashborg.net/static/hibiki-license.html

sawka 5y ago
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.
- notRobot 5y ago
  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?
  - sawka 5y ago
    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).

paxcoder 5y ago

sawka 5y ago

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 https://tests.hibikihtml.com/test-d3.html (source code here - https://github.com/dashborg/hibiki/blob/main/static/test-d3.html 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 https://testapi.hibikihtml.com/api/d3-test"

sverhagen 5y ago
Isn't that the promise too of React, Angular?
- sawka 5y ago
  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.

phpisatrash 5y ago

It's amazing! Another JavaScript framework which tries to self sell as something new.

VWWHFSfQ 5y ago

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/ https://htmx.org/

sawka 5y ago
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.
svachalek 5y ago
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.
- VWWHFSfQ 5y ago
  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 https://support.google.com/code/answer/54830?hl=en
- sawka 5y ago
  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.

henning 5y ago

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

sawka 5y ago
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.
- KaoruAoiShiho 5y ago
  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?
  - sawka 5y ago
    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.
    - electroly 5y ago
      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.

beders 5y ago

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!

sawka 5y ago
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.

delgaudm 5y ago

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

boffinism 5y ago
That's like complaining that so-called 'No Code' web platforms are actually using code behind the scenes!
- idop 5y ago
  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.
  - dkjaudyeqooe 5y ago
    > 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'.
    - idop 5y ago
      And yet, you know that it's there, and nobody called it "without microcode".
    - blacklion 5y ago
      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!

lunch 5y ago

> Hibiki [..] lets you create [..] frontend applications without JavaScript Yet the website is a blank white page, without JavaScript.

dpweb 5y ago

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.

ehsankia 5y ago

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.

deleted 5y ago

[deleted]

pmarreck 5y ago

> 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/ https://choosealicense.com/ and pick something more restrictive than MIT if you want. For example, I used EUPL 1.2 for mine.

sergiotapia 5y ago

Excellent license, +1 for that!

chrismorgan 5y ago

On licensing: I recommend taking a look at the PolyForm Project’s form licenses: https://polyformproject.org/licenses/ https://polyformproject.org/licenses/. PolyForm Shield <https://polyformproject.org/licenses/shield/1.0.0/ 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/ 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 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 https://blueoakcouncil.org/2019/03/06/model.html has some more explanation on why to choose it.

sawka 5y ago
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/ https://polyformproject.org/licenses/internal-use/1.0.0/ . Could add that as an alternate license.
ninjin 5y ago
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 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 https://blueoakcouncil.org/license-faq

tigrezno 5y ago

No, don't follow the VUE path, don't add your own invented format. Let us just write standard js/html.

Zababa 5y ago
Add React to that, JSX is not standard JS/HTML.
- tigrezno 5y ago
  at least, all files in react are js/ts. .vue files are bullshit
  - Zababa 5y ago
    They're not, they're usually .jsx/.tsx files that needs to be compiled.
rk06 5y ago
Vue supports standard js/html/css. It is react which reinventing everything
- tigrezno 5y ago
  <template>/<script>/options api/... want a word with you. Such a bad framework.

the__alchemist 5y ago

I read the intro page and skimmed the rest of the tutorial, and am left this this: What does this provide over HTML/JS?

sawka 5y ago
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__alchemist 5y ago
  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?
  - sawka 5y ago
    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.

sgdesign 5y ago

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

difosfor 5y ago

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.

sawka 5y ago
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.

kseistrup 5y ago

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