[HN Gopher] Launch HN: JSX Tool (YC F25) - A Browser Dev-Panel I...
___________________________________________________________________
Launch HN: JSX Tool (YC F25) - A Browser Dev-Panel IDE for React
Hi HN, We're Jamie & Dan, building JSX Tool (https://jsxtool.com) a
new inspector/dev panel IDE that allows you to navigate to any line
of your React project's JSX with just a click and a command click
to explore your render stack. Demo video:
https://www.youtube.com/watch?v=JIIXvN7vhrs I've been writing
React code for nearly a decade. Since I first saw source maps in
the days of Babel and Redux, I've always wanted to be able to edit
my code from the source maps. I've also always wanted to be able to
inspect my JSX like it was HTML. Last year, I found my first real
use of AI was taking ad-hoc CSS changes in the Chrome element
inspector, pasting them into ChatGPT, and asking for the equivalent
in Tailwind. I'd then paste those changes into my React TSX files.
I wanted to streamline this process but came to the conclusion that
to do so I needed to build a JSX inspector. I had to write a custom
AST parser to create a mapping between the JSX and HTML. So I
hacked on an inspector for a couple of months that connected JSX to
the DOM in both directions. The next feature was adding a CSS
editor, like the one in the browser inspectors but for JSX. Unlike
styling a piece of HTML I decided that any in memory style edits to
a React fiber should be globally applied, as if you had tweaked
that line of code in your codebase. Finally, I was able to add the
two AI features I really wanted: (1) prompt for in-memory styles
for when I was pixel tweaking, and (2) save those temporary changes
back to my codebase in the convention of the codebase I was working
in. To accomplish talking to the filesystem from the Chrome
extension I built a little local server that mounts from the root
of your project and allows the extension to send file-system
commands back to your project root. We named this the "Dev Server".
(Note: You can fully use us as a JSX inspector without this server
installed.) After all that, I found that to convert myself as a
user I needed it to be a pretty fully functional IDE. I needed vim
bindings, I needed a typechecker, I needed auto-complete, I needed
a linter, I needed code search and I needed a proper file explorer.
Fortunately we were able to take advantage of the dev-server
architecture we had stumbled onto in order to add an LSP server and
Rip Grep. At this point, after months of dog fooding, I use JSX
Tool for almost all of my website edits. We're still rough around
the edges for mobile but we're working on that. All of the IDE
stuff not involving AI is free and works fine without AI. We let
you get a taste of the prompting stuff for free but apply some rate
limits. The extension itself is not open source but the dev server
with the LSP is. It's a great foundation if you want to build any
sort of in-browser IDE and it's nearly React agnostic. Building the
dev server was a big undertaking so I'd love to see someone fork it
and find value in it. In the future we want to start adding things
that we are in a position to take advantage of over something like
Cursor, such as letting AI give you code suggestions for runtime
exceptions or work with the network logs. We think that the
convenience of having your IDE in the dev panel gives us a leg up
in convenience and workflow context. Anyway, regardless of how you
feel about AI coding, I wanted to make something that was useful
with or without AI. We'd love it if you gave it a spin and we want
to share anything we can about the technical side of the product
that you might find interesting.
Author : jsunderland323
Score : 63 points
Date : 2025-11-12 17:43 UTC (5 hours ago)
| imvetri wrote:
| 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
| jsunderland323 wrote:
| > 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!
| cadamsdotcom wrote:
| 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?
| jsunderland323 wrote:
| > 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!
| tnolet wrote:
| Interesting that this is now a venture-scale company, according
| to YC.
| brazukadev wrote:
| Right? There are at least 3 years that I don't get impressed by
| any Launch HN.
| apsurd wrote:
| 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.
| hmokiguess wrote:
| 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!
| jsunderland323 wrote:
| 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!
| hungryhobbit wrote:
| You seriously don't think anyone develops locally in 2025?
| hmokiguess wrote:
| 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.
| jsunderland323 wrote:
| Did you watch the demo?
| hmokiguess wrote:
| Yes!
| ARussell wrote:
| 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?
| jsunderland323 wrote:
| 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!
| hungryhobbit wrote:
| 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!
| jsunderland323 wrote:
| 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!
| whatamidoingyo wrote:
| 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!
| jsunderland323 wrote:
| 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.
| whatamidoingyo wrote:
| Oooh! Great!
|
| I haven't really been developing with React recently, but
| will definitely check this out!
| chrisweekly wrote:
| 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.
| jsunderland323 wrote:
| 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
| apsurd wrote:
| 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.
| jsunderland323 wrote:
| 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.
| swyx wrote:
| is the ultimate plan to become like a "Cursor for React"?
| jsunderland323 wrote:
| 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.
| swyx wrote:
| 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.
| jsunderland323 wrote:
| 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.
| ontouchstart wrote:
| 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.
| jsunderland323 wrote:
| >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.
| ontouchstart wrote:
| 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.
| jsunderland323 wrote:
| 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.
| ontouchstart wrote:
| 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.
| joshribakoff wrote:
| 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.
| jsunderland323 wrote:
| 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.
| ontouchstart wrote:
| Just a thought. Can you automate live UI development in your
| platform with Playwright? That will make agent integration
| easier.
| jsunderland323 wrote:
| 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
| ontouchstart wrote:
| I guess you can at least try to use Playwright for test
| coverage. This stuff is very hard to test in jest.
| marcelr wrote:
| finally! been waiting for someone to take this on.
| jsunderland323 wrote:
| <3
| cyberdrunk2 wrote:
| 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.
| jsunderland323 wrote:
| 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.
| jsunderland323 wrote:
| We made this opt in because React is doing this for
| performance reasons and you might not want us on at all
| times.
| catchmeifyoucan wrote:
| 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.
| jsunderland323 wrote:
| 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.
| zaksingh wrote:
| 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.
| jsunderland323 wrote:
| 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!
| leobuskin wrote:
| 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.
| jsunderland323 wrote:
| 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!
| leobuskin wrote:
| 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?
| jsunderland323 wrote:
| 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.
| swyx wrote:
| 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.
| Pufferbo wrote:
| Um, Firefox extension maybe?
| jsunderland323 wrote:
| 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.
| dahyman wrote:
| Pufferbo, my friend. Thank you for writing this comment. This
| is the kind of feedback we need.
|
| -Dan
___________________________________________________________________
(page generated 2025-11-12 23:00 UTC)