DiffsHub

mitchellh | a day ago

I'm trying to understand what viewing diffs has to do with vibecoding (the tag).

EDIT:

Okay, I caught up on a bunch of context/drama and understand how this came about. Sorry @quad for the noise. I see its removed now too.

dysoco | a day ago

Lobsters is on a silly phase where people are taking the liberty of judging whether or not a project "looks vibecoded" (e.g. low quality code, low commit count or even just a CLAUDE.md in the repo) and they will tag it as "vibecoding" even though it serves no purpose.

wrl | 19 hours ago

CLAUDE.md in the repo. Incorrectly removed here, was appropriate for the story.

ilyagr | 22 hours ago

Thankfully, the tag seems gone now.

munksgaard | a day ago

For some more context, this post seems to be relevant: On Rendering Diffs

Also, I'm impressed that e.g. browsing the Linux diff linked on the homepage is as smooth as it is. Try dragging the scrollbar manually. If only Github and other in-browser diff editors (I'm using Graphite at work) were that smooth...

On the other hand, I'm that impresses me so much. It should just be the norm, right? </get-off-my-lawn></obvious-engagement-bait>

mitchellh | a day ago

I know the person who did most of the diff rendering work and who authored that article. He was live updating me in texts along the way and its truly incredible how much research and work he put in. His full time job for literally months was to make diffs render fast.

Btw, despite the "vibecoding" tag (which, still confuses me), this work was anything but. The vast vast vast majority was just hard research, reading browser implementation code, trial and error, just good ol' thinking through the problem.

There was agent loops used for discovery of some hyper-focused reward-oriented tasks, but none of that made it in without human insight and review afaik. I think they talk about this in the blog post as well. It was really such a minor part of the work. It'd be totally crazy to dismiss the engineering effort for that reason!

I highly recommend reading the blog post or looking at the code. Amazing stuff, and a lot to learn.

steveklabnik | a day ago

There was agent loops used

This makes it eligible for the “vibe coding” tag.

Yes, it’s stupid. However, a significant portion of the user base wants it this way, and the mods don’t care either, so it is what it is.

altano | 22 hours ago

However, a significant portion of the user base wants it this way

Significant portion or vocal minority?

wrl | 19 hours ago

Going by count of votes, significant portion.

altano | 16 hours ago

Votes on what? Compared to what?

wrl | 54 minutes ago

Take a perusal through the meta tag submissions.

In particular, compare the audience reaction to "Can we stop tagging every thing as vibecoding?" or "Let's rename the "vibecoding" tag to "llms"" against "LLM generated submissions should be disallowed" (currently the most-upvoted submission in Lobsters history), or "Proposal: add "AI generated" as a flag reason".

Not all of these pertain specifically to tagging anything touched by an LLM as "vibecoding", but give a read on the temperature of the community and the general direction that the wind blows, so to speak.

steveklabnik | 21 hours ago

I tried to phrase things as charitably as possible. Any time I post on this topic here I get a ton of vitriol, so.

[OP] quad | 22 hours ago

I tagged it to get ahead of the inevitable witchhunt. Ironically, @mitchellh took it the opposite direction and the tag was removed via suggests.

Can't win for losing.

ilyagr | 22 hours ago

I, for one, don't want it that way. I think this is likely to shake out to a saner approach if we let/encourage it patiently.

Project proud of being all vibecoded (e.g. https://lobste.rs/s/galkdh/grit_rewriting_git_rust_with_agents) --> vibecoding tag makes sense

Projects where agents are tangential to their identity/purpose --> no vibecoding tag

Discussion of vibecoding in a project --> vibecoding tag, if that discussion is interesting enough to be a story

steveklabnik | 21 hours ago

I agree but if half a dozen threads with hundreds of comments aren’t changing anything, I don’t see it changing.

ellie | 20 hours ago

However, a significant portion of the user base wants it this way

I actually stopped visiting lobsters as often because of this. Was there ever a vote or something?

steveklabnik | 19 hours ago

Nope. There have been multiple threads with hundreds of comments each, but they haven’t lead to any change.

Diti | 20 hours ago

Oh? You shouldn’t be getting interactions with people who get irrationally angry at anything vibe-coded (like I do) since they/we filter out the tag.

The tag was removed for this submission though so I’m seeing the slop project.

ocramz | 8 hours ago

a significant portion of the user base wants it this way

respectfully, this is a bullshit argument.

steveklabnik | 5 hours ago

I’m not making an argument. I’m stating a fact. If it were not significant, it wouldn’t be this way. But it is.

driib | 28 minutes ago

Indeed, it should just be the norm. I hope Gitlab and Forgejo pick this up.

I made a bookmarklet to test drive it myself:

javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();

Unfortunately, many PRs require commenting, especially large ones. Let's see when Pierre tries to take this, e.g. create something like https://www.reviewable.io/ ?

mdaniel | a day ago

I couldn't work out why npmjs claimed it was Apache 2 since the repo had no license (and the package.json even has "private":true) but he answer is that it seems each directory is individually licensed https://github.com/pierrecomputer/pierre/blob/diffs-v1.2.11/packages/diffs/LICENSE.md and apparently diffshub itself is not part of the open source bits https://github.com/pierrecomputer/pierre/blob/diffs-v1.2.11/apps/diffshub/package.json#L4

That kind of "surgical licensing" approach makes https://github.com/pierrecomputer/pierre/tree/diffs-v1.2.11/packages/theming#:~:text=The%20theming%20toolkit%20for%20Pierre%27s%20open%2Dsource%20UI%20packages in a weird limbo land (since that directory does not carry the Apache 2 LICENCE.md, unless one counts the package.json field as authoritative)

runxiyu | a day ago

the UI does feel better than github's except for contrast. not sure about a11y though

orib | a day ago

FWIW, you can get the diff for any pull request on github by appending .diff.

For example, https://github.com/oven-sh/bun/pull/30412.diff

Appending .patch lets you get one that can be passed to git am: https://github.com/oven-sh/bun/pull/30412.patch

reivilibre | 21 hours ago

error: too big or took too long to generate

Did you choose this one on purpose for this reason? :D

orib | 20 hours ago

It was the first one on the linked site.

junon | 9 hours ago

Maybe I've just got lower expectations of my tools than others here, but... I don't really see a practical difference between this and GH's own. Everyone seems to lament how bad GH is and I seem not to have the same experience.

I have no idea why I'd use this over Github's.

mitchellh | 4 hours ago

I recorded this video showing why this is important for me. Sorry its X but thats where I've got the video. This is my standard experience historically and I explain why the speed matters. The problem is that when things are slow long enough for my mind to drift to other matters, it really messes up my flow state.

The video does a side by side comparison of how long it takes to open a PR and go to a specific file (a pretty common daily thing for me).

https://x.com/mitchellh/status/2057229385963618787

kraxen72 | 19 hours ago

seems kinda similar to pulldash (by coder.com) and difit (cli which serves a localhost page). not a huge fan of either of those: pulldash was kinda laggy and difit was extra effort, for self-review i just use the git tree compare vscode extension now.

I do like how fast this one is and the overall visuals. tried one of my prs and it looks good enough. maybe i'll bookmark it on pc.

munksgaard | a day ago

Comment removed by author