I think the front and back end of PHP are pretty similar. They are both the same letter P after all.
The collaborative sharing nature of these platforms is a big advantage. (Not just VS Code Marketplace. We have this with all extension and lib and program package managers.)
Current approaches revolve around
- reporting
- manual review
- automated review (checks) for flagging or removal
- secured naming spaces
The problem with the latter is that it is often not necessarily proof of trustworthyness, only that the namespace is owned by the same entity in its entirety.
In my opinion, improvements could be made through
- better indication of publisher identity (verified legal entities like companies, or of persona, or owned domain)
- better indication of publisher trustworthiness (how did they establish themselves as trustworthy; long running contributions in the specific space or in general, long standing online persona, vs "random person", etc)
- more prominent license and source code linking - it should be easy to access the source code to review it
- some platforms implement their own build infrastructure to ensure the source code represents the published package
Maybe there could be some more coordinated efforts of review and approval. Like, if the publisher has a trustworthiness indication, and the package has labeled advocators with their own trustworthiness indicated, you could make a better immediate assessment.
On the more technical side, before the platform, a more restrictive and specific permission system. Like browser extensions ask for permissions on install and/or for specific functionality could be implemented for app extensions and lib packages too. Platform requirements could require minimal defaults and optional things being implemented as optional rather than "ask for everything by default".
What makes you think only GitHub is celebrating?
You're already considering it; try it out.
Exploration and prototyping is not a life-commitment that excludes other options later (like going back to Rust after all).
its a javascript UI framework
a very satisfied field, with a lot of established mainstream options
Blazor is incredibly versatile in terms of where and how you run it. The UI is in HTML and CSS, the generated runtime bindings in JavaScript, but you can code the backend as well as frontend logic in C# / .NET / Razor template files.
It can render on the server or client, even work offline with WebAssembly and Service Worker, and dynamically switch between or combine them.
You can also integrate it into Windows Forms, WPF, or multi-platform .NET MAUI with Webview2, which will render "as a website" while still binding and integrating into other platform UI and code.
Your goals of "neat little GUI" and "as portable as possible" may very well be opposing each other.
Main questions are what do you have (technologies); what are you constraints, and what do you need. Different tech has different UI tech. Overall, most GUI programming is a hassle or mess.
If you want to dip your toes, use the tech you like, and look for simple GUI techs first. Don't try to do everything/all platforms at once first.
its goal is to be more user-accessible than NixOS
How does it attempt to do that? I assume it doesn't change Nix. Does it hide the configuration behind GUIs?
It's upcoming, and the time distance is increasing. They still have time.
a random program
like
alert(Math.random())
You're asking about the backend only, separated from the fronted? The fronted will be HTML only, but independent of the backend anyway?
Doesn't that mean you're introducing another interface and a need for another backend for the HTML frontend generating?
If it's independent, why does the frontend intention matter?
My first choice/exploration would be C#/.NET.
If budgeting donations is difficult, maybe donating time is more viable?
Employees are already paid for. Less people involved to approve too.
If you have the autonomy you may even be able to to without explicit approval.
Kissaki
joined 2 years ago
I've aired my frustration about the terminology previously; anyway, I'm trying to accept the terminology in the interpretation it could make some sense:
You tell the AI the "vibe" of what you want the result to have, and it does that - but of course it's not necessarily that simple. You may end up doing prompt engineering, multiple iterations, trial and error, etc
When we tried a product at my workplace generating a web app prototype in react seemed viable and reasonable, possibly good for prototyping and demonstrating. We also tried a Blazor app, and it utterly failed. I suspect because of less training on it and much more complex mixture of technologies.