Hacker News new | past | comments | ask | show | jobs | submit | more jedschmidt's comments login 

    new Option("<div>in the browser, yes.</div>").innerHTML


Oh I like this. I was messing with a similar tactic appending a textNode to an HTML element but this is much more elegant.


The text node approach is cross-browser, whereas I don't think this works on oldIE.


I just tried this and it doesn't seem to escape " to &quot;.


yes! awesome snippit :)


Thank you for explaining this much better than I did!


i get a gateway error


    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.


Indeed, this isn't entirely original, and I know services like this exist. To me, this is what PUSHER's API _should_ have been.


Good point. I'll get to githubbing the browserver.org site itself now.


Okay, it's here:

https://github.com/jed/browserver.org


Ha, tinco beat you to that joke. The server is the smallest instance that Joyent offers right now... hopefully it'll hang in there during the HN rush.


Would that happen to be one of the free http://no.de instances? Which if I recall correctly come with 128mb ram on their custom solaris servers... I always wondered what kind of load those small configurations using NodeJS while handling something non-trivial could do.

Could you share some traffic/load numbers from getting HN'ed?


Hard to tell right now... I started at Joyent's smallest node.js offering (1GB) and then ramped it up to 8GB when the load hit. The server is crashing a lot, but it's not very easy for me to debug right now.

Let me get back to you once the dust settles, deal?


Wow must of took a real hammering from being on the number spot. Goodluck!


Hey all,

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).


I'm slightly disappointed that it's implemented in more than 140 bytes.

Keep on being awesome. :)


Simple statement: stop being so cool.

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.


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 chose hosts over paths for disambiguation because I want the request passed to the proxy to be as close as possible to that passed to the browser.


Also you get same-origin protection, FWIW.


This does sound sort of interesting, but after thinking about it I don't get why this is cool. Can someone explain a practical use case?

How is it different, in practice, from say running a Node.JS on localhost and using localtunnel?


Simple question: how the fuck?


Basically a web browser reaches the Node HTTP server and gets assigned a throwaway hostname on the Node server. The browser and the server have a bidirectional connection (probably WebSocket via Socket.io or something). The throwaway hostname can be queried, via an HTTP API, and will, upon request, query the web browser through the bidirectional connection then will relay the results back.


Yeah, it's not quite a HTTP server, more of an API-driven backend to a HTTP server. Still neat.


mind = blown


Looks great, Travis.

One thing: you should consider building this on jed/dynamo-client[1] instead of jed/dynamo. I refactored the former out of the latter last week, adding exponential back-off retry and the ability to specify custom hosts for better testability. Also, I'll be refactoring jed/dynamo myself in the near future, which will introduce breaking some API changes.

    [1] https://github.com/jed/dynamo-client


Thanks Jed, I was unaware of dynamo-client ... I'll make sure to go off of that (exponential back off retry sounds awesome).


I recently built SAJAK (Simple Authenticated JSON API Kit) to suit my own needs: https://github.com/jed/sajak


Good name.


Here's a more accurate tl;dr of their JavaScript style guide:

    $ curl -I https://github.com/styleguide/javascript

    HTTP/1.1 301 Moved Permanently
    Location: https://github.com/styleguide/coffeescript


I think it's neat that people can create languages that compile to JavaScript so they can work in an environment that's more their style, but it really irks me when they try to say those languages ARE JavaScript.

This isn't a debate as to whether or not CoffeeScript is better, easier, cleaner, etc. It's a simple A does not equal B statement, and it's starting to remind me of the way my boss says I'm "good at Java".


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: