I dig this idea. I have the sneaking suspicion that GitHub Gists aren’t a first-class citizen of the overall GitHub product. I tried navigating to mine the other day and found myself ejecting to a search engine to find them. And then wondering if they are something I can trust to be around in the future.
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!).
At first I was like this interesting but I don't see this as more than a hobby project. Then I did some more reading and it turns out they recently raised 5.5M (seed round). I guess if they can become the next place for people to dump code for ML, I can see how they were able to raise.
I don’t know. These things make for very impressive demos and can raise a lot of interest, but the devil is always in the details.
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.
Sort of, but even Cloudflare workers went from a file editor to hosting an IDE-like environment (vscode) for your worker, and allows you to deploy worker "projects" directly from local/CI environments. Most Cloudflare Workers deployments I've seen were for custom proxies, or API transformation layers but nothing more complicated due to all the limitations, and it seems that's exactly what couldflare wants them to be used for, for now at least.
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.
I agree, we have a lot of difficult questions to answer. (Founder of Val Town here)
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 :)
Yeah, Gists don't feel like they've had much attention in a very long time.
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.
> Same reason people think a project is abandoned if it doesn’t get a „bug fixed and improvement“ update shipped every month.
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.
Isn't it easier just to adjust the wording or typos in the comments so that it looks like activity without troubling yourself with actual changes to give the same look?
> adding features can only make it worse, not better.
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).
> 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.
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.
Agreed, as you say it _exceptionally_ well adapted. Where the loop has basically reached a fixed point. As software is a relatively new phenomenon, maybe we'll reach a fixed point for most software in a few hundred years.
I see what you mean here. I tend to agree that Gists seems relatively feature-complete (at least for my basic use case; I can’t speak for others).
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.
This is awsome bc Github Gist links aren't Cool URL's and break on name changes even though repo's don't and Gist's have those hash ID's. I don't know that the Styles need be quite so on-the-nose, though I am glad to see syntax highlighting is already in.
I think this is awesome, but I do not see the use case: Why would anybody register on my site to publish his or her gists? I would love to get my gists from Github published under my site, but for this case I would prefer a static site generator (hugo, jekyll) with a good theme for gists.
Now this had me curious. Is there someone out there who has actually created a theme/template website for a static site generator like Hugo, Zola, or Jekyll where you could use both the usual markdown and the actual code files themselves? It seems fairly doable based off the templating engines available.
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.
if the fediverse supports posting with markdown and code syntax highlighting, what is the benefit of a standalone gist thing?
- Perhaps the ability to edit/clone and update?
- the anonymous dumps use case (which this doesn't support yet)
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.