ShareJS Roadmap

[Nelson Silva]

Hi,

I'd like to start by congratulating Joseph for a wonderful and simple OT project. Coming from Apache Wave it is a relief to find such simplicity in ShareJS's approach.

I would like however to understand the project's roadmap. Both this group and the GitHub repo have shown little activity lately and I'd like to understand what it means...

The Rizzoma guys have a rich text model as well as a wave model (blips, renderers, etc...) and I would really like to see it properly integrated in ShareJS's codebase. Perhap's a plugin model is in order to allow external contributions to ShareJS.

I would also love to hear from the community about new and interesting projects based on ShareJS. An Etherpad-lite clone using ShareJS would be nice, similar to MarkdownR but with cursor position metadata, participants, etc...

but a rich editor built on a general model<>view mapping with renderers/doodads would really bring ShareJS to a whole new level.

I understand that we developers need to earn a living and if we eventually get a contract to build on ShareJS we'll gladly donate to the project to keep it up and running!

In the meantime I'd just like to understand what the project's state is regarding its adoption and roadmap.

Thanks!

[Henri Bergius]

Hi,

On Thu, Apr 12, 2012 at 12:00 PM, Nelson Silva <nelson...@gmail.com> wrote:
> The Rizzoma guys have a rich text model as well as a wave model (blips,
> renderers, etc...) and I would really like to see it properly integrated in
> ShareJS's codebase.

<snip>

> but a rich editor built on a general model<>view mapping with
> renderers/doodads would really bring ShareJS to a whole new level.

I'm interested in doing this for Hallo
(http://bergie.github.com/hallo/) and Create (http://createjs.org/),
but haven't had time to properly dig into the Rizzoma code yet. And
obviously the Russian code comments don't help ;-)

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Jabber: henri....@gmail.com
Microblogs: @bergie

[Joseph Gentle]

On Thu, Apr 12, 2012 at 8:00 PM, Nelson Silva <nelson...@gmail.com> wrote:
> Hi,
>
> I'd like to start by congratulating Joseph for a wonderful and simple OT
> project. Coming from Apache Wave it is a relief to find such simplicity in
> ShareJS's approach.

Thanks!

> I would like however to understand the project's roadmap. Both this group
> and the GitHub repo have shown little activity lately and I'd like to
> understand what it means...

It means... I've got a bad habit of feeling obligated / busy / guilty
about something and then disappearing from sharejs for a month or two
at a stretch. A few months ago I took on a teaching job, and I've been
busy.

The obvious next thing that I've been talking about for ages is
getting proper connection status stuff in sharejs (who else is
connected and cursor positions and stuff). That should be pretty easy,
but it just needs time. And most of my little coding time has been
going into making games lately. Which is a long, roundabout way of
saying that if someone wants to take a stab at it you're more than
welcome.

Maybe everyone else is happy on this front, but most of the work I've
done lately on sharejs has gone into reinventing the wheel (pick a
communication stream, authentication, DB, etc) which has nothing to do
with the problem I was trying to solve in the first place (OT). I
suspect there's a nicer architecture somewhere where sharejs provides
a few types that do OT (receiving ops, sending ops and updating a
document in the process). Then its up to the application to send the
ops between client & server.

-J

[Nelson Silva]

Hi,

I understand the "feeling obligated" part.. taking something from a concept to a fully working solution involves lots of "less interesting" stuff to be done ... and I tend to feel the same way you do.

But since the concept of "interesting" varies from person to person I really hope people out there contribute back to the project with all the missing bits.

However there's still a very interesting problem to solve... annotations.

Like the rizzoma guys have found during their rich text model development this is a complex problem and they where able to come up with a nice solution for it.

Still it would be great to have a generic annotation system in ShareJS, one that was actually part of the project.

With this is place i would like to suggest a step further... use ShareJS with Etherpad Lite :P

If you look at etherpad (which you probably have) they have support for annotations. Probably with some sort changeset format mapping we should be able to plug ShareJS in there.

Basically they inherited the etherpad OT but it seems they're not very familiar with it so having a simpler, well understood and tested approach could really make a difference.... 

[Dominic Tarr]

It seems like this email is a reply?

but I didn't receive an original message through the mailing list.

what are annotations, is it a way to attribute edits to authors?

[Nelson Silva]

Annotations are metadata associated with a range. This allows adding support for stuff like user selection or styles.

[Vladimir Kobzev]

I think we can discuss possible way of shareJS development in free way and on the first step try to determine the priorities. 

Something like we made for rizzoma project http://rizzoma.com/topic/53fa7872b00a548ba72bba73f9ea5060/ Actually it was idea from user:)

But I think we don't have to determine fixed deadlines.

What do you think?

2012/4/21 Nelson Silva <nelson...@gmail.com>

[Anton Paramonov]

Annotations served in GW as a main way to implement text styles. Custom defined styles can be implemented without annotations. Selection can be implemented as a simple exchange of selected ranges from all of the clients without messing it with styling.

Are there any other applications for  annotations?

OT based RTF-editor and text exchange is quite utilitarian components and should be handled with API for integration in other websites and applications far from direct annotation management by the programmer.

Are annotations so valued to be implemented as a general purpose tool?

2012/4/21 Nelson Silva <nelson...@gmail.com>

[Nelson Silva]

Annotation in GW server for more than styles. It was used to identify the title of the wave, add link info and set the language for the content.

We've also used them for marking preprocessed content in our Robot. It parsed blips and "tagged" TODOs, Topics, Assignments, etc ....all using annotations.

The question here is not if it is possible to do all these things without annotations but that it is possible to do all these with them!

It would be best to combine efforts and create annotation support than to have separate effort to add rich text, selection, etc.... 

Just my 2c

[Kai Chang]

Can the JSON OT not model metadata? Seems like you can do many of these things already.

[Anton Paramonov]

One thing that fits all usually doesn't fit every specific purpose :) However I'd be glad to see OT for annotations, or at least API for that  :)

