51–60 of 65 posts
Looks interesting. Might try it for the incoming interview sessions. A big drawback for me is that I can't use my browser's back button after opening the page because the history is flooded.
I think there's a bug with text writing over eachother when 2 people are typing: http://imgur.com/1IvMccd (You can see how my bold line of text was interrupted by someone else.)
People are certainly allowed to write over each other (e.g click in the middle of your sentence and write something). If that's not what happened, let me know!
Earlier quoted context omitted.
Won't people realize that doing that would detract from the experience of other users? Haha, just kidding! Moved everything into a closure. Thanks for suggesting it.
Sure, now they'll need to do `cm = document.body.getElementsByClassName("CodeMirror")[0].CodeMirror` first. (I.e. it's client-side, you can't prevent people from doing whatever they want.)
Obviously you can't be stopped from editing the contents of the editing area, so if it works by simply checking for your updates to the editor then you can't stop it.
And yes, I'm quite sure private pads might be of use in certain situations.
Earlier quoted context omitted.
Sure, now they'll need to do `cm = document.body.getElementsByClassName("CodeMirror")[0].CodeMirror` first. (I.e. it's client-side, you can't prevent people from doing whatever they want.)
Well, if you don't attach the Firepad instance to the element and it's in a closure I'm pretty sure you couldn't modify it. I'd love to be corrected if this is incorrect. Obviously you can't be stopped from editing the contents of the editing area, so if it works by simply checking for your updates to the editor then you can't stop it.
In non-demo scenarios, you'd have authentication and security rules set up to prevent this sort of abuse / trolling / etc.
The main reason I bothered adding the closure was so people wouldn't copy/paste the code snippet from the HN post and have it work. :-)
Earlier quoted context omitted.
That's a good question, and I don't have an answer for you. However, since I've heard how awesome Firebase is, I'm wondering what you offer over Etherpad. After Google acquired it and open sourced the engine, lots of other websites have sprung up that use it. I'm sure there are great reasons to use your tool rather than an Etherpad-based one, so it'd be interesting to hear them! http://etherpad.org/ http://piratepad.…
The main reason you might want to use Firepad instead of Etherpad is if you don't want to run the server-side piece of Etherpad. For example, if you're stack is different than theirs it might be a pain to set up a special server environment just for the collaboration portion of your app. Firepad is fully client-side code, so there's no server software for you to set up. The other big reason you might use Firepad is t…
Earlier quoted context omitted.
The main reason you might want to use Firepad instead of Etherpad is if you don't want to run the server-side piece of Etherpad. For example, if you're stack is different than theirs it might be a pain to set up a special server environment just for the collaboration portion of your app. Firepad is fully client-side code, so there's no server software for you to set up. The other big reason you might use Firepad is t…
So, when you say it's "fully client-side code" -- what that looks to me to mean is not that it's not talking to a server somewhere, but that it's talking to Firebase's servers rather than my servers. Is that correct?
Earlier quoted context omitted.
Only slightly, though; I mean, Firebase is built on a fully-proprietary platform (Firebase).
I haven't looked at the code so I can't give you too much of a hard time (have you looked at it?) but the Firebase team might take issue with your use of the word 'slightly'. https://news.ycombinator.com/item?id=5519094 > All of the OT work happens client-side, so it's certainly > possible to adapt it to other backends.
The main thing that is difficult about building something similar to Firepad would be building the scalable distributed backend: there are no open source projects that I know of that provide that functionality. That is the value add of Firepad: the open source code is just some glue that you can find from other projects (including Etherpad, which is open source with both rich text and OT).
The thing that actually makes this interesting is the proprietary scalable synchronization backend from Firebase. That is interesting, no denial from me on that front: except for some issues with trusting the clients (pointed out in my other comment), this seems like a great and simple way for developers to rapidly get access to this collaborative text editing functionality for their applications. The open source parts, though, are not what is compelling.
To take some concrete examples: ShareJS is a strong implementation of OT (the guy is one of the people who had worked on Wave), but the backend they provide is less-than-stellar, based on fairly centralized storage into a small handful of backends, and no real attempt at supporting scalable front-end server endpoints (so, you have to have everyone connect to a single machine to act as the single-threaded mediator). Etherpad-lite is based on a similar architecture; you can shard these solutions on the document, but it just doesn't hold up in the same way Firebase does vertically.
Looking at this then from an alternative direction: one can imagine just taking the FirebaseAdapter from Firepad and wiring it into the backend of ShareJS. This isn't much work, and would probably be more useful than Firepad's current stack that is tied to the text editor: in addition to being able to use any of a number of text editors people have wired over ShareJS, ShareJS also supports arbitrary JSON document OT, allowing you to build systems that are closer in functionality to Wave (where people were using OT on the program state of things like chess games).
Earlier quoted context omitted.
I haven't looked at the code so I can't give you too much of a hard time (have you looked at it?) but the Firebase team might take issue with your use of the word 'slightly'. https://news.ycombinator.com/item?id=5519094 > All of the OT work happens client-side, so it's certainly > possible to adapt it to other backends.
I have looked at the code (and had looked at the code before leaving that comment). Please understand that the OT backend they are using is just something they got from someone else, so it isn't really interesting that the OT backend is open source. In essence, they just took an off-the-shelf open-source OT implementation and connected it to an off-the-shelf open-source HTML+JavaScript rich text editor. The main thin…
And we'd love to see integrations with ShareJS as well as other editors besides CodeMirror.
Earlier quoted context omitted.
What features would you like to see implemented next in Firepad?
That's a good question, and I don't have an answer for you. However, since I've heard how awesome Firebase is, I'm wondering what you offer over Etherpad. After Google acquired it and open sourced the engine, lots of other websites have sprung up that use it. I'm sure there are great reasons to use your tool rather than an Etherpad-based one, so it'd be interesting to hear them! http://etherpad.org/ http://piratepad.…