Juniper and Thebelab

[nthiery]

Juniper and Thebelab seem to tackle the same problem, with -- if I understood correctly -- similar approaches. Is there an intrinsic reason preventing the two project to converge? E.g. by merging Juniper's cool additional goodies (e.g. CodeMirror cells, ...) into Thebelab?

Cheers, Nicolas

[Miniland1333]

The implementation of persistent binder instances is quite useful! For end-users, having to wait for Thebelab to reload on each page has been quite dull and Juniper's approach reduces the time that they have to wait!

[nthiery]

That's indeed a very nice feature. Do you foresee any barrier to contributing it back to Thebelab?

[Miniland1333]

I am not familiar enough with the underlying code myself, but I think that we could open a branch on Thebelab dedicated to porting over functionality. It look like this is allowed based on the license as long as credit is given. @ines would you be interested in this?

[ines]

@nthiery @Miniland1333 Sorry for only getting to this now. To give you some background:

Is there an intrinsic reason preventing the two project to converge? E.g. by merging Juniper's cool additional goodies (e.g. CodeMirror cells, ...) into Thebelab?

I started off by using Thebelab and later a custom build of it, but I ended up rewriting it pretty much from scratch in a way that makes it easier for me to maintain, especially for use in the spaCy site. At that point, I thought it was fairest to maintain my own fork instead of trying to push all my changes upstream.

For example, I would never go and open a PR on someone else's project like "Replace jQuery because I personally dislike it" – I think that's unfair to fellow OSS maintainers. If I want to rewrite code like this, I need to accept the maintenance burden and fork it.

But of course, everything I changed and did is open-source and published as MIT, so it can be reused by others or adopted again.