2012/4/23 Nelson Silva <nelson...@gmail.com>

[Dominic Tarr]

I was gonna mention the json ot.

what is it that annotations has that json doesn't.

are annotations attached to a particular part of the text and move with inserts?

[Nelson Silva]

Since annotations are associated with a range these have to be updated according to any applied op. Like the Rizzoma guys have found out it is not trivial since you have to update the annotations to reflect any changes.

Also you need to setup rules for new inserts on the boundaries of an annotation. Imagine I have "this is bold text" and an annotation that says [8,12] = ["style/bold"] thus assigning style bold to the range 8-12, what should happen if a user adds "er" at pos 12 ? The expected behaviour would be for the annotation to be updated to 8-14 thus annotations should be inherited from the left.

I'm not looking for a silver bullet here and I know it won't fit every specific purpose. Apache Wave calls them annotations, EtherPad calls them attributes and we need something like it.

We could use the Rizzoma model which apparently is something like this:

{
    text: "This is the editor",
    format: {
      bold: false
    }
 }
We could just change "format" to "attributes" and we have almost what I'm looking for but I'd like to see it as part of ShareJS's core...

[Juan Bernabó]

Nelson,

This would be just a new Type for shareJS, so probably it's not required to touch the core of ShareJS but to add a new type. Right?

Juan.

[Anton Paramonov]

Well, Rizzoma model works well for text styling but it lacks some neat wrapping, I mean an API and some set of classes to hide necessary  OT operations, structures and precondition. It is just a solution of RTF editor data model and some parts of that puzzle are left in editor code (like style inheritance or Undo/Redo).

I think that this is something more then core of ShareJS and JSON OT. So... probably it would be better to define an extension for ShareJS since Rizzoma model was built completely on ShareJS features with no changes in the ShareJS core. 

What do you think?

2012/4/23 Nelson Silva <nelson...@gmail.com>

[Nelson Silva]

I totally agree. I just wanted to keep discussion topics separate. I've posted "Extract OT types from ShareJS" to spawn discussion about ShareJS's modularization.

