Hacker Newsnew | past | comments | ask | show | jobs | submit | jsunderland323's commentslogin

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?

One thing I still struggle to this day is the float/long conversion from json <-> proto. It somehow works and I still untangle the feeling of magic.

Its generated "TypeScript"... wasn't.

> 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.

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.


Regardless of which approach ends up being right, the tool itself is amazing. Best of luck with it!

Thank you so much! <3

Thanks so much!

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

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.

Pufferbo, my friend. Thank you for writing this comment. This is the kind of feedback we need.

-Dan


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!


But here's the thing: most of your real audience doesn't have API keys (except a few enterprise-ish folks or startups who got credits). They already pay subscription(s) (and will continue to pay the maximum, which will keep growing). The entire token resale model creates a weird economy and interdependency that shouldn't exist in the first place. In the end, all the deals with top-tier labs will be changing, most middlemen will start manipulating the token exchange rate at some point, and there's no transparency or single source of trust. What's the Endspiel here?

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.


Why per month though? What happened to installable products where you pay for a version and then you use that version. How is this a service?

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.


Thanks, that makes sense.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: