I have no doubt this could be a useful tool given the nice looking UX, but everything it does is already in Devtools.
If you open Devtools, then click "Sources", there are two options in the left panel 'Page' and 'Workspace'. Change to workspace and add the folder where your project lives. Now you can edit the code for your React (or anything else) project in Devtools and it'll save to your filesystem. You can make this a part of the project if you want to - https://chromium.googlesource.com/devtools/devtools-frontend...
Gemini is integrated into the Sources panel, so I just opened a JSX file and asked what classes I'd use in Tailwind to replace my CSS and it told me the right answer. It didn't update the code though. That 'Apply Edits' feature in jsxtool would be useful for a non-dev user.
Excited to try this! I think you're really onto something w your insight about advantages of IDE in devtools context. I've been doing React about a decade too (and webdev since 1998), and this really resonates.
This is exactly what I was looking for the other day! I'm very happy you guys are working on this because I can see a lot of potential. My main use case is just finding which element in my code controls which element in the browser when I hover over it.
My current workflow is to be in the dev tools, find the element I want to edit, edit the CSS to see if it looks how I want, copy the classname and html to then search in my codebase and make the exact same change there.
I am failing to get it work on a "custom" setup. I run my own server with localhost pointed to the domain, with HTTPS on locally generated certificates.
[jsx-tool] Proxy server running at http://localhost:4000
[jsx-tool] Forwarding to https://codeinput.com:443
[jsx-tool] WebSocket server listening on ws://localhost:12021
[jsx-tool] LSP worker exited with code 1
[jsx-tool] Restarting LSP worker...
[jsx-tool] LSP worker already started
(node:7881) [DEP0060] DeprecationWarning: The `util._extend` API is deprecated. Please use Object.assign() instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
[jsx-tool] Proxy error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca
[jsx-tool] Proxy error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca
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"? 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.
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.
Congrats on the launch! I think this has a lot of potential in eliminating context-switching. DevTools has always felt unintuitive/unfamiliar coming from an IDE, so just bringing the IDE UX and vim keybindings over is already a big improvement. It also makes LLM prompting feel better contextualized.
As an aside, thinking back to learning React seven or eight years ago by watching a bunch of tutorial videos where they'd switch between IDE and browser views or awkward split screens, this seems like a way better format for explainers/walkthroughs of frontend code.
>I needed it to be a pretty fully functional IDE. I needed [IDE feature]...
I'm just curious, why didn't you make this as a VS Code plugin to benefit from all the features of an IDE? 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.
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.
Came here to say something critical because modern front-end dev is a self-inflicted hellscape.
I watched the video and "deving from the UI" makes sense! Instantly get the value. Pretty cool!
It's another hurdle as to whether I'm really going to pay the switching cost of changing my dev flow, but it is a very intuitive and compelling proposition. well done.
I walk into everything ready to be hyper critical, so thanks so much for saying that.
In my experience, I found the switching cost to be low for things like copy changes and css stuff (or lower than I expected). Obviously I am incentivized more than anyone else to use it but it’s actually painful to go to an IDE to make those small changes after you get used to it.
I don’t realistically expect anyone to use us as a full IDE yet. It’s got a ways to go but for simple things, it’s awesome. We’re going to keep chipping away though.
Although I gave up on it, I had a similar idea. I built "VimTools", which allowed you to navigate between different sources on a webpage (via dev tools) and edit them, vim-style. I didn't get beyond the navigation part, though.
If you can implement some Vim-style navigation and key-bindings into this, that would be awesome!
It does! I'm an avid vim user so I made sure it had ctrl-p, ctrl-w (for window switching), (slash space for search), a nerd tree equivalent file tree explorer. I build all features to be vim compliant first. Just toggle enable vim mode in the settings.
I think this is cool! Honestly it’s one less click back into an IDE. I think I’d still have to hop back to commit to git, but it’d save me all the copy+paste time (esp w/ css styles).
CMD k instead of right click. But you have to have the dev server installed. We can’t edit source maps, we can only edit your actual source code. But there’s a full IDE in there so you can easily update the jsx code from your browser.
I'm a bit confused by the marketing verbiage and tool name. Is this going to target React only, or will it (eventually) support other solutions which use JSX, such as SolidJS?
Surprised by all the hostility in the comments: if this tool actually works as described in the video, you've created a whole new generation of dev tool with JSX Tool!
Me too. I know HN doesn't love YC companies but I was a little shocked.
I swear it isn't vaporware but there's only one way to find out.
There are definitely rough edges, we are after all a 2 man band but I don't ship things that don't work and it's admittedly not done great with older versions of React. You should try it though!
I've always wondered why this is (after all HN is basically YC) and I feel like it wasn't this way before but don't have evidence. HN leans skeptical and critical so maybe the AI wave brings that out in spades
I would love to go there! All of our fire power is going into make the IDE great at this time. Once, we accomplish that I think we may earn ourselves the right to do more exotic agent stuff with things like Playwright. But that's the general direction I think all this stuff is going
Most big corporates have their own inner sourced css components library. So when you get design feedback you wouldn't be directly editing the style in one self contained web application, which is what this demo is assuming.
A lot of people use LLM subscriptions, they don't use API keys. Why devtool devs continue to ignore this? I mean, ok, you have your "pricing" reselling an access to LLM models, that's the only, probably, simple way to monetize it, but it's a bad way in 2025, seriously. Allow me to bring my oauth with claude max, and/or offload whatever you do to my local claude code (or if there's some magic behind orchestration use SDK). And, oops, there's nothing to monetize and the entire thing can be recreated with vibe coding within a few weeks (it's not so much there, let's be honest).
I apologize for the writing style, don't take it personally, just every devtool product I see on HN nowadays fails for this particular reason.
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.
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.
AFAIK, every tool out there that lets you do oauth with your Claude Max plan is doing so with the same copy-pasted client id/secret that are extracted from Claude Code. It's not clear at all that this is above board, and when I asked our Anthropic rep, they encouraged us not to do this.
If there's an official way for 3rd party devs to piggyback on Anthropic plans, someone please tell me how!
fyi sometimes its because anthropic may have disallowed it. oauthing with your plan to bring the anthropic subsidy to non anthropic products is understandably a tricky deal unless you're scaled enough to make it make sense for both sides.
Congrats on the launch. Looks great! Do you envision this being used as the primary IDE or just for quick changes/tweaks while the main development is done on a standard IDE eg VSCode?
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.
and it's not compatible with latest version of react?
> React 19 Memory Optimization Detected
React has detected that this is a large page and is removing source information that is necessary for JSX Tool to run. This optimization helps improve performance but prevents JSX Tool from inspecting your React components. You can either navigate to a different page or override this limitation using the proxy setup.
It is. You need to setup the dev server to overcome this limit. That’s why we put that warning there. React 19 limits the number of fiber nodes with source maps to 10k. When you enable the proxy we update it to 1m but we have to do a find replace in the source for this limit, so you have to proxy through us or let our vite plugin transform the js file.
Are you saying you invented hot reload? And a dev tools css editor?
I am confused, because the ability to edit code and have the page update instantly exists with Vite, and next.js, and a bunch of other frameworks. It’s janky at times but good enough for most - and your edits are in your repo ready to commit. And browser CSS inspectors are really great. And there’s the React DevTools if you need to see props & component hierarchy.
Can you explain the value add over all these free things we already have?
I'm not saying that, no. We are super dependent upon HMR servers from Vite/Next.
We made the ability to write back from your dev panel to your filesystem and made a JSX inspector. As far as I know these are not things supported by either Next or Vite.
> And browser CSS inspectors are really great
I couldn't agree more. I agree so much that we wanted to make one so that you could do the same to JSX as you can do to HTML.
> Can you explain the value add over all these free things we already have?
Pretty cool project! I love to see progress on the UX of how we write and manage code.
My honest feedback to you here is, this isn’t very valuable by itself as a local dev tool. Make it so it can be run targeting a git repository with live preview and deployment to a real environment and you may have something much better!
Take a look at Theia IDE, maybe you could find a bridge to do that?
Hey, sorry, I tried to write my feedback with a little more empathy but I guess I should have been upfront to clarify my point.
What I meant to say is, I can't see this competing with the current state of the art as it comes to local development. As for remote development, we are quite lacking there IMO, and this seems to be a great potential candidate to solve that problem.
I do a large portion of my development locally, it's great, I love it. This product is trying to get me to change my workflow there and asking me to do it from the browser only. Why would I work on a browser only if I have a full suite of tools locally, terminals, IDEs, text-editors, rich LSP / plugins / Agents / etc.
Nice! Yeah, I don’t think we’re the only guys out there letting you map back to your file system. I think we’re first and foremost a JSX inspector that lets you locate your line of code but then there’s a bunch of different directions you can go from there —- editing being a big one.
Sort of. I think we want to leverage the parts of the runtime that Cursor wouldn’t be as good at. I don’t expect to replace Cursor, I expect to be better at a lot of React things that take advantage of the runtime and browser context.
because you're ex YC i feel ok giving some tough love that i dont think this is a good plan because cursor and v0 will eat your lunch if you get any traction, however, happy koding and may you find the thing you were meant to do.
I don’t mind the tough love one bit. Yeah, could happen. Startups just aren’t defensible creatures, especially in the post network effect world of AI. But having spent a bit of time in the world of startups (I worked at YC), I think it’s easy to forget that people build in an incumbent’s space all the time... and yes, usually those startups get killed. But by your logic, Cursor should not exist. We should all be using GitHub copilot. The browser IDE is really a new category so I think it will be somewhat awkward for any incumbent.
To be clear, I fully expect Vercel to launch something and for them to have the best distribution in the world. I don’t think they will ever support Vite or things that aren’t Next but que sera sera.
It is going to be a very competitive market but you still have a chance if you serve the needs of professional React development. Unlike POC and MVP projects by people who are learning React, professional React projects that serve production are very complex. Developers need to deliver features without regression, debug with whatever tools they have to find out root cause and fix the bug without causing regression and more issues. Tight unit tests, integration tests and QA cycles.
I have been using Cursor + Claude (Composer) in production code base with some success. Integrations with live React DevTools in the browser could make UI debugging and iterative development much faster. But you also need to think outside of the box of IDE. It is never about IDE. It is about high quality workflow.
That is why Playwright might be a critical piece of the puzzle instead of good to have.
I have instructed agent to generate Playwright test from screenshots that will dump API calls to debug and generate mocks to trigger the edge cases bugs. I am sure if jstool is there, it can fix the bug and reload.
If you can build browser automation into jsxtool, perhaps it can replace playwright. If I remember correctly, the guys who developed puppeteer/playwright used to work for chrome devTools or something.
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.
Startups aren't supposed to be "venture scale" when they launch. (I don't know what "venture scale" means, but it sounds big.) They're supposed to make something that at least a few people want, and then iterate.
just keep in mind you weren't in the pitch room. I'm old enough now to realize that not everything we see in public is the full story.
It may be all a pipe dream and not pan out, but I bet they pitched a path to more broader optionality. That's all you really need, momentum and optionality.
We haven't gotten much further than just launching and praying.
> Is this sponsored by yc?
I mean we're a YC portfolio company, so sort of I guess. I used to work at YC, so I suppose YC has been sponsoring me for a while now.
> Who are the target audience?
React developers
> Are the target audience companies or businesses or individuals?
Both, I hope. We definitely went more along the lines of supporting individual developers spiritually but there is no reason it shouldn't work if you have colleagues.
I have no doubt this could be a useful tool given the nice looking UX, but everything it does is already in Devtools.
If you open Devtools, then click "Sources", there are two options in the left panel 'Page' and 'Workspace'. Change to workspace and add the folder where your project lives. Now you can edit the code for your React (or anything else) project in Devtools and it'll save to your filesystem. You can make this a part of the project if you want to - https://chromium.googlesource.com/devtools/devtools-frontend...
Gemini is integrated into the Sources panel, so I just opened a JSX file and asked what classes I'd use in Tailwind to replace my CSS and it told me the right answer. It didn't update the code though. That 'Apply Edits' feature in jsxtool would be useful for a non-dev user.
Excited to try this! I think you're really onto something w your insight about advantages of IDE in devtools context. I've been doing React about a decade too (and webdev since 1998), and this really resonates.
Aw thanks so much. I knew there had to be some folks whom this would resonate with.
I'm excited for you to try it out too! Please let me know how it goes
This is exactly what I was looking for the other day! I'm very happy you guys are working on this because I can see a lot of potential. My main use case is just finding which element in my code controls which element in the browser when I hover over it.
My current workflow is to be in the dev tools, find the element I want to edit, edit the CSS to see if it looks how I want, copy the classname and html to then search in my codebase and make the exact same change there.
I am failing to get it work on a "custom" setup. I run my own server with localhost pointed to the domain, with HTTPS on locally generated certificates.
I tried
but got 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"? 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.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
Congrats on the launch! I think this has a lot of potential in eliminating context-switching. DevTools has always felt unintuitive/unfamiliar coming from an IDE, so just bringing the IDE UX and vim keybindings over is already a big improvement. It also makes LLM prompting feel better contextualized.
As an aside, thinking back to learning React seven or eight years ago by watching a bunch of tutorial videos where they'd switch between IDE and browser views or awkward split screens, this seems like a way better format for explainers/walkthroughs of frontend code.
Haha. I had the same thought. I told my mom if it doesn’t work out for developers I can always pitch it as a tool to teach people React.
Thanks for the comment man!
This looks awesome!
>I needed it to be a pretty fully functional IDE. I needed [IDE feature]...
I'm just curious, why didn't you make this as a VS Code plugin to benefit from all the features of an IDE? 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.
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
Came here to say something critical because modern front-end dev is a self-inflicted hellscape.
I watched the video and "deving from the UI" makes sense! Instantly get the value. Pretty cool!
It's another hurdle as to whether I'm really going to pay the switching cost of changing my dev flow, but it is a very intuitive and compelling proposition. well done.
I walk into everything ready to be hyper critical, so thanks so much for saying that.
In my experience, I found the switching cost to be low for things like copy changes and css stuff (or lower than I expected). Obviously I am incentivized more than anyone else to use it but it’s actually painful to go to an IDE to make those small changes after you get used to it.
I don’t realistically expect anyone to use us as a full IDE yet. It’s got a ways to go but for simple things, it’s awesome. We’re going to keep chipping away though.
Although I gave up on it, I had a similar idea. I built "VimTools", which allowed you to navigate between different sources on a webpage (via dev tools) and edit them, vim-style. I didn't get beyond the navigation part, though.
If you can implement some Vim-style navigation and key-bindings into this, that would be awesome!
It does! I'm an avid vim user so I made sure it had ctrl-p, ctrl-w (for window switching), (slash space for search), a nerd tree equivalent file tree explorer. I build all features to be vim compliant first. Just toggle enable vim mode in the settings.
Oooh! Great!
I haven't really been developing with React recently, but will definitely check this out!
I think this is cool! Honestly it’s one less click back into an IDE. I think I’d still have to hop back to commit to git, but it’d save me all the copy+paste time (esp w/ css styles).
I hope there’s a right click, “edit JSX” button.
CMD k instead of right click. But you have to have the dev server installed. We can’t edit source maps, we can only edit your actual source code. But there’s a full IDE in there so you can easily update the jsx code from your browser.
I'm a bit confused by the marketing verbiage and tool name. Is this going to target React only, or will it (eventually) support other solutions which use JSX, such as SolidJS?
It's a bit of an aspirational name. For now it's just React, but we hope to get to support other frameworks that use JSX when we have more bandwidth!
Surprised by all the hostility in the comments: if this tool actually works as described in the video, you've created a whole new generation of dev tool with JSX Tool!
Me too. I know HN doesn't love YC companies but I was a little shocked.
I swear it isn't vaporware but there's only one way to find out.
There are definitely rough edges, we are after all a 2 man band but I don't ship things that don't work and it's admittedly not done great with older versions of React. You should try it though!
> I know HN doesn't love YC companies
I've always wondered why this is (after all HN is basically YC) and I feel like it wasn't this way before but don't have evidence. HN leans skeptical and critical so maybe the AI wave brings that out in spades
> I've always wondered why this is
Anyone here for too long does not get minimally impressed by Launch HNs anymore, and the quality isn't improving, to say the least.
Envy.
They see stuff that they could've built too, at least they think, but didn't so they shoot it down.
The thread seems pretty positive at this point...I think this might be a case of the contrarian dynamic:
https://news.ycombinator.com/item?id=24215211
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
There was barely any hostility and all the comments even remotely critical are downvoted to oblivion
What is the point of posting here if anything critical is just a downvoted down
I thought these posts are for feedback
Just a thought. Can you automate live UI development in your platform with Playwright? That will make agent integration easier.
I would love to go there! All of our fire power is going into make the IDE great at this time. Once, we accomplish that I think we may earn ourselves the right to do more exotic agent stuff with things like Playwright. But that's the general direction I think all this stuff is going
I guess you can at least try to use Playwright for test coverage. This stuff is very hard to test in jest.
Most big corporates have their own inner sourced css components library. So when you get design feedback you wouldn't be directly editing the style in one self contained web application, which is what this demo is assuming.
We actually do support monorepos and it can do multi-file edits.
Wow, this looks really cool!!
Thanks so much!
A lot of people use LLM subscriptions, they don't use API keys. Why devtool devs continue to ignore this? I mean, ok, you have your "pricing" reselling an access to LLM models, that's the only, probably, simple way to monetize it, but it's a bad way in 2025, seriously. Allow me to bring my oauth with claude max, and/or offload whatever you do to my local claude code (or if there's some magic behind orchestration use SDK). And, oops, there's nothing to monetize and the entire thing can be recreated with vibe coding within a few weeks (it's not so much there, let's be honest).
I apologize for the writing style, don't take it personally, just every devtool product I see on HN nowadays fails for this particular reason.
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.
AFAIK, every tool out there that lets you do oauth with your Claude Max plan is doing so with the same copy-pasted client id/secret that are extracted from Claude Code. It's not clear at all that this is above board, and when I asked our Anthropic rep, they encouraged us not to do this.
If there's an official way for 3rd party devs to piggyback on Anthropic plans, someone please tell me how!
fyi sometimes its because anthropic may have disallowed it. oauthing with your plan to bring the anthropic subsidy to non anthropic products is understandably a tricky deal unless you're scaled enough to make it make sense for both sides.
Congrats on the launch. Looks great! Do you envision this being used as the primary IDE or just for quick changes/tweaks while the main development is done on a standard IDE eg VSCode?
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.
and it's not compatible with latest version of react?
> React 19 Memory Optimization Detected React has detected that this is a large page and is removing source information that is necessary for JSX Tool to run. This optimization helps improve performance but prevents JSX Tool from inspecting your React components. You can either navigate to a different page or override this limitation using the proxy setup.
It is. You need to setup the dev server to overcome this limit. That’s why we put that warning there. React 19 limits the number of fiber nodes with source maps to 10k. When you enable the proxy we update it to 1m but we have to do a find replace in the source for this limit, so you have to proxy through us or let our vite plugin transform the js file.
We made this opt in because React is doing this for performance reasons and you might not want us on at all times.
finally! been waiting for someone to take this on.
<3
Sorry, just trying to understand.
Are you saying you invented hot reload? And a dev tools css editor?
I am confused, because the ability to edit code and have the page update instantly exists with Vite, and next.js, and a bunch of other frameworks. It’s janky at times but good enough for most - and your edits are in your repo ready to commit. And browser CSS inspectors are really great. And there’s the React DevTools if you need to see props & component hierarchy.
Can you explain the value add over all these free things we already have?
> Are you saying you invented hot reload?
I'm not saying that, no. We are super dependent upon HMR servers from Vite/Next.
We made the ability to write back from your dev panel to your filesystem and made a JSX inspector. As far as I know these are not things supported by either Next or Vite.
> And browser CSS inspectors are really great
I couldn't agree more. I agree so much that we wanted to make one so that you could do the same to JSX as you can do to HTML.
> Can you explain the value add over all these free things we already have?
You should watch the demo video!
Vue has one of these and the performance is pretty awful. I hope they make performance a priority.
We do our best! Weak maps are a developer's best friend
Pretty cool project! I love to see progress on the UX of how we write and manage code.
My honest feedback to you here is, this isn’t very valuable by itself as a local dev tool. Make it so it can be run targeting a git repository with live preview and deployment to a real environment and you may have something much better!
Take a look at Theia IDE, maybe you could find a bridge to do that?
Good luck on the launch!
Gotta respectfully disagree here but yeah, I definitely understand the remote workflow use case and why some folks want that.
I think if you're building something that is targeting designers that is the way to go.
Thanks for checking it out though!
You seriously don't think anyone develops locally in 2025?
Hey, sorry, I tried to write my feedback with a little more empathy but I guess I should have been upfront to clarify my point.
What I meant to say is, I can't see this competing with the current state of the art as it comes to local development. As for remote development, we are quite lacking there IMO, and this seems to be a great potential candidate to solve that problem.
I do a large portion of my development locally, it's great, I love it. This product is trying to get me to change my workflow there and asking me to do it from the browser only. Why would I work on a browser only if I have a full suite of tools locally, terminals, IDEs, text-editors, rich LSP / plugins / Agents / etc.
Did you watch the demo?
Yes!
Astro does the same, or something similar, but without an extension i think — https://docs.astro.build/en/reference/experimental-flags/chr...
It seems to leverage some official chrome devtools workspaces concept.
Nice! Yeah, I don’t think we’re the only guys out there letting you map back to your file system. I think we’re first and foremost a JSX inspector that lets you locate your line of code but then there’s a bunch of different directions you can go from there —- editing being a big one.
is the ultimate plan to become like a "Cursor for React"?
Sort of. I think we want to leverage the parts of the runtime that Cursor wouldn’t be as good at. I don’t expect to replace Cursor, I expect to be better at a lot of React things that take advantage of the runtime and browser context.
because you're ex YC i feel ok giving some tough love that i dont think this is a good plan because cursor and v0 will eat your lunch if you get any traction, however, happy koding and may you find the thing you were meant to do.
I don’t mind the tough love one bit. Yeah, could happen. Startups just aren’t defensible creatures, especially in the post network effect world of AI. But having spent a bit of time in the world of startups (I worked at YC), I think it’s easy to forget that people build in an incumbent’s space all the time... and yes, usually those startups get killed. But by your logic, Cursor should not exist. We should all be using GitHub copilot. The browser IDE is really a new category so I think it will be somewhat awkward for any incumbent.
To be clear, I fully expect Vercel to launch something and for them to have the best distribution in the world. I don’t think they will ever support Vite or things that aren’t Next but que sera sera.
It is going to be a very competitive market but you still have a chance if you serve the needs of professional React development. Unlike POC and MVP projects by people who are learning React, professional React projects that serve production are very complex. Developers need to deliver features without regression, debug with whatever tools they have to find out root cause and fix the bug without causing regression and more issues. Tight unit tests, integration tests and QA cycles.
I have been using Cursor + Claude (Composer) in production code base with some success. Integrations with live React DevTools in the browser could make UI debugging and iterative development much faster. But you also need to think outside of the box of IDE. It is never about IDE. It is about high quality workflow.
>you still have a chance if you serve the needs of professional React development
That's my entire thesis. I think it's a long long road. But I think you've actually done a great job of pretty much seeing the whole vision.
That is why Playwright might be a critical piece of the puzzle instead of good to have.
I have instructed agent to generate Playwright test from screenshots that will dump API calls to debug and generate mocks to trigger the edge cases bugs. I am sure if jstool is there, it can fix the bug and reload.
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.
If you can build browser automation into jsxtool, perhaps it can replace playwright. If I remember correctly, the guys who developed puppeteer/playwright used to work for chrome devTools or something.
Um, Firefox extension maybe?
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
Interesting that this is now a venture-scale company, according to YC.
Startups aren't supposed to be "venture scale" when they launch. (I don't know what "venture scale" means, but it sounds big.) They're supposed to make something that at least a few people want, and then iterate.
just keep in mind you weren't in the pitch room. I'm old enough now to realize that not everything we see in public is the full story.
It may be all a pipe dream and not pan out, but I bet they pitched a path to more broader optionality. That's all you really need, momentum and optionality.
Right? There are at least 3 years that I don't get impressed by any Launch HN.
How are you planning to acquire customers?
Is this sponsored by yc?
Who are the target audience?
Are the target audience companies or businesses or individuals?
Congratulations
> How are you planning to acquire customers?
We haven't gotten much further than just launching and praying.
> Is this sponsored by yc?
I mean we're a YC portfolio company, so sort of I guess. I used to work at YC, so I suppose YC has been sponsoring me for a while now.
> Who are the target audience?
React developers
> Are the target audience companies or businesses or individuals?
Both, I hope. We definitely went more along the lines of supporting individual developers spiritually but there is no reason it shouldn't work if you have colleagues.
> Congratulations
<3 Thanks so much!