I believe we should promote ShareJS to its own GitHub account and use it to store all related modules. All the ACE, CodeMirror, Halo stuff that has been in development should be moved to separate projects along with all other types that build on core types (text and JSON).

[Nelson Silva]

So, to sum up, my roadmap proposal would be something like:

 - Promote ShareJS to top level at GitHub

 - Define a repo structure and guidelines for addons and samples

 - Extract samples, persistence, C/S protocol, etc as addons

 - Implement Document Metadata as proposed in https://github.com/josephg/ShareJS/wiki/Document-Metadata This would give us contributors, cursors, etc

 - Create sample with participants and cursors (something like MarkdownR but with list of participants and cursor positions)

 - Refactor rizzoma's contribution to support "attributes". (They call "params" as of now but the ideia is the same)

 - Create sample rich text editor (using Rizzoma's editor, Halo or any other text-editor - it would be great to have an editor that doesn't depend on content editable - perhaps extracting Wave's editor and providing a pure JS API )

 - Support Wave's model ? (conversation, blips, etc...)

 - Create Robot API ? (could just be a ShareJS client but with a nice interface)

What do you think ?

[Henri Bergius]

On Tue, Apr 24, 2012 at 11:18 AM, Nelson Silva <nelson...@gmail.com> wrote:
>  - Create sample rich text editor (using Rizzoma's editor, Halo or any other
> text-editor - it would be great to have an editor that doesn't depend on
> content editable - perhaps extracting Wave's editor and providing a pure JS
> API )

I'm happy to work on this with Hallo (http://hallojs.org/), but I will
need some help to understand how to apply OT to rich text (I can read
Cyrillic but my Russian is too rusty for the comments in the Rizzoma
codebase ;-))

[SlNPacifist]

вторник, 24 апреля 2012 г., 16:32:41 UTC+7 пользователь Henri Bergius написал:

On Tue, Apr 24, 2012 at 11:18 AM, Nelson Silva <nelson...@gmail.com> wrote:
>  - Create sample rich text editor (using Rizzoma's editor, Halo or any other
> text-editor - it would be great to have an editor that doesn't depend on
> content editable - perhaps extracting Wave's editor and providing a pure JS
> API )

I'm happy to work on this with Hallo (http://hallojs.org/), but I will
need some help to understand how to apply OT to rich text (I can read
Cyrillic but my Russian is too rusty for the comments in the Rizzoma
codebase ;-))

Commentaries at the top were updated some time ago, they explain the idea of every operation. All function commentaries are rather dumb and they were written just to make sure functions don't do more than they should.

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Jabber: henri....@gmail.com
Microblogs: @bergie

You can ask me any question about "formatted text" datatype or common OT - didn't read much theory but caught some unobvious things trying to implement OT from scratch. Moreover I'd be glad to participate in audio/video conference if anyone wants it.

By the way, if we want well written data type, we should consider using some utilities since most of OT is just transforming ranges aganist insertions and deletions, and this code is duplicated in every type working with array-like data (strings and lists for now).

[SlNPacifist]

понедельник, 23 апреля 2012 г., 17:37:27 UTC+7 пользователь Nelson Silva написал:

Also you need to setup rules for new inserts on the boundaries of an annotation. Imagine I have "this is bold text" and an annotation that says [8,12] = ["style/bold"] thus assigning style bold to the range 8-12, what should happen if a user adds "er" at pos 12 ? The expected behaviour would be for the annotation to be updated to 8-14 thus annotations should be inherited from the left.

I came to conclusion that there is no effective way to implement this behaviour in transformations because this behaviour depends on document, which is totally bad for transformations, since every client can have it own version of document.

In this case:

