jsunderland323's comments

Thanks! Still ironing out early kinks but I have a couple of friends using it. It’s been a joy to work on.

Hey I'm working on this problem (also a YC company but it's FOSS). It's a Dind approach https://coasts.dev/, I wonder if this works for your setup.

Yeah, I agree but as someone in this thread said, if Temple OS came out today there is no way it wouldn’t be immediately derided as AI slop. That’s what worries me.

Blatant slop is obvious. Slop with a modicum of effort is harder. I’m still adjusting my slop-o-meter on other people’s work. It’s easy for me to identify my own slop, it’s not always so obvious when looking at someone else’s AI assisted work.

I’ve been mulling over this for a couple of days too. I have a project I want to share with the HN community that I put a substantial amount of effort into but it was definitely AI assisted (as is literally everything today).

I’ve read all of the source and I drove the architecture but it would be a stretch to say I didn’t ask for assistance on things that felt fuzzy or foreign to me. I also have generally stopped typing code. I still don’t think the LLM made the project though, it feels like my decision making.

If the bar for Show HN becomes no AI whatsoever then you’re just going to see a bunch of people covering their AI tracks. I’m reluctant to post it because I’m afraid of getting blasted by the community for using AI. At the same time, it is work that I’ve poured hundreds of hours into, that I’m proud of and that I think would be of interest to HN.

I read the Obliteratus post that made it to the front page the other day and I agree that is pure slop. While it’s frustrating that it took up front page space, it’s evident that the whole community caught on to the sloppiness of it all immediately and called it out. I just don’t think HN wants to set the precedent that no AI code should be shared.

I also saw a week or two ago that someone open sourced a project of theirs that wasn’t open source in the first place. The reason they stated was that they had vibe coded and were embarrassed to be discovered. If you want to get a concept out quickly with AI, you’re now hesitant to open source because of the precedent set by the community. I think that’s a scary thought to me. I would rather know the tools I’m using are AI generated/assisted and make the value judgement on if I trust the code and project owners.

Umm it's not as bad I thought it would be. ~16mb per locale. ~28k words in the english docs.

Not schilling, just easier to show you the repo since it's open source. https://github.com/coast-guard/coasts

I'm working on a CLI now.

The pattern I used was this:

1) made a docs command that printed out the path of the available docs

$ my-cli docs

- README.md

- DOC1.md

- dir2/DOC2.md

2) added a --path flag to print out a specific doc (tried to keep each doc less than 400 lines).

$ my-cli docs --path dir2/DOC2.md

# Contents of DOC2.md

3) added embeddings so I could do semantic search

$ my-cli search "how do I install x?"

[1] DOC1.md

"You can install x by ..."

[2] dir2/DOC2.md

"after you install..."

You then just need a simple skill to tell the agent about the docs and search command.

I actually love this as a pattern, it works really well. I got it to work with i18n too.

I’ve had a lot of success with grpc web. Had to patch a couple of things along the way. My biggest misgiving is thinking having bigints would be a good idea (it is not a good idea). Aside from that though, I’ve been happy with it. What felt broken to you?

> seems like the sort of guy with the money and connections to pop the AI bubble

…and has been known to cause bank runs

We actually do support monorepos and it can do multi-file edits.

Hey csomar. If you switch over to discord I can work through it with you there.

> I understand you are trying to make a simple one click/command solution but some setups are more complicated than the standard yarn dev nextjs app.

I agree our docs are totally lacking on the more advanced dns setups! I'm so sorry.

> Maybe you should explain a bit what the server does and what it needs to connect to? why does it need some kind of a "proxy"?

If you don't do the manual installation where you point to the web-socket server in your <head>, it will inject that tag into your <head> tag. The web socket it how the chrome extension communicates with your file system.

You don't need the proxy for most things. It's fine to continue to just use codeinput.com as long as you have a way of making the websocket url discoverable to the extension.

