okay, after working in this for a couple minutes I found it to be AWESOME!!! great job guys. Obviously, there's a ton of people on it right now, and the proverbial dicks just pasting 10101 all over to annoy, but in a team i could see how this would be really awesome. While working on it there was a short minute where the dicks let off and i really got to see how great this can be for teaming up to iteractively write code.
Nitpick: It seems impossible to scroll down and read the stuff below the actual editor (at least in Chrome), since the editor keeps auto-scrolling me back up to itself whenever new data comes in.
Haven't looked into the code/docs deeply, yet, but would love to know if it can be customized to send data to one's own backend service for private implementations. Love the editor. Also had a few great laughs trying to use it alongside so many other people.
We built it as a Firebase app, but we're releasing it as open source and are looking forward to seeing what the community does with it. :-) All of the OT work happens client-side, so it's certainly possible to adapt it to other backends.
Additionally, a lot of the OT code is based on ot.js[1], a fantastic open source OT implementation by Tim Baumann. He has a node.js backend as well as Haskell and Python. Of course then you have to run the server code somewhere and figure out how to persist the documents, etc. :-) Definitely worth checking out though.
Cool. I am going to check this out. I was planning to work on a document site like github but for non technical people (http://www.rubberdocky.com), but have put that on the back-burner for now. One of the projects I recently came across that I thought looked awesome was Substance (http://www.substance.io). I like the idea of collaborating on documents in a way like github but only more accessibly for anyone.
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.
Browsers have debuggers, which allow users to set breakpoints and inject/run arbitrary code in the context of some function. (At least Chrome allows that, not sure about others.)
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!
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 to get all of the other goodies that Firebase provides, like the automatic scaling, Forge debugger, declarative security, etc.
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?
Most every Etherpad implementation I've seen is pretty much a direct copy of what Etherpad was. I have no idea if this is inherent to the Etherpad source, but it sure seems it. The entire point of Firepad is that you can use it for much more custom use cases, like Socrates: http://socrates.io — no crappy word processing UI, or any of that stuff. Totally custom and easy to do.
Would be nice if each user had their own cursor/state and different users could modify different parts of the doc at the same time without causing crazy to happen.
Everyone does have their own cursor state and can edit the document separately (even in offline mode). People are testing the limits of it right now though, so you're probably seeing a fair amount of "select all" + "delete" and other annoying behavior.
If you want to try it without other people messing with it. Click the "Private Firepad" link in the upper right corner.
This inspired me to create a simple page where people can update their status in real-time. It's similar to the firepad.io text editor, except you can only edit your own status and not that of others.
I'm biased, since I'm a Firebase dev, but honestly, Firebase is great for solving /all kinds/ of use cases. :-)
We've had people build everything from emergency response simulations synchronized across multiple devices to iOS apps for grandparents to read books with their grandkids over long distances.
Firebase is great any time you need real-time updates, collaboration, or you just want to get something up and running without having to spin up your own servers.
I definitely can see a use case for this if it had some type of integration with MS word.
Unfortunately I'm currently stuck working for the big corporation, and we have so many meetings reviewing documents, etc over fairly large teleconferences across the world-- so not face to face meetings. Currently, usually only one person drives the edits in MS Word and screenshares with the group via a WebEx or LiveMeeting... if there could be some sort integration with MS Word so multiple people could edit at the same time and view the same thing, there would be no need for the LiveMeeting/WebEx screenshare and the collaboration would be much more seamless. Would remind me of a SubEthaEdit mashed with MS Word.
Can you provide more detail? Here or firepad@firebase.com or as a github issue? From the screenshot it's not immediately obvious to me what went wrong.
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!
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.
Firepad will eventually support rich-text copy/paste and import/export as HTML (export is actually already supported through the API, but not exposed through the existing UI), as well as lists, paragraph indent, and all of the other features that you'd want. They just didn't make it in for the v1 release. :-)
As for similar projects that are already more HTML-friendly, maybe check out Etherpad[1]? It has HTML import / export, though I haven't tested it out.
We are building a real time HTML synchronization engine at wikidocs.com (using a custom OT engine). It's still work in progress, but you can already try it out - if you fire up the inspector and manipulate the DOM, your changes will be synchronized automatically.
Perhaps because hackpad isn't [edit: as gung-ho about being] open source (if they are at all)? I'm sure there are other commercial offerings too... like yours!
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'.
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 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).
Again awesome app!!