Originally two clients have text (I've underlined bold text because bold is slightly visible on my monitor):

This is bold text

First writes "er" at the end, second removes bold from last word:

First: This is bold texter

Second: This is bold text

They exchange with operations which do not get transformed against each other because there is no clue that they influence each other in some way:

First: This is bold texter

Second: This is bold texter

At the end clients have different documents which is not what we want from OT.

[Joseph Gentle]

On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson...@gmail.com> wrote:
> So, to sum up, my roadmap proposal would be something like:
>
>  - Promote ShareJS to top level at GitHub

Sure.

>  - Define a repo structure and guidelines for addons and samples

Do you think that would help? I'm a little biased, but I think the
repo structure is fairly self explanatory.

>  - Extract samples, persistence, C/S protocol, etc as addons

There's a fair bit of thinking we have to do here, about exactly how
sharejs should be structured. I'm not too happy with how its
structured at the moment - I feel like sharejs is trying to do too
much. I'd be interested to see proposals for how it should be
rewritten.

>  - Implement Document Metadata as proposed
> in https://github.com/josephg/ShareJS/wiki/Document-Metadata This would give
> us contributors, cursors, etc

Yep. I've been promising this for months, and I keep getting
distracted. We'll get there.

>  - Create sample with participants and cursors (something like MarkdownR but
> with list of participants and cursor positions)
>  - Refactor rizzoma's contribution to support "attributes". (They call
> "params" as of now but the ideia is the same)
>  - Create sample rich text editor (using Rizzoma's editor, Halo or any other
> text-editor - it would be great to have an editor that doesn't depend on
> content editable - perhaps extracting Wave's editor and providing a pure JS
> API )
>  - Support Wave's model ? (conversation, blips, etc...)

Wave's model is quite complicated. I'm not sure how much of it we
really need. Eg, wave has full XML support (arbitrarily nested
elements with attributes) as well as rich text annotations, which are
orthogonal to the XML structure. I think thats too much. I'd be happy
with just supporting one or the other.

>  - Create Robot API ? (could just be a ShareJS client but with a nice
> interface)

Haha knock yourself out :D

-J

[Nelson Silva]

No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jos...@gmail.com> escreveu:
>
> On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson...@gmail.com> wrote:
> > So, to sum up, my roadmap proposal would be something like:
> >
> >  - Promote ShareJS to top level at GitHub
>
> Sure.

Great!

>
> >  - Define a repo structure and guidelines for addons and samples
>
> Do you think that would help? I'm a little biased, but I think the
> repo structure is fairly self explanatory.
>

This should probably come after the next point... the idea is to define a structure for addons... the repo structure for ShareJS is fine.

> >  - Extract samples, persistence, C/S protocol, etc as addons
>
> There's a fair bit of thinking we have to do here, about exactly how
> sharejs should be structured. I'm not too happy with how its
> structured at the moment - I feel like sharejs is trying to do too
> much. I'd be interested to see proposals for how it should be
> rewritten.
>

Etherpad Lite has plugins using npm so we could try something like that... break up ShareJS into modules and then work on each of those to provide proper abstractions and promote code reuse in new contributed modules.
Projects like brunch allow you to choose the plugins you want to use just by adding them to your package.json... these are just two examples but i'm sure there are several other approaches to choose from.

> >  - Implement Document Metadata as proposed
> > in https://github.com/josephg/ShareJS/wiki/Document-Metadata This would give
> > us contributors, cursors, etc
>
> Yep. I've been promising this for months, and I keep getting
> distracted. We'll get there.
>

Not sure you have donations set up but you should... i understand that these days there's just so many neat stuff to do and all hobby projects get to a point they feel like an obligation... perhaps we could come up with a neat project based on ShareJS for motivating.. how about some sort of game? Or a ptp version using webrtc's peerconnection?

> >  - Create sample with participants and cursors (something like MarkdownR but
> > with list of participants and cursor positions)
> >  - Refactor rizzoma's contribution to support "attributes". (They call
> > "params" as of now but the ideia is the same)
> >  - Create sample rich text editor (using Rizzoma's editor, Halo or any other
> > text-editor - it would be great to have an editor that doesn't depend on
> > content editable - perhaps extracting Wave's editor and providing a pure JS
> > API )
> >  - Support Wave's model ? (conversation, blips, etc...)
>
> Wave's model is quite complicated. I'm not sure how much of it we
> really need. Eg, wave has full XML support (arbitrarily nested
> elements with attributes) as well as rich text annotations, which are
> orthogonal to the XML structure. I think thats too much. I'd be happy
> with just supporting one or the other.
>