The only other use case for the proxy is if you are on a page that has over 10k react fibers and are not using vite. This comes up a lot in things like CRMs or Next projects with a lot of 3rd party dependencies. In that case we have to find and replace a part of the react source that limits the number of React Fibers with source maps from 10k to 1m.

I tried to give a system design overview here but I will be the first to admit that it's pretty lacking https://jsxtool.com/docs/dev-server/system-design

Thanks! I think we want to get good enough to take over the front end and your IDE is there for backend things but I think it’s a long road to get to that place. For now I feel comfortable promoting that it’s great for small tweaks and style changes but I think it would be pretty disingenuous to tell anyone to ditch their IDE at this point. With that said, we keep building features to make the full IDE dream a reality.

Thank you so much! <3

We actually do have a VSCode plugin we built a couple of months ago. It's a sort of a gnarly install if you run our dev-server from a docker container (which we do), so we shelved it. We dog food everything before putting it out. There's some cleanup we need to do before we publish it but it's coming.

> I'm just curious, why didn't you make this as a VS Code plugin to benefit from all the features of an IDE?

What I was trying to articulate is that I want is to write code in my dev-panel. I don't want to switch panes to an IDE for frontend tweaking. Of course there are times that I do want to switch to my IDE, which is why we developed the VSCode extension that is coming.

> I'd imagine you could do something similar to the Live Server plugin. That way you could support any browser and not worry about maintaining the IDE features.

This may turn out to be the right approach in the end. I've just explored the one avenue that you see today but I could be totally wrong and you might be right that the embedded browser in the IDE approach is the way to go.

Thanks so much!

We do our best! Weak maps are a developer's best friend

I don't think I'm really the best person to defend the practice of recurring revenue but I would rather be transparent that we collect a monthly fee for some features than vanity launch as a one time fee product to hacker news only to pull the rug on my customers a year later.

To be clear, we are not charging you for up to 10 prompts a day with flash or any of our IDE or inspector stuff. We respect your offline privacy and never upload anything that you don't explicitly ask us to use. We open sourced the dev server so that other folks can build JSX inspectors to keep us in check.

> What happened to installable products where you pay for a version and then you use that version.

We're a two person company with a lot of bugs and important IDE features that still need to be built out. You want auto-version updates right now. When we are in a more stable place development-wise I would love to put out a hard cut that folks can pin to.

We gotta stabilize on chromium but then 100%. It's tough while we are so dependent on auto updating to put out hot-fixes. We built with https://wxt.dev, which, I highly recommend. So it shouldn't be too tough of a port. But you are heard loud and clear. Dan hates Chrome from the bottom of his heart.

Well, I'm saying I'm happy to not be involved in the resale token trade in general. I don't think enterprises are the only folks with API keys. There are a lot of people who might not be savvy or motivated enough to setup an API key with Anthropic, OpenAI or Vertex and in those cases we want them to be able to use our key to reduce user friction.

It's not in our interest to resell tokens, it actually diminishes our margin but it's a must if you want to be accessible to folks who don't want to go sign up for an API key. We choose to delay launching by a couple of days so that people could bring their own keys because we don't want to be middle men if you don't want us to be.

If you want to just pay me $16 a month to be a good IDE and inspector, I love that. That's the value I think we provide to you. We cannot control whatever manipulation of token prices occurs with other providers. All we can do is give you enough context for your prompts that you don't need the latest bleeding edge models to make edits to your react code with confidence. We aren't an AI company, we are a devtool that helps with prompting.

No it's all good and it's a fair point.

So from my vantage point we need some way to create revenue. We have tried to make as much of the tool free as we can. We do a 10% markup on tokens issued by us. That's better than cursor who does 25%. We support BYOK so you can use your own claude key, and vertex key. If you do that you are basically just paying us a flat troll tole of $16/month to use our entire frontend but you are free to be unbounded by a markup on your tokens. We actually prefer this because it's better unit economics for us. So please bring your own key!

To be clear, I'm with you 100%. You have my word that I will add in playwright when we get to a point where we can support it.