I tried it on a hello world example and was surprised to see that when I run `python test.py` it opens the app at a https://console.pglet.io URL -- it seems to copy my code into the cloud when I run it.
For me it means that project is just a toy. Maybe an amazing one, but still.
In most of my positions in the past pushing random company data outside is a serious nono. I have enforced and agreed on that myself. So me using recklessly such a project naively thinking it will act politely means I might not have a job any more.
So - maybe I would play with it at home, but if I won't ever use it at a job (AGPL also adds to it), why bother?
Oh, no, I've missed my HN moment! :) Anyway, hope it's not too late to say hi and answer some questions.
Hi, I'm Feodor - the author of Pglet. The project is still in "alpha" and there is still a lot of experimenting around default modes and API will probably have some breaking changes going forward.
Thank you for the constructive feedback you guys gave here!
Re: licensing - Only Pglet Server is under AGPL at the moment, multi-language client libraries which are embedded in your app are MIT. Selection of AGPL is not final and was mostly influenced by recent fear/trend of big co incorporating your service into their cloud offerings.
Re: remote mode by default - your app code is not being uploaded to console.pglet.io, but it's UI is "streamed" there only. However, I agree this looks scary for the initial experience - will roll it back to "local" mode by default with explicit "publish" option.
Better docs, more examples and other languages support (Go, Rust, Deno) are coming later this year. Stay tuned!
So this is basically a web version of Gtk-server? One then wonders if this couldn't have Gtk-server's interface. Or, vice versa, if Pglet interface couldn't be added to Gtk-server.
Presumably someone who chooses AGPL intentionally wants to exclude people who "won't go near AGPL", in which case this can't be a terrible choice, by construction.
Because most of us aren’t in a position where we can give away our code.
There is a minefield regarding using AGPL servers and I prefer working around it.
If I build AGPL code into my code or vice versa however it becomes very clear as far as I cam see: I have to provide a download link to the entire product.
For many of us that is not an option: My clients would of course reject that, and of course I would not use it for my own for-profit projects either.
It's dubious and untested whether the "but it's an external process" defense works against AGPL, especially when you're writing your program literally against the API of the project. It also seems inaccurate given the example from the README:
i'm convinced two-way binding is an anti-feature in reactive UI. bindings should flow one way from model to view, and view changes should be reflected back to the model via events.
Looks really nice but sadly there aren't many PowerShell examples. I will stick to Universal Dashboard until they can provide some examples of this working with PowerShell.
Just looked through the source, that is not a client! There is only a constructor to create a "Page" but the page has no methods, and there is nothing else exported.
