Hacker News Reader

Comment by chewxy | Hacker News Reader

So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that this is rather silly?

If you want a client-side app that uses TCP, why must you do it over the web? The appeal of write-once-run-everywhere?

It's not TCP over HTTP, that would require a TCP stack. It's the io bytestream from a specific TCP connection, shuttled over HTTP.

It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.

On the contrary, this sort of things allows us to write clients in a uniform way. It will be nice to be able to debug the redis client in a jsfiddle. :)

By this argument, "uniformity" means we should then port the linux kernel to javascript so that we can debug it in jsfiddle.

Down that path lies madness.

What's wrong with writing a kernel in JavaScript? This would actually be quite valuable as a pedagogical tool.

It uses Websockets, which are only HTTP for the handshake: the rest of the connection is just a TCP stream.

So it's really more like a NAT bridge.

it's not about pure tcp, as i get it - it allows you communicate from browser directly (via webtcp server as a bridge) with any servers such as redis, mongodb, rabbitmq and so on.

WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp

Well, you didn't read the post apparently and only a title :(

I actually did. I was quite interested in the redis example. For about 10 seconds, which I then went "wtf is this useful for?"

We really need to stop reinventing the wheel

What would you use to achieve the same thing with Redis?

The XY Problem http://www.perlmonks.org/index.pl?node_id=542341

I wouldn't. I'd make a HTTP call to the server, and let the server handle it. (i.e. your "what's so different from the backend method")?

Yep, and i wrote about differences to such approach in the post. Don't get me wrong, this is definitely a hack, I'm not saying people should stop doing it the old way.

Likewise. While I appreciate the concept of a bridge (I'm a strong believer that the fastest app is the app that does practically nothing at all, and I can see the benefit of using a TCP-bridge like thing to make something faster), I just think we should not be reinventing the wheel.

That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)

REST is far more appropriate for databases.

Pub/sub is well catered for by socket.io (websockets).

This glue belongs on the server.

If I did need arbitrary TCP connections my first thought would be a websocket proxy...

Reply on news.ycombinator.com