4 ms·

How I built a Real-time Collaborative Editor with Web Sockets, Node.js & Redis

61 points by laktek 16y ago

papachito 16y ago
Demo looks impressive, congrats.
Raphael 16y ago
Right tools for the job indeed.
mohamedaslam 16y ago
Awesome! Keep up the good works!
thilanka 16y ago
Good impressive and nice work. Congratz
jacquesm 16y ago
> V8, on which Node is built, supports only IA-32 and ARM processors. What a pity it doesn't support 64 bit yet, I'd definitely play around with this otherwise.
- papachito 16y ago
  64 bit is supported on Linux http://code.google.com/p/v8/issues/detail?id=330#c7 http://code.google.com/p/v8/issues/detail?id=330#c7
  - jacquesm 16y ago
    They should really update that page then, anybody reading it that plans to deploy on a 64 bit system is going to be turned away.
antirez 16y ago
Is it possible in this context to replace Node.js with Event Machine without any kind of loss of expressiveness, abstraction, performances? Or, in other words, what are the advantages of node compared to an event programming library for another language like Ruby or Python? Since Ruby supports fibers, it should actually be simpler to take the state across events firing, at least in theory, but since I'm everything but a node.js expert I would love to hear your opinion on the matter.
- SamReidHughes 16y ago
  node.js uses Javascript. That means, for example, I don't have to rewrite my code that identifies valid chess moves in two different languages.
  - antirez 16y ago
    this is a good point. But I see node.js is often used in contexts where there is no real sharing of code between the web part and the server part.
- laktek 16y ago
  As I mentioned in the post real bottleneck occurs when it's used with the other supporting libraries (which would be the practical case). Most libraries in Ruby (or Python) are implemented as blocking processes. This defeats the purpose of using an evented programming library. In contrast, most of the Node.js' libraries are written in a non-blocking manner. This may be because of the initial path the eco-system took. Also JavaScript, being naturally event-driven language encourages writing non-blocking code.
  - antirez 16y ago
    Hello laktek, I really agree about the fact that node.js being from the ground up an evented environment got most libraries written in the same paradigm. On the other side I fail seeing how Javascript is a more event driven language compared to Ruby. In the context it's often used (the web browser) it supports callbacks, but not with some special semantic. Just callbacks, anonymous functions. For this point of view I think that languages with coroutines are probably more powerful as event-driven programming languages, because it's possible to save the state across calls in a much more high level way, leading to code resembling a lot erlang code for instance. Thanks!
mattlong 16y ago
The author states that a difference between Realie and Etherpad is that he users Web Sockets for client/server comm. I'm fairly certain that Etherpad uses Web Sockets too. Am I mistaken?
- asolove 16y ago
  Yes, you are. Web Sockets have only been available in Firefox and Chrome in the last few months. Etherpad is written with Comet: http://ejohn.org/blog/etherpad-real-time-editing-with-javascript/ http://ejohn.org/blog/etherpad-real-time-editing-with-javasc...
- aaroniba 16y ago
  Etherpad had 3 modes of transport between client and server: short-polling, long-polling, and streaming, each with varying support for different browser/OS/proxy settings. The client starts the connection with the most widely supported method (short-polling), and then attempts to "upgrade" the connection by testing out faster connection types. I think the messages from client to server always had to do an HTTP post, so we did incur the overhead of all the HTTP headers with each post from client to server, which happened at most twice per second. You can view the client-side JS code for handling these 3 connection types here: http://code.google.com/p/etherpad/source/browse/trunk/infrastructure/net.appjet.ajstdlib/streaming-client.js http://code.google.com/p/etherpad/source/browse/trunk/infras... I didn't write this, but that's my understanding of how it works. You can also get around the overhead of HTTP headers by using a Flash shim, but we never got that to work well through weird proxy configurations and misbehaving ISPs.
swannodette 16y ago
> You may think this is more or less similar to what Etherpad had - yes, it is! Huh he says nothing about implementing operational transform so I can't imagine that this anything like Etherpad at all. > However, on some occasions these two actions needs to be executed concurrently Some occasions? Using diffs? What about conflicts?

