<div dir="ltr"><div><div><div><div><div><p>Started a draft earlier, lost it.</p><p></p><p>js9 looks very cool! I'd love to see it integrated!<br></p><p>I would recommend doing an nbextension and wrapping your view in a widget, packaged up as a python module. Then you either have to tell the user to install the files to the magic location, or do it for them (as qgrid, with its nbinstall) based on something they do.<br></p><p dir="ltr">Though they are not the same thing, the big advantage to nbextensions and widgets are:<br></p><ul><li>widgets: interactive integration with all the other widget things: layouts, controls, etc.<br></li><li>
Some Day being able to use your front end work with another kernel<br></li></ul>
<p dir="ltr">When integrating with the notebook front end from python "simply", a higher order pattern than publish_display_data is:</p>
<p dir="ltr"><i>def show(data):<br>
  display.display(Javascript("..</i><i>.data..."))</i></p>
<p>Every time you want to change something, you call show. If you want to have the frontend do something to the backend, you do something like</p><p><i>IPython.kernel.execute("something")</i><br></p><p dir="ltr"></p><p>Eventually, you will end up reimplementing most of what widgets do.<br></p><p dir="ltr">With widgets,</p>
<p dir="ltr"><i>class SomeWidget(Widget):<br>
  _view_module = Unicode ("nbextensions/extension/file"</i><i>)<br>
  _view_name = Unicode ("SomeView")<br>
  Data = SomeTrait()</i></p><i>
</i><p dir="ltr"><i>x = SomeWidget()<br>
display.display(x)<br>
x.data = data</i></p>
<p dir="ltr"></p>
<p dir="ltr">You can work with the widget instance as a normal python object... But it has a secret life up in the browser, and you don't have to worry about state, which is huge. Now your view/backend is part of the larger widget ecosystem, and other widgets 
can be linked to it without any additional integration work, and you're really pushing<br></p>All that being said, this is not as easy as it could be. The issue arises from "the notebook" as the user perceives it, actually being:<br></div><ul><li>the kernel: do compute<br></li><li>the server: provision compute, serve static assets<br></li><li>their code and data</li></ul></div></div></div><div>The single user, native kernel, local install experience has suffered somewhat from the needs of the distributed, multi-user, multi-kernel experience. In the case of javascript, the kernel doesn't even know it's running a notebook (could be running shell or qt... or whatever).<br><br></div><div>So we're stuck right now with:<br></div><div><ul><li>install your backend package into the kernel</li><li>install the extension into the server<br></li></ul></div><div></div><div>Here is an exhaustive issue describing some of the issues (with pictures!):<br><a href="https://github.com/jupyter/notebook/issues/116">https://github.com/jupyter/notebook/issues/116</a><br></div></div><div><br></div></div>