The json stuff in ShareJS should be enough to mimic wave's conversation model and the blips could be text with attributes/annotations. So basically we're mostly missing a rich text model. Since rizzoma already has this we could just start by extracting it from their clone.

> >  - Create Robot API ? (could just be a ShareJS client but with a nice
> > interface)
>
> Haha knock yourself out :D
>

:p just aiming high...

> -J

[Nelson Silva]

For reference... this is a discussion about brunch's approach to plugins:

https://github.com/brunch/brunch/commit/f903e7b723afd7f9900eb57f93d07bc612ec1818

[spasquali]

It's unfortunate that this is written is CoffeeScript. It's a strange choice for a revolutionary product -- to intentionally exclude the majority of developers, and to convict those remaining to debug hell.

Such brilliance, dulled. That JG is that brilliant is the only reason we see this at all.

The proper thing is to fork the project into a JS-only initiative, properly annotate it, and invite developers.

In fact...

[Jeremy Apthorp]

I think you've missed the point of CoffeeScript.

[Collin Miller]

Yeah, I think if you're going to complain at least suggest a substantial change, like an Erlang server implementation.

"C-" for effort.

[Sandro Pasquali]

Could you expand on that?  For now I'll respond using a level of analysis equal to yours: I think you've missed the point of my post.

[Sandro Pasquali]

Sigh.  

Let me give you a concrete example. This should help you understand the very simple point I made. I'm assuming you're actually interested in being helpful.

Our team is growing. We build diverse products in a very large space which demands precision and realtime performance. As such, NodeJS has entered into our conversation, and via that pathway, so has ShareJS.

It is an exciting time for realtime, collaborative applications. With Joseph, I want this new niche to become a big niche and maybe even a huge new initiative that will bring even more excitement (and fun, and profit) to the technology sector (https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)

But collaboration isn't just a buzzword: applied correctly, it can greatly improve the user experience, team dynamics, strategy, and other business needs for those of us who are building the software products of the future.

In order to explore these ideas our team constructed a collaborative editing environment using ShareJS, which we now use internally, and when ready, will release as a full-fledged (and open) product.

We do not have anyone on our team who writes Coffeescript. Not because we think it is stupid, or a trend, or we like to complain about the meanies who innovate. We love those meanies! It is also not because we don't "understand" CS, or aren't competent or hip enough to grasp indentation. Just three of many reasons:

1. We don't have anyone who writes CS. So we can't usefully contribute to CS projects. You (might) be able to grasp, given what we are currently working on (and which libraries we are using), why that fact is relevant to this conversation.

2. We are a profit-driven company that does not spend resources uselessly. A convincing business case has yet to be made to me demonstrating the benefit of taking my team off of servicing our customers (fixing bugs, feature care, new products) and learning another way to write code in JS (amazingly, they are really quite good at writing it the old fashioned way).

3. There is clear and unmistakable preponderance of JS coders vs. CS coders. This would put costly strain on our recruiting efforts, which may even put us in the terrible position of not being able to control peer quality at the source (careful selection of team members) due to a desperate need for hands.  I do not want to hire anyone for the wrong reasons, (and neither do you).

Consider truth: a small fraction of a developer's time is spent writing new code. 

Consider why: mature languages offer the lovely benefit of a vast, existing, codebase which probably already solves that problem. Every time I hear a CS person argue for DRY it kills me a little inside.

