Opengist: Open-source alternative to GitHub Gists
github.com
github.com
It's a better interface for editing / creating GitHub gists.
Login with GitHub, get a list of gists, get a full blown CodeMirror-based editor. Preview for markdown files.
And it's open-source: https://github.com/kjk/tools.arslexis.io/tree/main/frontend/...
Built mostly with Svelte 4 and a tiny bit of Go backend.
I use Gists as a way to stash lists publicly. I’m curious what use cases for Gists exist beyond the obvious “here’s a snippet” (which is valuable in and of itself!).
I’ve worked on a project like that before. Very simple editor, you put your code in, and it gives you an API endpoint. Wanna make a change? Just edit, hit save and it’s live. It was a great hit in all demos. Everybody loved it. Then developers actually started using it, and questions like “how do I do dependency management?”, “How do I split my code into multiple files?”, “How do I build my code?”, “What about Java/C#/Go/Python/etc?”, “How do I debug my code?”, “How do I use source control?”, “How do I integrate it into my CI/CD?”, “Can I deploy a container?”, “How do I manage multiple contributors and projects and access and dev/stage/prod?” Come up.
You can see how they skirt around some of these questions. “Modern JavaScript” as in just import from npm or urls so they don’t have to worry about dependency management and putting lots of code in 1 file. Or writing a custom blob library to deal with storage. But the minute you need anything that needs a standard file system, network features, or anything any developer would expect to have, you run into a very steep cliff. You end up slowly needing to implement an IDE, a source control, a CI/CD system, a deployment pipeline, an offline experience, a monitoring story, and many things that are better implemented by many other products already.
They have the same service in a way: HTTP endpoint, email, cron, etc. You can edit your code on the same site, although I think that's much lower on their "features" list as compared to val.
Their answer to some of the questions you frame is simply "you dont".
No filesystem, use R2. No source control, bring your own. No containers, use wasm.
Not to mention that Cloudflare, despite their impressive services and scale, makes no profits. They don't publish details for Workers in particular, but I wouldn't be surprised if it's nothing but a blip in their overall negative income. They are also a public company so they are not beholden to VC influence per se or pressure to make profit on a short time scale. Their stock isn't doing well as a result. I personally have the sense that Cloudflare is playing a very long game and their board are ok with it. But I don't know if val.town or any small-time VC funded startup is playing the same 20/30 year game on becoming the de facto backbone of the internet the way Cloudflare is.
Now we work well with small amounts of code, great for integrations, prototypes, internal tools, hackathon projects, home-cooked apps. You could think of us like "zapier for developers" or "retool but in code". Both of those companies built huge businesses without figuring out a lot of those issues. But we're hopeful we'll figure them out.
eddd-ddde is totally right that we're building a higher-level abstraction, like Heroku did, so we do avoid some complexity that way, and have better scale-to-zero economics, ie no need to lug around a whole file system for each runnable code.
The hard questions I'm currently focused on are working with groups of "vals" (ie folders or projects or some other abstraction), so you can fork, branch, and version them as a group. Part of me just wants to go back to files and folders and leverage git & github, but there's also something really powerful about live, rich, web objects, like tweets or a hacker news thread, that don't map well to files and folders. I really love this public discussion with some of my advisors and main investor about the tradeoffs of files & folders: https://github.com/val-town/val-town-product/discussions/106
We have a great investor (Dan Levine) who knows that these sorts of products take time. We have a small team (currently 4) which means on our current fundraise (5.5m) we have 3-5 years to figure some of these things out. If any of these problems sound interesting and worth tackling to you, we're hiring :)
I still love them as a product and use them on a daily basis, and there's nothing that feels particularly missing from them, but they're clearly not something GitHub are investing a lot of effort in beyond keeping them working at the moment.
If they work and there's nothing missing, what effort would they put into them?
Good point.
Any new product should have $X bugs/month added by the current developers so that future developers can indicate 'signs of life' by fixing $Y bugs/month![1]
TBH, once a product reaches whatever goal the founders set out to achieve, adding features can only make it worse, not better. Bugfixes, refinements? Sure. Extra features? Can only heighten the learning curve for newcomers in the future, even if the incremental learning curve added is small.
[1] With suitable values for $X and $Y so that a project can show slow and steady improvement in reliability, until the inevitable rewrite 12 months later.
There are exceptions, but software is usually part of a system, a social system. Successful software changes its environment, and in turn, the environment demands change from the software, which diligent maintainers attend to.
It follows that, in the general case, "no change in a long time" is a pretty good indicator that the software is either unsuccessful or abandoned. As I said, there are exceptions (gists might be one of them).
Or just exceptionally well adapted to a stable social environment. Which might even be so stable precisely because the software is working so well that no changes to either software or social system -- business processes -- are required.
For my part, I’m reacting to Gists’ place in the overall GitHub UX. Maybe it’s just me, but it feels heavily implied that Gists aren’t part of the golden path.
In the beginning I saw it as just a convenient pastebin service associated with the git service, for single files and quick sharing.
It seems overkill to create a repo. When people make gists that are like 2-3 files they should just make a repo.
On the other hand, Docker seems to be a bit overkill for something one could use a static site for instead if it's supposed to be self-hosted. It's even better security-wise. Otherwise, I wonder if one could upload a gist and have it run on the server through some unknown exploit.