HN user

kyle-ssg

28 karma

https://github.com/kyle-ssg

Posts6
Comments27
View on HN

Hey, I should have maybe made this more clear - I definitely don't care that it's 120fps more that the frame rate doesn't drop and we aren't seeing freezes. Initially the project was, with large files, with syntax highlighting especially or switching very large branches. The built-in FPS counter actually proved really helpful in observing these.

Yep of course, Syntax colouring will come. And it was intentionally left out first couple days due to critical path for me, I imagine I'll add intelisense too but I'm glad I decided to make language support installable - goal is fast + great Git.

open in system:

Isn't that reveal in finder? I did add this if so :).

selectively staging lines

Oh I've never actually done this! But I think I understand, so just pushing a few lines in a changed file. Fun! I've always used a different IDE where I don't think that's a thing. I'll add an issue.

What models and tools did you use to create this?

Opus 4.8.

What were your biggest challenges in making this?

UI that had to react due to things such as the window size changing, specifically with horizontal and vertical scrolling and getting it to work with mouse drag + text selection via shift and arrow keys. It was a lot of back and forth. In the end after getting it working for the main editor I (Claude) turned it into a with_scrollbars decorator method.

Knowing to splitting god functions before they sprawl / emphasising regression tests, and specifically frame rate regression has helped me a lot so far I think.

If it were truly as easy as asking an AI once, then everyone would already be shipping successful products daily. AI just lowers the bar to entry.

I could not agree more! I think there's a finite group of people who have a strong software engineering background who really know the rewarding pain and are able to embrace AI in an optimistic way.

I do agree with some of this principle, if I sat blasting prompts with all the things I could think of, of course it won't end well. Strong regression tests and good patterns are needed.

RE a month usage, that is a good idea, I will use it for a month and do a more long-form post.

I've been using it since I started building it, and have not touched my IDE, thats the goal. All commits to the repository have been made via the tool itself.

I think something to note on this as I already see this in the comments. There's always the suggestion of "Yeah that's easy we could do that".

To this I'd say it totally depends on the usecase, I've seen 10s of tech teams build this badly and end up causing more harm than good, some even just static config files that require a build to change which totally defeats the point.

I think looking for an open source tool is great, to this I'd say consider the following :

- Before anything else, you'd definitely want the ability to turn the flags off per environment (dev/prod etc) without having to deploy code.

- Do you want to control who can manage features? Quite often you'd want to enable non-tech people to manage / test features.

- How scalable does it need to be? Some people might want to just not have to worry about serving thousands or millions of flags.

- Do you want to serve flags based on users or maybe even groups of users? I've seen attempts at this but then you start having to worry about setting traits and building some sort of rules engine.