TL;DR: This is a proxy server that routes HTTP requests from a unique subdomain (e.g. http://m7rp3u2ntr9t3xr.browserver.org) to a browser that's visiting browserver.org. The JavaScript in the browser then handles the HTTP response. This is possible thanks to a persistent connection between the browser and browserver.org, via some "websocket-like" protocol.
The title "node.js HTTP server, in your browser" is because the HTTP handler in the client (browser) has a Node-like API, see:
I put browserver together in my free time over the last week. It's still a bit of a toy, but I think it's useful to explore ideas around extending webhooks all the way to the browser, to simplify our increasingly complicated web architectures.
It's already late here in Tokyo, but I'll be up for a bit if anyone wants to chat/brainstorm about approaches like this (and also to make sure the server stays up).
Hey! I am doing something very similar with PageKite (http://pagekite.net/), although the server does not run in a browser.
I've decided to try to get authors of similar tools together on a mailing list to discuss whether we can agree on a common protocol so our clients/servers (connectors/relays, backends/frontends) can be interoperable. Join us: http://mailman.klaki.net/mailman/listinfo/revprotun
I had this idea, too, the killer application is actually demos and talks, I think. The speaker sets up their browser server, asks the audience to hit a URL, and then demonstrates in real time aspects of the system.
It's also a very neat way to bring WebKit Inspector to bear on server style code. Glad you did it! I presume that you have a wildcard subdomain at the DNS level and then some Node parsing magic to correctly proxy. Why subdomains though? Why not just a tag like browserver.com/29adfija02 ?
I find this title rather misleading. There is no node.js HTTP server in your browser. Meaning, you cannot do anything that is part of Node.js in the browser "server"
The browser is still running its original js engine with none of the Node goodies. It merely receives proxied requests, does some stuff to it, then sends it back to the proxy, which returns it to the client.
It merely receives proxied requests, does some stuff to it, then sends it back to the proxy, which returns it to the client.
You just described the majority of the web servers that we web developers deal with. Sure, it's a proxy, but the fact that the machine responding is connected via WebSocket and not a local network doesn't make it any less of a server, in my opinion.
I do get that the idea is that it "just" uses javascript (the server appears to be down, so I'm actually guessing) -- but when such projects already exist, I kind of expected more...
I don't really see why this is special. It's just a websocket connection that happens to show every request made to the server. Your browser is not a server, no matter which way you cut it.
I think there's a ton of unrealized potential in this kind of thinking. Although people will say 'But that was done by X a year ago!' I see that as evidence that this is gaining momentum.
Now, what's the project that will fully take advantage of this kind of thing?
A lot of times it is about coming up with the right terminology and positioning of an idea for it to "take off". This is a really nice approach in that it utilizes concepts/a paradigm we are already comfortable with.
Weinre is a project that, if my understanding of it is correct, leverages the same basic idea. It's used to remotely debug mobile browser issues and also uses Node.
Anyone know if browserver.org is self hosting (i.e. running on some guys desktop/laptop in a browser window)? Site is down at the moment and I'm wondering if this is why.
[+] [-] arturadib|13 years ago|reply
The title "node.js HTTP server, in your browser" is because the HTTP handler in the client (browser) has a Node-like API, see:
https://github.com/jed/browserver-client#example
[+] [-] jedschmidt|13 years ago|reply
[+] [-] bilalhusain|13 years ago|reply
[+] [-] jedschmidt|13 years ago|reply
I put browserver together in my free time over the last week. It's still a bit of a toy, but I think it's useful to explore ideas around extending webhooks all the way to the browser, to simplify our increasingly complicated web architectures.
It's already late here in Tokyo, but I'll be up for a bit if anyone wants to chat/brainstorm about approaches like this (and also to make sure the server stays up).
[+] [-] madrobby|13 years ago|reply
Keep on being awesome. :)
[+] [-] shurane|13 years ago|reply
On a related note, keep at it. I hope you go places.
And where/how did you get the idea?
Things like this make me wonder why I'm not having fun creating neat (and useful!) things.
[+] [-] HerraBRE|13 years ago|reply
I've decided to try to get authors of similar tools together on a mailing list to discuss whether we can agree on a common protocol so our clients/servers (connectors/relays, backends/frontends) can be interoperable. Join us: http://mailman.klaki.net/mailman/listinfo/revprotun
[+] [-] javajosh|13 years ago|reply
It's also a very neat way to bring WebKit Inspector to bear on server style code. Glad you did it! I presume that you have a wildcard subdomain at the DNS level and then some Node parsing magic to correctly proxy. Why subdomains though? Why not just a tag like browserver.com/29adfija02 ?
[+] [-] wamatt|13 years ago|reply
How is it different, in practice, from say running a Node.JS on localhost and using localtunnel?
[+] [-] quarterto|13 years ago|reply
[+] [-] brettbergeron|13 years ago|reply
[+] [-] ericz|13 years ago|reply
The browser is still running its original js engine with none of the Node goodies. It merely receives proxied requests, does some stuff to it, then sends it back to the proxy, which returns it to the client.
[+] [-] jedschmidt|13 years ago|reply
[+] [-] arturadib|13 years ago|reply
https://github.com/jed/browserver-client#example
[+] [-] arunoda|13 years ago|reply
You just listen for a URL and forward it to the browser with socket.io (Pusher, Pubnub are some commercial services for this)
If I can change some content in your webpage by just curling localhost, I can judge the title you put :)
[+] [-] e12e|13 years ago|reply
Apparently there's a newer variation at:
and of course there's Opera's Unity.I do get that the idea is that it "just" uses javascript (the server appears to be down, so I'm actually guessing) -- but when such projects already exist, I kind of expected more...
[+] [-] shurane|13 years ago|reply
[+] [-] jedschmidt|13 years ago|reply
[+] [-] aba_sababa|13 years ago|reply
[+] [-] andrewmunsell|13 years ago|reply
[+] [-] state|13 years ago|reply
Now, what's the project that will fully take advantage of this kind of thing?
[+] [-] shaunxcode|13 years ago|reply
[+] [-] Xurinos|13 years ago|reply
[+] [-] mcantelon|13 years ago|reply
https://github.com/apache/incubator-cordova-weinre
http://www.youtube.com/watch?v=4nL6xey13fE
[+] [-] VikingCoder|13 years ago|reply
http://www.webrtc.org/
That said, this is cool!
[+] [-] jmspring|13 years ago|reply
[+] [-] quarterto|13 years ago|reply
[+] [-] quarterto|13 years ago|reply
[+] [-] Kilimanjaro|13 years ago|reply
Change some HTML in that text area and refresh automatically in all listeners.
That would be an interesting toy to play for a while.
[+] [-] sehrope|13 years ago|reply
[+] [-] jedschmidt|13 years ago|reply
[+] [-] mgurlitz|13 years ago|reply
[+] [-] jedschmidt|13 years ago|reply
[+] [-] alan_cx|13 years ago|reply
Loading the app... If this message doesn't go away within 10 seconds, it means that the server crashed under heavy load. Please refresh mercilessly.
:)
[+] [-] mislav|13 years ago|reply
[+] [-] rip_kirby|13 years ago|reply
[+] [-] sharps_xp|13 years ago|reply
[+] [-] debacle|13 years ago|reply
It was a good 15 minutes, though.
[+] [-] tinco|13 years ago|reply
[+] [-] shawndumas|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] bestest|13 years ago|reply