Show HN: A backend agnostic Ruby framework for building reactive desktop apps
codeberg.org92 points by zero-st4rs 4 days ago
92 points by zero-st4rs 4 days ago
For a year or two I've been building a UI library with the aim of making desktop applications fun and easy to write.
It is currently written in C/Ruby and uses a custom tree sitter grammar to describe templates.
Features include: composable UI components, template directives, event and prop handling, slots, styles and automation capabilities baked in.
One of the goals of the project is privileging easy to write custom components via a drawing API over providing a fixed set of components.
At the time of this writing it should install on Windows, Mac, and Linux, but sometimes it is hard to test the install on all platforms.
I'd love to hear any feedback or suggestions on the project. It is still in an early stage, but it would be great to hear thoughts.
Docs are here: https://hokusai.skinnyjames.net/ Repo is here: https://codeberg.org/skinnyjames/hokusai
Licensed under the PPL
Could you add some information about licence? Currently I don't know what is it compatible with and it's not listed on OSI. So unless someone's up for reading lots of legalese, it's not easy to use/publish. Yeah, this still doesn't answer: can I use this with agpl, gpl, lgpl, apache2, others. The summary on top seems to imply that it's not AGPL/GPL compatible since it talks about granting specific types of organisations some monetization privileges. It doesn't simplify what the rules are (what qualifies as use?), without having to read the licence itself. On the first read it's basically: compatible with BSD-like and PPL... and not much else? It actually seems to break the licensing itself - the colorize gem is GPL2, which seems not compatible with PPL. https://github.com/fazibear/colorize/blob/master/LICENSE https://codeberg.org/skinnyjames/hokusai/src/commit/5380728d... Yeah, the main thing I understand about PPL is that it behaves like the GPL license, but has provisions for worker owned cooperatives or non-profits. 4.c. (Looking at the information again around this license, I suspect I may be incorrect though) And you are correct, including colorize does break GPL2, I'm surprised I missed that. Any lawyers out there? :) Disclaimer: I am not a legal professional (in any jurisdiction), and this is not any form of an official advice.
But I've happened to work as "engineer in licensing and copy activation" for one of the major FOSS vendors, and then being a licensing compliance officer in another large-ish FOSS project; and here are my 2¢: You are indeed in violation of GPL2 when building on top of GPL2-licensed code and giving it a non-compatible license. And PPL is explicitly non-compatible, since it restricts the "four freedoms of FOSS" for some actors (as despicable as they might be), while GPL is explicitly restricting any form of judgement when providing the four freedoms. On a more general note — I appreciate the spirit and the intention behind your licensing choice, but unfortunately in practice this would mean severe impediment for hokusai adoption.
Like, it would be technically hard/impossible to include hokusai and derived works into any software packets distribution: they both technically and by policy are usually restricted to "clear, well-known licenses" (which typically means OSI/FSF-recognized ones), and it might not even be possible to express your licensing choice when putting the code up there.
And who would pick a GUI toolkit to build with, when the resulting code can't even be published in the package repos of their Linux distro of choice? On a more fundamental level (and I start feeling out of my depth here a little bit) — Creative Commons licenses and their derivatives are usually not a great fit for software code. Eg right here in the comments someone already mentioned that it's not clear what constitutes "use" of your codebase — and indeed, the text of your license mostly focuses on Reproduction, Distribution and Adaptation.
If I build and html-based webapp on hokusai, run it on my own server, and you open the page — is this Distribution or Reproduction, for whom of us? Even worse, if hokusai is being used in a startup which assigned shares (not options) to its founding engineers, but not to everyone — is it a "worker-owned business" or not?
What about an exploitive business which frames itself as a coop/NGO/whatever, but frames it actual workers as contractors (Uber-style)? Legally it might pass the benchmark outlined in PPL, but in practice it might be even more exploitative than just hiring someone at the labor market rates. Same with an org which exploits unpaid interns or volunteers... Thanks so much for the clarifying and thorough information. I will admit that my choice to use PPL is reactionary to the ecosystems of software development as they are now, which I'm not sure GPLv2 addresses. I personally don't really understand why all information shouldn't be free without conditions. Cooperative ethos is also voluntary, so it also isn't my intention to enforce that. That being said, I might have to think on it for a bit. Hokusai was originally made with Crystal lang, but now uses a Ruby interpreter, so a considerable portion of any derivative source will be available regardless of using the GPL or not. Could a more permissive license prevent an end-user from re-publishing these sources? There is also an issue with resource allocation (eg. time). The reason I don't think the GPL works well is that most individuals cannot sustain the effort to fully develop many projects that could supplant competitive ones (a necessary condition for equity imo) because they have to live, and living requires money (time). The closest model I am able to think of is software that has very cheap licenses for the lifetime of that project (as opposed to monthly subscriptions or licenses that are absurdly expensive). Maybe sponsorships are a better answer to these questions. All in all, these are probably concerns with how companies and people exploit each other as opposed to how software should be available. Maybe GPL2 or a more permissive license is the way to go? In my (limited) understanding, running your source code using a GPL-licensed interpreter to run the code is not considered _linking_, and thus GPL would not infect the code in question. (This is what allows even prorpietary code to run on top of OpenJDK, which is itself GPL-licensed).
In Ruby's YARV interpreter case it's even more straightforward — Ruby License is essentially "either our custom or BSD-2" (https://www.ruby-lang.org/en/about/license.txt), so no "infectious copyleft" happens when running software with YARV. I'm a little bit uncertain with what you mean with "prevent an end-user from re-publishing", and what's a desired behaviour here: licenses differ in who they consider to be an end-user (that's the main difference between GPL and AGPL, for example) and if they give any end-user a blanket permission to **obtain** the source code (that's the most substantial difference between copyleft and permissive licenses). WRT business models on top of FOSS — I fully understand the struggle. I cannot possible give any meaningful advise in hokusai's specific case (and arguably I'm even less qualified to do this than commenting on licensing intricacies, please keep this in mind) — but the successful business models in FOSS I've witnessed range from "this is our GPL-licensed code, but you can buy a proprietary non-copyleft rights from us if you're a commercial enterprise" to "this is your GPL-licensed source; if you don't want to deal with its', pretty complicated, compilation — you can buy binaries from us" to "hey, this is my Patreon/Github Sponsorship — if you want new releases to keep coming, put some money where your mouth is". Feel free to email/message me (link in the profile), maybe I can help you find a setup which would be the best match to your ideas of how it all should work — hopefully without putting the further adoption of hokusai under unnecessary risk... (But, again, I'm just a random guy from the Internet, and all this would be just my pretty unprofessional opinion...) This is reminding me a lot of shoes.rb (in a good way) Awesome work! Thanks! _why is the person who really sparked my love and engagement with Ruby so this means a lot. This looks super cool, exactly what I've been wanting to create some useful widgets! Thanks for sharing! Thanks! I'm really interested to hear how it "plays" for people. Would love updates if you use it. First time I hear about "copyfarleft license". I wonder what that means in practice for such a library. Thanks for raising this question. From the discussion here: https://news.ycombinator.com/item?id=43938309, it probably won't stay PPL for much longer. It just needs to be worked out. Very cool project, and well thought with the choice of Raylib or SDL2. But since Raylib can compile to Android (https://github.com/raysan5/raylib/blob/master/examples/Makef...), do you think it could be difficult to add Android as a target platform ? Interesting, for sure. I don't know much about Ruby on android (the resulting application will absolutely need a ruby interpreter) but I thought Windows would be a no-op and I got it working there, so who knows? :) Ahah nice, I will definitively craft some GUIs for fun with your lib and make you some feedback. Thanks for this project ! How would you compare this to RubyMotion? Great question. From what I understand of RubyMotion, it compiles directly to native, calling into Objective C APIs, and like DragonRuby the Ruby implementation is not MRI. Since Hokusai uses MRI, one can pull in from that ecosystem of gems. RubyMotion also appears to support (iOS, Android, OSX) whereas Hokusai intends to support OSX, Linux, and Windows. Implementation-wise, the framework itself seems different. Looking at the following [RubyMotion app](https://github.com/HipByte/RubyMotionSamples/tree/master/ios...), the logic is spread out over separate files and it doesn't appear to have a templating language. On the other hand, Hokusai UI components are just a class that inherits from Hokusai::Block, and are self contained blocks that can be stitched together. Hokusai is more like Vue Single file components in this regard.
Hokusai also doesn't make a distinction between a "component" and an "app", they are all just Blocks. Does that answer your question? looks neat, and definitely in the spiritual tradition of shoes! how does deployment work? can this be used to ship apps where the end user doesn't need to be aware of hokusai or ruby? This is a great question that I don't yet have an answer for. Ideally, there should be an automated way builtin to the gem that packages apps. Currently, I use a tool I wrote called Barista to package an an application with it's dependencies, (part of it was modeled after chef/omnibus). This might not be the best way though, so I'm open to ideas. Looks really cool. Just a curiosity though, why xmake instead of rake? Good question! Most of the development build fetches and compiles C dependencies. xmake happens to be really good at this, especially considering xmake-repo. Rake tasks don't have builtins for this iirc. this is really cool, thanks for contributing to the ruby ecosystem!!
Do you have any example sites? I couldn't find a reference on your overview Yup! https://hokusai.skinnyjames.net has a guide with screenshots. The repo itself has more examples. Cool.. I guess but I just wonder.. is writing the UIs in code an actual practice that people do these days? I program (mostly) in C++ using Qt for my UIs and I just use the Qt Designer to visually drag and drop to build my UIs and the actual code gets generated by the tool. Fast and simple. As an end user, what's the licensing situation like with Qt? I was looking to build a cross-platform desktop application (down the rabbit hole...) and was frustrated with the number of options that were just a web view of some sort and some bindings to a JS/TS framework of your choice (I don't have one and don't really want to have to use one or bundle it with the application). Qt looked interesting, particularly with the concise syntax afforted by QML and QtQuick, but the licensing was off-putting and even just getting access (for a non-commercial project for example) seemed to require an awkward sign-up and some kind of installer. I crave the conciseness and simplicity of something like SwiftUI but the options for doing that in a cross-platform way seem limited. It's double licensed. The Qt Company offers both a commercial and LGPL license but they do their best to bury and hide the LGPL option and use dark patterns to try to trick one to get the commercial license. They also want to push you towards getting an account with them for the installer. That being said the packages (without online installer) are also available for direct download when you know where to look... [see link below] If you're on Linux though the situation is much simpler since your distribution most likely already packages the Qt libs so you just use your package manager to install them and off you go... Regardless, for anyone looking for a native portable toolkit, I don't really think there's anything that comes close to Qt in terms of functionality and tooling (like Qt Creator and Qt Designer) and once you get over the idiosyncrasies and quirks its really quite good (for the most part). I'm on macOS a lot of the time so I did get to the installer part and immediately stopped as it felt like LGPL-licensed software should be accessible without needing an account, an installer (is it useful?) or anything except allowing the end user to access libraries and headers directly. For the developer that knows what they're doing the installer is not absolutely necessary, you can just download the zip (or tar.gz) and extract the whole thing somewhere and go from there. The installer does provide some more advanced features such as selecting feature by feature and version by version which Qt components you want to install. At least this is how it works on Windows, I expect Mac to behave similarly. For the end user of your product you'd of course package your software with the Qt libs (or integrate the Qt installation process in your application installation process) so that the end user doesn't need to know nor care about Qt installation at all. Almost everywhere and everything I’ve worked on that had a UI layer has eventually - if it didn’t start there - landed on just managing the UI in code itself. Most UIs are made with web technologies without WYSIWYG. And now quite a lot of UIs on desktop are made with web tech.
viraptor - 4 days ago
maxmcd - 4 days ago
viraptor - 4 days ago
zero-st4rs - 4 days ago
kirushik - 3 days ago
zero-st4rs - 3 days ago
kirushik - a day ago
omneity - 4 days ago
zero-st4rs - 3 days ago
xfalcox - 4 days ago
zero-st4rs - 4 days ago
jenadine - 4 days ago
zero-st4rs - 3 days ago
az09mugen - 4 days ago
zero-st4rs - 4 days ago
az09mugen - 4 days ago
whalesalad - 4 days ago
zero-st4rs - 4 days ago
zem - 4 days ago
zero-st4rs - 3 days ago
dismalaf - 4 days ago
zero-st4rs - 4 days ago
iraliaf - 4 days ago
zero-st4rs - 4 days ago
samiv - 4 days ago
sunrunner - 4 days ago
samiv - 4 days ago
sunrunner - 4 days ago
samiv - 4 days ago
Klonoar - 2 days ago
teaearlgraycold - 4 days ago