Consider analysis: What is *advantage* of the compile step? What is the *advantage* of losing existing IDE tools (mainly their debugging features)? What is the *advantage* of having a CS coder on your staff (it isn't speed -- that is a red herring. See previous.)? How would you argue for budgeting the additional training and recruiting costs to your CEO?  What is the *advantage* of bifurcating your development process (given all that JS code that powers your existing systems)?

Consider the point: When I want to encourage contributions to my OS JS project (which this is), why would I make it difficult for JS coders to contribute? This is a great place to think about what I've written in the context of *the point of this entire thread* : why is it that this project has so little activity?  Or better: how can we make it more active? Because it should be. Because it is brilliant and timely and effervescent.

I'm suggesting not only a substantial change, but an essential change.

[Collin Miller]

It's pretty terrible to lord your "precious paid-time contributions" over a free/open source project on the basis of the language used to implement it.

If the authors willing to put in the time are happy with CS, it's going to be in CS. That's the nature of the beast.

If you want pure-JS, put your money where your damn mouth is and show us the code.

[Collin Miller]

If we can't find anybody willing to re-write the whole thing in JS I had this idea.

fork it and run:

coffee -co lib/ src/

Now you've got a very clean pure-js implementation you can work on without blowing up your cost structure.

And debugging works great.

I will personally rewrite your patches in coffeescript to get them into ShareJS proper. For free.

I'm 100% serious and extend this offer to anybody else who wants to contribute but can't be bothered to deal with a little coffee script.

[Nelson Silva]

This is getting a bit offtopic so we should probably move this discussion to a new post.

Still, I don't see any advantage of JS over CS. The trend is polyglot programming, just use the right tool for the job and JS is becoming the VM for the web so this is like saying "you should have written it in assembly, all that C/C++/... stuff is just adding more complexity to the code base". The motto of CS is CS is just JS so there's nothing stopping you from extending ShareJS with pure JS and if you want to contribute back to the project just publish your work somewhere and someone will gladly port it over to CS (even if it's just a mater of using http://js2coffee.org/)

A port to GWT or Dart is a lot more interesting (specially the latter). Static typing or type checking along with proper tooling support would make it worth while and in the end both of these compile down to JS.

[Kai Chang]

I'm glad Joseph took the essential component of Wave and created a simple way for js programmers to get started with realtime OT. It's  a great project that I was able to deploy on a server to teach a friend some programming.

The project is well-designed, well-documented, with many examples. How much better can it get?

I think the roadmap should be whatever Joseph feels inspired to do, he should do that. Apache Wave has tried all sorts of roadmaps and planning, and still the Wiki and examples don't hold a candle to ShareJS (despite being a much older, larger project).

[Dominic Tarr]

I'm a javascripter, and certainly not a coffee scripter, but I can see
that coffee script is really
nothing but javascript with 'a queer makeover' but most of the
semantics are still the same
on the inside. a competent javascripter could pretty easily hit the
ground running with coffee script.

it would probably be easier to just learn it than to try and get
ShareJs to change.

[Claudio Cicali]

Totally agree.

I really hope that this CF hype will die asap.

[Nelson Silva]

CF?
I still struggle to understand why people are reluctant to embrace polyglot programming... is it because you invest in lots of meaningless Java / .net certifications? Are you afraid to end up with unmantainable code? Do you still believe in code reuse? I can understand the complexity of a big codebase written in a dynamic language but ShareJS is simple, concise and well tested so CS fits it like a glove. I did a quick port of the text OT stuff to Dart in a couple of days and will try to get the JSON stuff as well so if you have a team available you can probably port it to whatever language you need in no time.
You have OT code from etherpad, apache wave, collide, etc... all freely available as well so just pick whatever you want and get it working. I have ShareJS working on rhinojs on vert.x so i can dev modules in any language... just stop with the CS vs JS debate... i would pick CS any day over JS just because it looks and feels better to me but hell, some people even like php so it's really a mater of opinion.
Joseph did a great job with ShareJS i think it is better because of CS. If you'd rather use JS look at Etherpad Lite, they even have attributes. If you're into GWT you have Apache Wave and collide.

[Claudio Cicali]

The problem is that for me, now, CS is not a language worth learning. I'll never use (at least in a foresable future) CF as the language for ANY of my project; I'm perfectly at ease with JS, and I don't need any "dumb down" layers. I need to eventually find good JS programmers to help me out, not CF. So I'd need to learn it JUST to use someone else's project, even if the project is in... JS! I know that this applies with any other languages (using SOLR? Learn Java...), but at least learning a bit of Java makes sense.

We're going to have to learn a lot more JS in the next couple of years (EC6, anyone?), writing compatibility layers, addressing browser issues... do we really need to get our life even more complicated with a level of (fake) abstraction, with a new syntax, written by same random guy? I don't think so.

Sorry for the rant.

[Naveen Michaud-Agrawal]

Unfortunately for you, the web is moving toward polyglot programming with javascript as the 'runtime' (similar to the JVM as the runtime for Clojure, Scala and the like). Now that browsers are starting to support Source Maps, you'll start seeing much more experimentation in client-side browser languages, not less. Expect to see many more interesting projects that use languages that haven't even been invented yet.

If you really have an allergy to CS, you can do as Colin mentioned above and compile ShareJS into JS and use that directly. You'll find the code generated by CS to be really clean and readable (I was able to port the OT model to python directly from the CS, and add a tcp connection that could be used from non-web clients, and this is without much experience in either JS or CS).

Naveen

[Nelson Silva]

Come on, CS takes like a couple of minutes to understand. Everyone who uses it is/should be at ease with JS, it is but a subset to make it more manageable. JS is very "forgiving" and i really believe you have to be a ninja to grasp all its quirks.. prototipal inheritance, vars that get promoted to outer scopes, dozens of different ways to get stuff done, inconsistent behaviour between browsers, weird type conversions, etc, etc... if we're stuck with it i really hope we get more of GWT, CS, Dart, whatever...
Also, there's no need to learn CS to use ShareJS! You can extend it with pure JS, you can wrap it in jsni and use it in gwt, you can wrap it in an isolate and use it with Dart, you can run it with v8 and use it with c, c++ whatever, you can run it with rhino and get it on the jvm...
Don't learn JS or Java... learn programming! OO, functional, logical, try a bit of Scala or haskell for true powerfull type systems, learn C to understand pointers, try some asm just for fun, learn lisp or smalltalk to understand where we come from and that the greatest languages have been here for decades, play with prolog for something different, learn python, ruby, see how rails and django brought some sense to jee just by keeping it simple! Try Go, try lua, try Dart... and perhaps in the end you'll feel like many... so many great languages and we got stuck with JS for the next couple of years ! Even actionscript its ecma cousin is better...

[Joseph Gentle]

If you already know javascript, it takes about 2 hours to learn
coffeescript. Coffeescript introduces (almost) no semantic changes to
javascript. It takes longer to read & understand Javascript: The Good
Parts than it does to learn coffeescript. Its much easier to teach a
good javascript developer coffeescript than it is to teach a fresh
javascript & coffeescript programmer how to write good JS/CS.

But that isn't really why we're arguing here. Zed Shaw says it better
than I can:

"""
Imagine I break software development clients into two camps:
Collaborators and Customers. Now imagine I then break projects into
two categories of Implementation and Invention.

Collaborators will participate daily and know what's going on because
they are there and will usually pay variable price because of a higher
tolerance of risk. Customers just want something packaged, want it now,
and will only pay a fixed price and if it isn't perfect they'll bitch.

Implementations are things you've done a billion times or that you can
manufacture with a consistent process and have low risk and low
variability. Inventions are done different every time, require creative
thinking, adaptation to randomness and chaos, and generally are riskier
and variable.

In an ideal world, you pair Collaborators with Inventions, and
Customers with Implementations. The other combinations end in
disasters and you really only find them in the corporate world where
the force of tons of cash can make those bad mixes work anyway. In the
open source world where Darwin rules, the good projects gravitate
toward Collaborators+Inventions or Customers+Implementations, with the
former more common than the latter.

The reason some people might get upset at you is that you are saying
(or what they hear) is, "I'm a Customer dammit and I want my
Implementation planned with no risk now." That's ungrateful and
irritating and insults their hard work.
"""
(From http://lua-users.org/lists/lua-l/2007-12/msg00470.html )

ShareJS needs to balance the needs of these two camps. There's a lot
of creative design in ShareJS. But also, it needs to be stable so you
can actually use in your products. If its too planned, contributors
get bored and leave (like me!). But if its too unstable, the project
isn't actually useful.

I feel this struggle constantly in the code. The use of coffeescript
is a concession to creativity and learning - coffeescript is a fun
language to program in, and it makes me feel like a monster stomping
through tokyo. But I also want ShareJS to be stable and not break
between versions. Hence ShareJS has a bajillion lines of unit tests
and CI and whatnot. Unit tests mean ShareJS should never break. But
they're seriously annoying when I want to change the APIs (even
internal ones) because I have >2x as much code to change.

So yes, using coffeescript is a conceit to make the project more fun
to work on. If your developers don't like learning, fork the project,
compile out the coffeescript to javascript then clean it up. The
golden rule of coffeescript is that it maps 1-1 to javascript anyway,
so the JS is surprisingly readable (eg:
https://github.com/josephg/ShareJS/blob/master/webclient/textarea.js
). Its a bit of work maintaining your own fork, but if you've got a
staff I'm sure you can manage it. As a byproduct, you'll learn ShareJS
works internally, which will make hacking on it way easier. I ported a
physics engine (Chipmunk) to javascript at the start of the year and I
understand it _sooo_ much better now than I would have from just
reading the docs or something.

-J

[Claudio Cicali]

Very interesting points indeed, Joseph (and Nelson, of course).

I think I'm gonna lose this angry feel about CS (I keep writing it "CF", don't know why!).

:)

