Comment by gbadman | Hacker News Reader

Comment by gbadman | Hacker News Reader

Parent Full thread

How about opening up a browser-based API for existing in-browser IDE-like environments to leverage the debugging tools that are already present?

What I am talking about is instead of recreating jsFiddle in the dev tools, how about letting jsFiddle (with appropriate user confirmation) control the dev tools?

As the creator of Plunker (http://beta.plnkr.co/edit/e5iLyQ?p=preview), I would love to be able to leverage the environment that has already been created to allow adding breakpoints and inspecting of running code. Since Plunker already has live-previewing and a working multi-file editing interface, it would be really amazing to be able to take it to the next level.

Shameless plug: If you've never heard of Plunker, check it out. For free you get live-reload of previews, transparent compilation (and sourcemapping) of stuff like Coffee-Script, Typescript, Stylus, etc.., real-time collaboration on the same code, live js/css linting and much more! Also, it is open-source (http://github.com/filearts/).

Isn't the first paragraph exactly about that?

Hi Paul,

What I understood from your article is that you're mostly exploring 1) the possibility of opening up the dev tools to locally-installed applications like SublimeText2; and 2) the integration of jsFiddle-like apps within DevTools.

Please correct me if I misunderstood.

What I'm asking about is creating an in-browser API for a website to interact with the dev tools. Obviously, this would require a very thorough review of the risks of having such an API from a security perspective (and how users can opt-in in a transparent and well-controlled manner). That being said, I am still hoping!

If this is already in the books, then Hooray! I can't wait to start experimenting.

I hope I didn't come across poorly, because I really appreciate all the work you've been doing!

So - Firefox exposes a tcp-based protocol (not enabled by default. The user will need to go to a special tool to start the server). It will expose feature like adding break points, exploring the DOM and the CSS rules, and editing content (CSS/HTML/JS).

So external tools can connect to Firefox. But this protocol is not accessible from a page. But we could imagine using a websocket instead of a normal tcp socket, and let the web page connect to ws://localhost.

Paul, very cool indeed.

Stretch goal: How about having an in-browser API that could create such a websocket?

That would open some interesting possibilities in terms of remote debugging by piping socket traffic over another socket/WebRTC datachannel as well as allowing websites to interact with the debugger.

Allowing websites to interact with the Debugger API is something we would like to do, but, as you note, the security implications require much more thought to get it right.

Reply on news.ycombinator.com