[IPython-dev] [iPython-dev] thoughts on the notebook, alternative front-ends and remote editing

Nicholas Bollweg nick.bollweg at gmail.com
Thu Mar 5 15:59:18 EST 2015

Really, not trying to start a fight with Mountain View!

Reading up on the Google Drive spec, there is at least one (no license
provided, 1 contributor) API implementation in Java:


Presumably, between that and the API docs, another reference implementation
could be built, presumably on Tornado to fit with the rest of the community
infrastructure. Presumably some kind of cross-implementation test suite
could be arrived at. I would see those pieces as an entry gate.

I would still see something that looks like a local evented model store, no
matter how the updates get to it: perhaps this is a thing the Flux pattern
can be used to implement?

I have no experience with React, but do find a lot of what they say as very
positive. I would look hard at the other reactive programming environments
(riot, mithril, etc.) as well: there is something to be said for orders of
magnitude less code in your framework. I wouldn't even rule derby out, as
its standalone form is pretty capable, but heavy like react because it is
bringing along so many node polyfills. But otherwise, having already
invested in backbone, it's not the worst either.

On Thu, Mar 5, 2015 at 2:17 PM, Kester Tong <kestert at google.com> wrote:

> Jared,
> can you let us know (here or in
> https://github.com/ipython/ipython/issues/7784) a bit about your
> experience with React.  I've found it very easy to use but powerful, and it
> seems to play nicely with other frameworks.  Other people have raised
> concerns about performance (e.g. Atom moved away from React for performance
> issues).  I can identify 3 areas that might need to be handled outside
> react: the text editor, output areas (that can contain large binary blobs)
> and widgets (which I don't know a lot about).  I think these can probably
> be solved simply by having React components that wrap some other code, and
> don't try to maintain state using React.  But you have a lot more knowledge
> of this than me.
> Kester
> On Thu, Mar 5, 2015 at 2:07 PM, Jared Forsyth <jared at jaredforsyth.com>
> wrote:
>> ++for react. That's what the UI for Notablemind is written in, and makes
>> state management awesome. It also makes things like rearranging cells
>> trivial.
>> On Thu, Mar 5, 2015 at 9:36 AM Kester Tong <kestert at google.com> wrote:
>>> Hi Everyone,
>>> I'm part of the Google team that is working with IPython on realtime
>>> collaboration and notebook redesign.  I was also one of the developers on
>>> the coLaboratory project, where we implemented a Notebook front end using
>>> the Google Drive realtime API (see
>>> https://github.com/jupyter/colaboratory or
>>> https://chrome.google.com/webstore/detail/colaboratory-notebook/pianggobfjcgeihlmfhfgkfalopndooo?hl=en-US
>>> for the working Chrome App).
>>> The main choices I've seen so far in this thread are:
>>> * text editor vs traditional notebook
>>> I prefer the traditional notebook for the reasons Nicholas gave.
>>> * Storing model in browser vs the same place as the kernel.
>>> I think that we should aim to have both capacities, and that's what me
>>> and Matthias had been aiming for so far.  For backends like Google's
>>> realtime API (which is afaik the only free web based backend for this sort
>>> of thing), the model needs to be in the browser.
>>> * Using derby.js
>>> It's great to have operational transforms (OTs) taken care of by someone
>>> else.  But I'm concerned that locking into this would exclude other
>>> backends such as Google Drive's realtime API.  Maybe we could wrap both in
>>> a another layer though.
>>> Currently I've been prototyping with React, although my prototype is
>>> much less developed than the others posted here.  React is nice because,
>>> based on my experience in coLaboratory, there are lots of stateful UI
>>> components in the notebook, and React allows you to store all your state in
>>> one place.  However, it also has stateful components if you need them.
>>> Right now I have a list of cells id's, and map from cell id's to cells,
>>> which as Matthias mentioned, seems like the best way to handle realtime,
>>> but also helps keep cell widgets independent of their position in the
>>> notebook.
>>> Kester
>>> On Thu, Mar 5, 2015 at 8:42 AM, Wes Turner <wes.turner at gmail.com> wrote:
>>>> On Thu, Mar 5, 2015 at 1:29 AM, Jared Forsyth <jared at jaredforsyth.com>
>>>> wrote:
>>>>> I've managed to get together a tutorial for ipython
>>>>> <http://app.notablemind.org/tutorial/ipython/> and a  general
>>>>> navigation tutorial <http://app.notablemind.org/tutorial/>, and more
>>>>> docs are coming soon.
>>>>> I'd love to get your feedback!
>>>> At first glance, this looks outstanding!
>>>> * Dig the vim shortcuts
>>>> * Dig the split panes (.glyphicon-resize-vertical and
>>>> .glyphicon-option-vertical might work)
>>>> Wondering how/where the 'undo' / 'redo' support is implemented, and
>>>> whether it would be possible to port that back upstream?
>>>> Thanks!
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150305/fc052558/attachment.html>

More information about the IPython-dev mailing list