[spasquali]

Not sure what is being implied re: Zed. I hope it isn't that "CS developers are inventors" and "JS developers are implementors". 

As always, I am thankful for this project (even in its current form) and am actively using it. 

This conversation is about how to get more collaborators. My minor point, distilled, is simple: regardless of how easy it is to learn CS, that is still a cost to be borne by someone, at least in time, possibly in interest, possibly in actual monetary cost to a company, which would not be borne if the project was written in JS. All costs are brakes on innovation. There are simply many more developers for ShareJS to attract without that cost. CS automatically, dramatically, lowers the project's chances of attracting contributions. I don't see how this particular analysis can be argued against on its own (and not for other reasons).

Demonstrating the point: https://github.com/josephg/ShareJS/pull/112

That being said, *of course* I am not making demands, implying that Gentle is some kind of jerk for wasting my time with this stinking CS.  *Of course* the project existing, at all, in CS or in FooBarScript or something else is more important than it not existing.  *Of course* it is so good that some (but not as many as the fanboys may think...) will learn CS *solely* to use it. If it needs to be in CS for the core team to stay interested, of course that is the winning strategy.

Porting to JS is an excellent idea, especially for the pedagogical implications.

[Nelson Silva]

I guess what's missing in your analysis is the fun factor. When you invest your free time on an open source project you need it to be fun. Learning a new language increases the fun factor and the simplicity of CS and its overall look and feel really adds to that. I understand Joseph and i believe he won't be working much more on ShareJS. When you start growing your project and community you have to start worrying about stability, performance, etc... you have to please users and make a commitment and that's no longer fun! It's like Zed put it... there are innovators/entrepeneurs who love playing with new ideas but after a while they get bored and start looking for new toys... it is up to implementers to take care of the boring stuff and turn the prototype into a product.
If you feel that a JS port is the way to go do it! That's a very simple task and like you said there are lots of JS developers (although i'd rather have one Joseph than a dozen others :p).
I've been feeding this discussion cause i'm on holidays but i think that if all the time we've "lost" here was put to good use you'd already have you JS "port" up and running.
I'm working on a Dart port and will get back to it asap. It's a great learning experience which i recommend to anyone interested in ShareJS.