61 points by laktek 16y ago

papachito 16y ago

Demo looks impressive, congrats.

Raphael 16y ago

Right tools for the job indeed.

mohamedaslam 16y ago

Awesome! Keep up the good works!

thilanka 16y ago

Good impressive and nice work. Congratz

jacquesm 16y ago

> V8, on which Node is built, supports only IA-32 and ARM processors. What a pity it doesn't support 64 bit yet, I'd definitely play around with this otherwise.

papachito 16y ago
64 bit is supported on Linux http://code.google.com/p/v8/issues/detail?id=330#c7 http://code.google.com/p/v8/issues/detail?id=330#c7
- jacquesm 16y ago
  They should really update that page then, anybody reading it that plans to deploy on a 64 bit system is going to be turned away.

antirez 16y ago

Is it possible in this context to replace Node.js with Event Machine without any kind of loss of expressiveness, abstraction, performances? Or, in other words, what are the advantages of node compared to an event programming library for another language like Ruby or Python? Since Ruby supports fibers, it should actually be simpler to take the state across events firing, at least in theory, but since I'm everything but a node.js expert I would love to hear your opinion on the matter.

SamReidHughes 16y ago
node.js uses Javascript. That means, for example, I don't have to rewrite my code that identifies valid chess moves in two different languages.
- antirez 16y ago
  this is a good point. But I see node.js is often used in contexts where there is no real sharing of code between the web part and the server part.
laktek 16y ago
As I mentioned in the post real bottleneck occurs when it's used with the other supporting libraries (which would be the practical case). Most libraries in Ruby (or Python) are implemented as blocking processes. This defeats the purpose of using an evented programming library. In contrast, most of the Node.js' libraries are written in a non-blocking manner. This may be because of the initial path the eco-system took. Also JavaScript, being naturally event-driven language encourages writing non-blocking code.
- antirez 16y ago
  Hello laktek, I really agree about the fact that node.js being from the ground up an evented environment got most libraries written in the same paradigm. On the other side I fail seeing how Javascript is a more event driven language compared to Ruby. In the context it's often used (the web browser) it supports callbacks, but not with some special semantic. Just callbacks, anonymous functions. For this point of view I think that languages with coroutines are probably more powerful as event-driven programming languages, because it's possible to save the state across calls in a much more high level way, leading to code resembling a lot erlang code for instance. Thanks!

mattlong 16y ago

The author states that a difference between Realie and Etherpad is that he users Web Sockets for client/server comm. I'm fairly certain that Etherpad uses Web Sockets too. Am I mistaken?

asolove 16y ago
Yes, you are. Web Sockets have only been available in Firefox and Chrome in the last few months. Etherpad is written with Comet: http://ejohn.org/blog/etherpad-real-time-editing-with-javascript/ http://ejohn.org/blog/etherpad-real-time-editing-with-javasc...
aaroniba 16y ago
Etherpad had 3 modes of transport between client and server: short-polling, long-polling, and streaming, each with varying support for different browser/OS/proxy settings. The client starts the connection with the most widely supported method (short-polling), and then attempts to "upgrade" the connection by testing out faster connection types. I think the messages from client to server always had to do an HTTP post, so we did incur the overhead of all the HTTP headers with each post from client to server, which happened at most twice per second. You can view the client-side JS code for handling these 3 connection types here: http://code.google.com/p/etherpad/source/browse/trunk/infrastructure/net.appjet.ajstdlib/streaming-client.js http://code.google.com/p/etherpad/source/browse/trunk/infras... I didn't write this, but that's my understanding of how it works. You can also get around the overhead of HTTP headers by using a Flash shim, but we never got that to work well through weird proxy configurations and misbehaving ISPs.

swannodette 16y ago

> You may think this is more or less similar to what Etherpad had - yes, it is! Huh he says nothing about implementing operational transform so I can't imagine that this anything like Etherpad at all. > However, on some occasions these two actions needs to be executed concurrently Some occasions? Using diffs? What about conflicts?