From what I have started to read, react also does not play nicely with external css.
I'm considering prototyping the things also by starting with the text-editor which is much simple and will be re-usable for code cells.

I might play around from the other side, (notebook structure) since I know nothing about JS text-editors.

My understanding is that things like React are about efficient updates to the UI. We are really performing two completely separate sync operations:

1. model to UI (this seems like what React etc. are for)
2. model to server (it seems like these tools don't help with this at all)

Is it possible for things like React to not talk to the DOM at all? It seems like that's not the right model for getting content into codemirror, etc., though I'm not actually sure.

@minrk

Is it possible for things like React to not talk to the DOM at all?

What do you mean? Do you want to address "model to server" using something like React? As you correctly said, React is about encapsulating elements that talk efficiently to the DOM. That is the point of the view in the MVC paradigm in which React works as the view.

@KesterTong

I would argue against using Polymer in the near future. Polymer proposes a very intriguing idea but it is still in its infancy and currently works only as a proof of concept as it relies heavily on polyfills to achieve its goal. Furthermore, web standards are notoriously slow to be accepted. If you are thinking about refactoring the Javascript code in the near future (months or even one or two years), then it is very unlikely that Polymer is going to be production-ready.

React is very nice. As other suggestions, AngularJS is very popular, Ember is also popular but very idiosyncratic.

By the way, I noticed you have Backbone as dependency but I don't think you're using it to manage the models. Is this correct?

@minrk @rsmith31415 Regarding React, what I meant was concerned that React forces you to have a single model object for the whole document, which it renders to the DOM with every change to this object. It does allow components to be stateful, but it seems to maintain a global "state map" (see http://blog.circleci.com/local-state-global-concerns/)

Given that react seems to be pretty flexible, I think it will probably be able to work with whatever we do.

@rsmith31415 Regarding Polymer, these are good points (btw I work at Google so that might give me a different perspective). We definitely do want things working now.

@takluyver Regarding Mithril, looks very similar to React, but I'm assuming React is overall a better choice because it's a bigger project. Not dismissing it but for now I would favor React.

Given all this, I think it makes sense to start prototyping with React (and maybe Omniscient) and see where that gets us. Even if we don't choose this framework, it's probably the fastest to prototype with, so we can learn something about what the constraints are.

Sorry internet was off yesterday :-(

I'll respond to all later.

I think one of the main advantage of things like react is that actually you don't have to bind
the changes of the model to the change of the dom.
and IIRC, you can change part of the model.

The main problem right now is that the current notebook UI is a state machine which has only one entry point,
and once we get RT collar, you can be dropped in the state machine at any point in time:
cell in execution, kernel restarting... and so on and so forth.

So you need to describe visually the app purely as a function of the model;
and not the the models. you do need only one model which is the state of the application.
The state of the application encompass the state of the notebook, but has more information
in it.

Le 14 févr. 2015 à 10:23, Kester Tong notifications@github.com a écrit :

@minrk @rsmith31415 Regarding React, what I meant was concerned that React forces you to have a single model object for the whole document, which it renders to the DOM with every change to this object. It does allow components to be stateful, but it seems to maintain a global "state map" (see http://blog.circleci.com/local-state-global-concerns/)

Given that react seems to be pretty flexible, I think it will probably be able to work with whatever we do.

@rsmith31415 Regarding Polymer, these are good points (btw I work at Google so that might give me a different perspective). We definitely do want things working now.

@takluyver Regarding Mithril, looks very similar to React, but I'm assuming React is overall a better choice because it's a bigger project. Not dismissing it but for now I would favor React.

Given all this, I think it makes sense to start prototyping with React (and maybe Omniscient) and see where that gets us. Even if we don't choose this framework, it's probably the fastest to prototype with, so we can learn something about what the constraints are.

—
Reply to this email directly or view it on GitHub.

I like mithril, as well as the newly-rereleased riot. Both are really cut-down, and have a lower barrier to entry than a big framework like Angular/React, despite the far smaller communities. But you then still have to solve the OT thing. Likely the current comms model is able to support this, but that's mostly outside my ken.

However, I'll throw out derbyjs as a maturing nodejs/browser (i.e. isomorphic) framework that handles OT from front to back (under the covers is ShareJS and racer). Presumably, a given "room" in nodejs would start a kernel against a notebook, so there would still only be one kernel.

It maintains a virtual DOM like react and friends, but because it also runs on the server, it can serve up the exact expected state of the DOM for someone just showing up when using its own templating syntax. It is possible to use any other javascript library as well, such as this codemirror example, but obviously it's not going to be pushing an already-evented Codemirror over the wire.

The big win of derby OT is that everything is handled entirely at an evented model level, where a model is big chunk of JSON-like data: thus it maps very cleanly to the notebook format. No messages, no callbacks, no pubsub. This should feel comfortable for someone who has worked in Backbone, as the models react like model.get("cells") returning a JSON list, but also dotted constructs within that: model.set("cells.0.source", "some code"). More powerfully, a dotted location in the model, model.at("cells.0") returns a scoped version of the model... which exposes .on("change", fn).

There are reactive model queries, etc. as well, but these would not be used for the baseline notebook interface... but would make the file browser, for example, much easier.

In addition to the model, there are additional namespaces like _session and _page that are either not persisted, or persisted differently. The model as exposed to the rendering page is fairly fluid as well: from the canonical model in the database, one can create references, like model.ref("_page.notebook", "notebooks.1234-15124-12312"). Each component, as well, has a model bound to the specific set of pieces of the rest of the model, which makes reusable components very easy to imagine.

Of additional interest is derby-standalone (demo) which wraps up the whole framework into a single file. This could be a very exciting way to deploy a notebook, as many interactive features could be maintained working against the in-memory model.

A little prototype-off sounds pretty interesting!

meant was concerned that React forces you to have a single model object for the whole document, which it renders to the DOM with every change to this object.

@KesterTong that is how om works (a clojurescript wrapper over react), but not how React has to work, or how it generally works in practice. Components maintain local state for things they own, and this is not kept in any sort of global place. Also, the whole DOM tree doesn't get updated for every change (not even the virtual DOM). If state within a component changes, that component gets updated, and it's children (but only if the children need to).

There it some skill involved in designing any large js app to be performant, but I have found that React makes things much easier than any other framework.

My experience: writing notablemind, which works as an alternate frontend to ipython, and handles large documents/notebooks (such as the tutorial) with relative ease, and that's without putting much effort into optimizing for speed (there's a lot of low-hanging fruit there, made simple by react).

Another huge plus for me with React is that it really lets you have modularity. Declaring a component just in javascript (instead of split between js+handlebars/angularbars) buys you so much.

In my experience, Angular projects are much harder to maintain at scale.

Ember has some good conventions to make things work for large teams, but all around TooMuchMagic for my tastes.

thanks for the info @jaredly. Reading the docs I got the impression that all the state tends to be stored in the top level component and passed down through the tree as properties.

I'm still not quite clear on how stateful components interact. Can you tell me more about this in general and for notablemind? I can imagine two patterns. The first is that the parent component keeps refs for the child component, which it uses whenever it needs to query state from the child component. The second is that the child component's state is managed by a model object that lives outside the child component's state, and whose changes are listened for by the component. The second pattern seems to be a requirement when we use external APIs like Google Drive or derby.js which define their own model objects. I guess the second pattern equates to using React as the View only.

Good talk yesterday, sorry I had to dip out before we got down to the nitty gritty.

Derby components are the same, but different, from/to react: both have an virtual dom. however, with derby one still has a split between html and javascript... or any compile-to-js/html languages.

Here are the components for derby-notebook.

Here's how the model chain stretches back to the server:

• A notebook document exists in the notebook collection in the store
• A route subscribes to the notebook document to its model and "renders" a template with that model (scare quotes, because it's doing the model<-->dom diff ✨
• the template can include one or more components, referenced with custom tag names... that never go to the DOM!
  • the template creates bidirectional bindings to underlying model paths to its components which become...
• the model mounted on the component, which has no (direct) knowledge of where it came from.

What I like about this is that there is only the one metaphor for interacting with data:

/store|route|component/.model./get|set|.../(path, value, function(err){})

Some status:

I've broken out markdown cells as a specific thing to implement the render-edit loop, as well as capture the concept of "I want this rendered" while "that other person doesn't". Works pretty good!

It's actually pretty cute to watch markdown get live-rendered while someone is working on it... occasionally huge swathes of text disappear and reappear, or when images magically show up.

I still have to work on the "sealevel" for scrolltop to ensure that the users viewport stays static while things are happening elsewhere.

I've also started thinking about user identity, activity, presence, and chat, as in discussing with colleagues it seems pretty clear that a robust (and preferrably undoable (and preferrably computable)) history is needed: look away, and who knows what happened! At first, I'll likely just let the currentCell (and perhaps currentCursor) leak out of session and into the notebook document and use identity (random font-awesome + random color) to annotate the other editors' current focus. But a gitter-like chat experience, with messages like\

Showing

• Chat
• Cell Events
• Widget Events

15:00 ran cell y
15:01 says: What have you done? 👎

is really not very far away. The computable part would be being able to access this kind of history in the notebook itself, which is terrifyingly meta. We're thinking voting widgets, brainstorming with word clouds, etc.

Additionally, I've added a little documentation of how my data model represents the stateful notebook. If none of my other stuff lives past my research here, perhaps this can!

@bollwyvl you might want to check out the coLaboratory Chrome App to get some ideas on identity and presence. We also use google-docs style comments internally, where comments are attached to a particular cell.

I haven't checked out coLaboratory... I should definitely give it a shot! I
understand it actually embedded a kernel with nacl, or some such dark
sorcery.

Sure, i see "cell" (annotation) as one of the key axes of messages, though
"time" (chat) is important as well. Basically any "effort" the user puts
into the system is potentially interesting... Explicit notes, Widget
interaction, etc.

Actually, easy uploading and annotation of pdf is one of the must-have
features of the system we envision to support applied research by virtual
teams... In addition to cite2c-like annotation consumption, both in
markdown and some rudimentary rich text editing (nb-wysiwyg).

I look forward to the continuing discussion... Has there been any more
about higher order abstraction for rt/ot yet?
On Mar 12, 2015 8:16 PM, "Kester Tong" notifications@github.com wrote:

@bollwyvl https://github.com/bollwyvl you might want to check out the
coLaboratory Chrome App
https://chrome.google.com/webstore/detail/colaboratory-notebook/pianggobfjcgeihlmfhfgkfalopndooo?hl=en-US
to get some ideas on identity and presence. We also use google-docs style
comments internally, where comments are attached to a particular cell.

—
Reply to this email directly or view it on GitHub
#7784 (comment).

ot.js is much cleaner than share.js. It has an implementation in Javascript and Python and CodeMirror support.
https://github.com/Operational-Transformation/ot.js

I'm not familiar with derbyjs but I would rather have separate implementations for the UI and OT.
That will make things more modular.

In my case, I already have an OT server that is not using node.js (or sharejs).
My server controls editing permissions and if you'll force me to use derbyjs and node.js it will make it very hard for me to integrate the notebook.

@benbro we're trying various prototypes at various levels here. I suppose the discussion will probably end up being about the one The Jupyter Realtime Notebook, which as much as anything will be driven by the modularity at each layer, but i think experimentation is the order of the day. But yeah, we will have to pick an stack for what is eventually shipped.

What are your needs and goals? What is missing from the comms spec that you want for your integration? We're definitely going to need to support different rt/ot systems, and the simpler, more standards-based, multiple-implementation, the better. I had looked at substance and ot.js some time back, i'll have to circle back around and see what has developed. Can you point us at any specific highlights?

The derby prototype is not affiliated with ipython/jupyter, aside from this discussion, and is at least partially in support of creating a more complex open source example of a derby application... One can only look at so many todo examples. However, i feel like it may indeed not be the right long term answer because it is so dominated by one major contributor. That being said, it works pretty good, and suits the work that i am doing. It actually is quite modular, as while sharejs is sharejs, racer (the model layer) and derby (the ui layer) can be used independently (derby-standalone).

Hi Everyone,

I just wanted to update everyone with our current thinking on frameworks. This is a consensus based on discussion in the IPython developers meeting in March, and meetings with @ellisonbg @Carreau @jasongrout @sccolbert @SylvainCorlay and myself.

1. We will begin protoyping with phosphor, which so far is a clear winner over React, but the similarity of these frameworks means switching will be easy. Key points of comparison are
   • Phosphor is "the good parts" of react.
   • Simple JS syntax for building the virtual dom beats JSX, because it keeps the toolchain simple.
   • Phosphor is written in TypeScript. React may be compatible, but have a framework written in TypeSecript is even better.
   • Some minor concerns about the diffing algorithm creating unnecessary moves, but it's very unlikely this will turn into a major problem.
   • The ability for designers to write in JSX seems like a marginal benefit for React, as we prefer to have the designers produce images anyway (not sure if all IPython devs agree here, but this was our thinking).
2. No matter what the framework, everything will be done in TypeScript. Key points:
   • TypeScript will have solved all ES6 compatibility issues by the time we are doing the rewrite.
   • TypeScript seems to be generally great. @ellisonbg and myself were impressed with how easy and non-verbose it was to write, how much static safety the type system provides, and the simplicity of the toolchain.
3. Use phosphor panels (formerly known as widgets, but renamed to emphasize their primary use in high level layout) for high level layout only. Lower levels of the dom tree well be done using phoshpor components.
4. Start off using plain ES6 objects for model objects, possibly inheriting/using Phosphor events/signals.
5. Plan of action: @Carreau @jasongrout and I will work on a prototype of notebook with a TypeScript notebook model, and phosphor components, including Brian's CodeMirrorComponent. This will have add a realtime backend which is wrapped in an evented model.

@KesterTong is there any info about phosphor like a website, blog, talk or online examples?

https://github.com/phosphorjs

There are examples I don't remember where.

https://github.com/phosphorjs/phosphor/tree/master/examples

The phosphor-ui and phosphor-core repos have been merged into the phosphor
repo and will be removed in the coming days. I'm still in the process of
updates based on feedback from our recent meetings.

On Thu, Mar 26, 2015 at 8:07 PM, Matthias Bussonnier <
notifications@github.com> wrote:

There are examples I don't remember where.

—
Reply to this email directly or view it on GitHub
#7784 (comment).

Hey, I've been working on a project (still in very early stages) to make writing IPython notebook-like apps easier. I'm using AngularJS - I think I read elsewhere you may have already discounted angular, but maybe some of my code could still be useful.

You can find it at https://github.com/dustyrockpyle/ipyng.

I have a few novelties working with it, and getting a notebook app working is on my to-do list. Let me know if you have trouble with the build system or if you have any questions.

Thanks for the pointer @dustyrockpyle.

@Carreau @sccolbert @jasongrout The latest experiment with using phosphor to create a notebook interface is at https://github.com/KesterTong/phoshpor-notebook.

My main goal was to transfer my knowledge of virtual-dom usage to @Carreau and others. The separation of model and view in the code is not very good.

@Carreau can you coordinate with @jasongrout who already has a typescript notebook model? @sccolbert has been very helpful with phosphor related issues, so ping him with questions about the framework.

btw https://github.com/KesterTong/phoshpor-notebook is just a fork of phosphor itself. I didn't figure out a way to use phosphor as a dependency except by following the same pattern as phosphor examples. To run, follow the instructions in the readme, then build the notebook with gulp notebook and then run python -m SimpleHTTPServer and navigate to http://localhost:8000/notebook/

One big hesitation for me about phosphor: Is anyone using it? It has 3
stars on github, has existed for less than a month, has no noticeable
website, and it looks like no tests. I'm all for experimentation, but there
are definite benefits to using a framework that people have been using and
improving for a while. What if we get a few thousand lines into the project
and then realize that some of the fundamental design assumptions of the
framework don't scale?
If you want a "react but not actually react", then there's mithril, or
mercury, or a variety of other things.

On Wed, Apr 1, 2015 at 9:54 AM Kester Tong notifications@github.com wrote:

btw https://github.com/KesterTong/phoshpor-notebook is just a fork of
phosphor itself. I didn't figure out a way to use phosphor as a dependency
except by following the same pattern as phosphor examples. To run, follow
the instructions in the readme, then build the notebook with gulp notebook
and then run python -m SimpleHTTPServer and navigate to
http://localhost:8000/notebook/

—
Reply to this email directly or view it on GitHub
#7784 (comment).

Technically, phosphor hits a sweet spot in that we can use the virtual dom when want it, but also mix in manual dom manipulation. Another advantage is being written in typescript.

@ellisonbg initially noticed phosphor because of it's widgets/panels. These provide layout of multiple panes in js similar to a tiling window manager. I'm not very familiar with this side of things, but I think @ellisonbg feel strongly that Jupyter needs this kind of layout manager. Given that we would be using these widget/panels for the large scale layout, it seems natural to use phosphor for the virtual dom too if we can.

Regarding the community support for the project, the following things ameliorate this problem:

• The components/virtual dom library is very small and simple.
• Switching between components/virtual dom libraries is not that hard. The hardest part is writing the model/controller code.
• @sccolbert (author of phosphor) works for Bloomberg, who do a lot of work with IPython.

Up til now we were only aware of React and Phosphor, so we should look into mithril and mercury. Are you aware if either of these has better support for typescript?

One big hesitation for me about phosphor: Is anyone using it?

Yes internally.

It has 3

stars on github, has existed for less than a month,

More, but repo was moved, changed to typescript and made public recently.

has no noticeable website, and it looks like no tests.

True, for test but typescript is annoying enough that you cot your test everytime you compile :-)
We will do better.

I'm all for experimentation, but there
are definite benefits to using a framework that people have been using and
improving for a while. What if we get a few thousand lines into the project
and then realize that some of the fundamental design assumptions of the
framework don't scale?

I share similar reservations about phosphor: testing, documentation, lack
of large-scale production deployments, tenuous build chain, stylus. I did
give it a spin, though, and it seems ok once you overcome these things.

I am generally in favor of using a higher-order compile-to-JS language, and
see the benefit of having a framework that also enjoys the assurances
provided by that kind of build process.

However, my initial introduction to typescript has a very NIH feel to it.
Why are types their own package manager... that breaks travis? Now we have
three package managers.

I am +1 on mithril http://lhorie.github.io/mithril/index.html: you can
read and understand it in an afternoon. It supports typesecript
http://lhorie.github.io/mithril/tools.html. It can compile a big chunk of
html into a function. It's basic signature for building a component is
humorously short.

RiotJS http:///is similar. It has its own template language, which is
even valid HTML.

As I mentioned at length earlier, Derby is also worth considering: it can
be completely front-end https://github.com/derbyjs/derby-standalone, but
brings half of nodejs along, so it's 200k. But it does support the realtime
evented model that phosphor remains agnostic about, and will have to be
welded on.

We can follow on phosphorjs/phosphor#8

Regarding Mithril, has anyone looked at the source code? I have. It's impenetrable and undocumented.
https://github.com/lhorie/mithril.js/blob/next/mithril.js

@bollwyvl

tenuous build chain, stylus

What? Gulp and Node.js are tenuous now? What's wrong with Stylus? Would you be okay with Less or Sass? What difference does any of this make? It builds and it works.

initial introduction to typescript has a very NIH feel to it

You must have taken a superficial look. It's been in development for years by Microsoft and they have deployed million+ SLOC projects which it. Angular 2.0 is written in TypeScript. etc...
microsoft/TypeScript#1757 (comment)
http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

The API documentation for Phosphor is very thorough. Yes, there are no website/tutorials yet but that's because I spend my time making the library better.

Phosphor provides much more than just a virtual DOM, see the discussions from yesterday:
#7997
phosphorjs/phosphor#8

Let's move the phosphor discussion to the phosphor repo.

On Wed, Apr 1, 2015 at 10:07 AM, S. Chris Colbert notifications@github.com
wrote:

Regarding Mithril, has anyone looked at the source code? I have. It's
impenetrable and undocumented.
https://github.com/lhorie/mithril.js/blob/next/mithril.js

@bollwyvl https://github.com/bollwyvl

tenuous build chain, stylus

What? Gulp and Node.js are tenuous now? What's wrong with Stylus? Would
you be okay with Less or Sass? What difference does any of this make? It
builds and it works.

initial introduction to typescript has a very NIH feel to it

You must have taken a superficial look. It's been in development for years
by Microsoft and they have deployed million+ SLOC projects which it.
Angular 2.0 is written in TypeScript. etc...
microsoft/TypeScript#1757 (comment)
microsoft/TypeScript#1757 (comment)

http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

The API documentation for Phosphor is very thorough. Yes, there are no
website/tutorials yet but that's because I spend my time making the library
better.

Phosphor provides much more than just a virtual DOM, see the discussions
from yesterday:
#7997 #7997
phosphorjs/phosphor#8 phosphorjs/phosphor#8

—
Reply to this email directly or view it on GitHub
#7784 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

To elucidate a bit on what others have said: we did consider a range of JS frameworks at an in-person dev meeting in Berkeley a few weeks ago, and the concerns about Phosphor being a young and relatively unknown project were brought up. However, there are the following points in its favour:

1. We believe the project has solid foundations, and @sccolbert knows what he's doing. He explained to us why he wrote Phosphor, where it can interoperate with other frameworks like React, and so on.
2. Phosphor is being used internally at Bloomberg, so the risk of it being abandoned is relatively low.
3. Bloomberg is using IPython, and we're talking with Chris, so if we hit a bug or limitation in Phosphor, we may be better able to get it resolved quickly.

There are also two pieces involved in this discussion:

• Application layout: to the best of my knowledge, nothing else does the job Phosphor can do in this regard. Building the layouts we want with plain CSS seems to be, at the very best, tricky and brittle: every time we fix one issue, we introduce another. I doubt there are any silver bullets for this, but the hope is that Phosphor will allow us to make the UI more modular.
• Model-view separation (with attendant features like 'virtual DOMs'): This is where there are a lot of competing packages. It's possible to use the layout parts of phosphor with views from React, for instance. However, if we're relying on Phosphor for layout anyway, I'm not sure there's a compelling reason to avoid its model-view parts.

(My understanding may be incorrect - other people who were in the discussions, please correct me if so)

I wanted to write this here to explain why we believe Phosphor makes sense for IPython. As others have suggested, let's take the discussion of phosphor itself to phosphorjs/phosphor#8.

@ellisonbg We should have our own issue to discuss this. I don't think it is fair to pollute @sccolbert's repository with discussions that are more focused on the use of phosphor in Ipython than on the merits of phosphor as an independent project.

@rsmith31415 yes, I agree it would be useful to have a separate ipython
issue to discuss the usage of phosphor in ipython. However, for the parts
of the discussion that don't don't directly relate to IPython and are more
general questions about phosphor, I think those should go in the phosphor
repo so other people looking at phosphor can benefit.

On Wed, Apr 1, 2015 at 10:24 AM, rsmith31415 notifications@github.com
wrote:

@ellisonbg https://github.com/ellisonbg We should have our own issue to
discuss this. I don't think it is fair to pollute @sccolbert
https://github.com/sccolbert's repository with discussions that are
more focused on the use of phosphor in Ipython than on the merits of
phosphor as an independent project.

—
Reply to this email directly or view it on GitHub
#7784 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

@ellisonbg Agreed. That's why I posted there the parts that are related only to phosphor.

As @ellisonbg points out, these are concerns about phosphor-in-the-notebook-buildchain, and the developers that will have to use it, and may not represent my personal views :)

tenuous build chain,

What? Gulp and Node.js are tenuous now?

Like i said, breaks on travis. Could have been related to the DDoS of github over the weekend.

stylus

What's wrong with Stylus? Would you be okay with Less or Sass? What difference does any of this make?

I love stylus! My happiest prototyping environment is a single .jade with embedded stylus and coffee. But none of the established frameworks that we'll need to provide the rest of the UI (colors, typography, icons, etc.) use stylus. So if we want to set, say, a particular color that has some impact in phophor and whatever, we'll have to duplicate that variable logic in multiple environments.

It builds and it works.

See travis.

initial introduction to typescript has a very NIH feel to it
You must have taken a superficial look.

Very superficial indeed. Mainly just the type package manager rubbed me the wrong way. I've worked a touch with it in the past on webcola, and ran into several tooling issues if you are outside the visual studio mothership, but that was a year ago.

The API documentation for Phosphor is very thorough. Yes, there are no website/tutorials yet but that's because I spend my time making the library better.

We're here to help, if this is what is chosen! But it does make it hard to evaluate: the generated doc is... thorough... but doesn't help me get an intuitive feel for what I should be doing. As we think about try.jupyter.org we could certainly consider using that as a sample case.

@bollwyvl moved to: phosphorjs/phosphor#8 (comment)

Back on a much earlier topic: mesh.js looks like a nice, backend/platform agnostic way to wrap up evented models.

The good ol' Todos is quite concise... needs the good ol' Codemirror example, though!

I could see this being a nice way to keep downstream code from being too vendor-specific: one adaptor for, say GDRT, one for some lightweight, shippable tornado app.

Thanks for the pointer. I'm learning Phosphor/Typescript by re-writing slowly the notebook frontend here also, while we are posting links.

A lot of good discussion on this issue, thanks everyone for participating. With jupyterlab being written atop phosphor, as I understand it, there is no longer an open question left here, so I'm going to go ahead and close this.

Happy hacking!