The front-end is a simply client of a remote debugging server hosted by the browser. This is exactly how the built-in browser DevTools are working in modern browser like Chrome, Firefox and Safari. Vorlon.js is built on node.js and is using socket.io to manage it’s connections to the browsers and the front-end is simply communicating to the central (local) server that provides an aggregated view of the browser information. Vorlon.js doesn’t bring anything new to the table I’ve been reading the announcement blog-post of vorlon.js a few few times to wrap my mind around the purpose of the project, and I get that the point of the project is a “An open source, extensible, platform-agnostic tool for remotely debugging and testing your JavaScript.”, but I simply don’t understand why the team has chosen an approach that includes to re-invent (as in re-implement) much of the logic, our community have spent years on building and perfecting. To me, this particular front-end work seems completely unnecessary as a front-end for this kinda of functionality already exists - and has for years. I’ve been following the vorlon.js project for a while now, and recently I’ve started to notice a big amount of work being put into building a “DOM Explorer” and other parts of “DevTools-like front-end”, which trigger this Why make own DOM Explorer over Firefox or Chrome DevTools? We already have it :)- Kenneth Auchenberg June 24, 2015

I might be completely wrong in my criticism.

Preface: This is quite an opinionated post, and everything here is said without have had a chat with the team, and is purely based upon the observations I’ve made since the announcement and by following the project.

This post is a follow-up discussion of brief Twitter thread between and where I asked into the reasoning behind building Vorlon.js.

Rerunning scripts in ghostlab