Jupyter Frontends: From the classic Jupyter Notebook, to JupyterLab, nteract and beyond

Jupyter Frontends: From the classic Jupyter Notebook, to JupyterLab, nteract and beyond

The Jupyter architecture (message specification, kernels, notebook documents) allows for multiple end-user applications or Jupyter frontends. The traditional application for Jupyter is the classic Jupyter Notebook, which began as the IPython Notebook in 2011. Since then, the Jupyter Notebook frontend has become a critical tool for millions of users doing interactive computing in scientific research, education, and commercial data science, machine learning, and AI. In recent years, a number of more modern end-user applications built on top of the Jupyter architecture have emerged, including Rodeo, CoCalc, Stencila, nteract, and JupyterLab. Project Jupyter is embracing the flowering of end-user applications and taking steps to document and formalize the abstractions across all Jupyter frontends.

Kyle Kelley and Brian Granger offer a broad look at Jupyter frontends, describing their common aspects and explaining how their differences help Jupyter reach a broader set of users. They also share ongoing challenges in building these frontends (real-time collaboration, security, rich output, different Markdown formats, etc.) as well as their ongoing work to address these questions.

E76c7ebc9d2e8a4b840f13cd01946437?s=128

Kyle Kelley

August 24, 2017
Tweet

Transcript

  1. 
 Jupyter Frontends: From the classic Jupyter Notebook, to JupyterLab,

    nteract and beyond Brian Granger, Cal Poly Kyle Kelley, Netflix Project Jupyter JupyterCon 2017
  2. • User Testing @ JupyterCon •What is interactive computing? •

    User interfaces for interactive computing • The terminal as a UI for interactive computing • Jupyter Notebook: successes and challenges • Foundations of Jupyter frontends: • Jupyter Message Specification • Survey of different Jupyter frontends/UIs Outline
  3. • We are doing extensive, in person user experience testing

    here at JupyterCon • We need your help to improve our software! • Thursday+Friday all day • Location: Gramercy room on level 2 • Drop in or sign up: • http://bit.ly/jupytercon-usertesting User Testing @ JupyterCon
  4. Interactive Computing An interactive computation is a persistent computer program

    that runs with a "human in the loop," where the primary mode of steering the program is through the human iteratively writing/running blocks of code and looking at the result. Human Centered Computing
  5. Interactive Computing: Breakdown Compose A UI to compose blocks of

    code Submit A UI to submit code to the running program Run A method to run code in a persistent namespace Output A method to return output to the user View A UI to view the output Repeat A method to repeat the process Frontend = User Interface = UI
  6. IPython: The Terminal as a UI IPython was released in

    2001 and provided a UI for interactive computing Tab completion, extended syntax (!, %, ?), plotting integration
  7. IPython: The Terminal as a UI Compose Type at the

    Terminal Submit Run eval(code, globals, local) Output print(output, file=sys.stdout) View Look at the Terminal Repeat while True: IPython was released in 2001 and provided a UI for interactive computing:
  8. • No narrative: code without narrative is empty of meaning

    • Narrative text/documentation • Images, Visualizations, Equations • No memory: wasteful and frustrating • Everything you type is lost when you exit IPython • Only memory was hitting the up arrow after restarting to cycle through previous commands • Python’s runtime effectively requires you to restart often • code, exit, ipython, up, up, code, exit, ipython, up, up, up, code, … • No reproducibility and communication: your own private dead end • No way to record/reproduce an interactive computation and its results • No way share a session with others and communicate results Usability Challenges of the Terminal In spite of this, Python, IPython, NumPy, Matplotlib, etc. were revolutionary
  9. Why is the classic IPython/ Jupyter Notebook so useful?

  10. The IPython/Jupyter Notebook maintains the full interactive computing workflow while

    adding narrative, memory, reproducibility, communication
  11. File = reproducible, communication, memory equations narrative images memory Narrative,

    Memory, Reproducible, Communication compose repeat submit/run output IPython Notebook 2011: “Computational Narrative”
  12. Jupyter Notebook 2017

  13. Jupyter Notebook: Successes

  14. >6-8M??? Users https://github.com/jupyter/design/blob/master/surveys/2015-notebook-ux/analysis/report_dashboard.ipynb

  15. ~100 Languages https://github.com/jupyter/jupyter/wiki/Jupyter-kernels

  16. Highly International Community Google Analytics for jupyter.org, July 2017

  17. Over 1M Notebooks on GitHub

  18. An Amazing Community: Emergent Behaviors

  19. Jupyter Notebook: Challenges

  20. • Built with web technology of 2011 (jQuery, Bootstrap, require.js)

    • In contrast to core server/architecture in Python, which has been relatively stable • Important features became difficult to implement: • Real-time collaboration: models and views are welded together • Collapsing input/ouput: DOM/CSS had become pseudo-public APIs • No distinction between public/private APIs - anything breaks everything • Difficult to extend • Code base is large enough that you miss static typing • No dependency injection for runtime dependency resolution Jupyter Notebook: Challenges
  21. • Leaky foundations: • Message spec and notebook format had

    become “polluted” with implementation specific details • Libraries such as ipywidgets were welded to the classic notebook implementation details • Other non-notebook workflows: • QTConsole: interactive computing with rich output • Hydrogen/RStudio: Python/R scripts with interactive computing and rich output • Emergent behaviors: • Exciting, but unexpected usage cases • An ecosystem that has become an abundant, fertile, rich garden • With a codebase that is difficult to scale or maintain to span those usage Jupyter Notebook: Challenges
  22. Frontend Foundations

  23. Exploring the Protocol

  24. Exploring the Protocol { "msg_type": "execute_request", "content": { "code": "print('hey')"

    } }
  25. Exploring the Protocol { "msg_type": "status", "content": { "execution_state": "busy"

    } }
  26. Exploring the Protocol { "msg_type": "status", … } { "msg_type":

    "stream", "content": { "text":"hey\n", "name":"stdout" } }
  27. Exploring the Protocol { "msg_type": "status", … } { "msg_type":

    "stream", … } { "msg_type": "status", "content": { "execution_state": "idle" } }
  28. Exploring the Protocol Two types of messages so far •

    Execution status - busy or idle • A stream of “stdout”
  29. Exploring the Protocol How about longer computations?

  30. Exploring the Protocol { "msg_type": "status", "content" { "execution_state": "busy"

    } } { "msg_type": "stream", "content": { "text":"hey\n", "name":"stdout" } } { "msg_type": “stream", "content": { "text":"sup\n", "name":"stdout" } } { "msg_type": "status", “content" { "execution_state": "idle" } }
  31. Exploring the Protocol - Rich Media How are tables, plots,

    and rich media shown?
  32. Exploring the Protocol - Rich Media "content": { "code": "pd.read_csv('temps.csv').sample(n=5)"

    }
  33. Exploring the Protocol - Rich Media { "msg_type": "execute_result", "content":

    { "data": { // Full payloads below "text/plain": ..., "text/html": ..., } } }
  34. Exploring the Protocol - Rich Media temp date 4851 56.4

    2010/07/22 04:00:00 6232 65.9 2010/09/17 17:00:00 8497 47.0 2010/12/21 02:00:00 5875 60.9 2010/09/02 20:00:00 5625 65.7 2010/08/23 10:00:00 text/plain
  35. Exploring the Protocol - Rich Media <table> <thead> <tr style="text-align:

    right;"> <th></th><th>temp</th><th>date</th></tr> </thead> <tbody> <tr> <th>4851</th> <td>56.4</td> <td>2010/07/22 04:00:00</td> </tr> … text/html
  36. Exploring the Protocol - Rich Media HTML Payload

  37. None
  38. None
  39. Building a Notebook Document

  40. Building a Notebook Document We’ve witnessed • How code is

    sent to the runtime • What we receive as a frontend
  41. Building a Notebook Document How do we form a notebook?

    How do we associate messages to the cells they originated from?
  42. Building a Notebook Document • Send message with a msg_id

    (message id) • Responses refer to originating message as the parent Message IDs
  43. Building a Notebook Document { "msg_type": "execute_request", "msg_id": "0001", "content":

    { "code": "print('hey')" } } We send the execute_request as message 0001 code: "print('hey')" And initialize our state
  44. { "msg_type": "status", "msg_id": "0002", "parent_id": "0001", "content": { "execution_state":

    "busy" } } Building a Notebook Document Responses show originating msg_id is parent_id 0001
  45. Building a Notebook Document { "msg_type": "status", "msg_id": "0002", "parent_id":

    "0001", "content": { "execution_state": "busy" } } Message code: "print('hey')" status: "busy" Cell State
  46. Building a Notebook Document { "msg_type": "stream", "msg_id": "0003", "parent_id":

    "0001", "content": { “text": "hey\n", “name”: "stdout" } } Message code: "print('hey')" status: “busy" outputs: - type: "stream" text: "hey\n" name: "stdout" Cell State
  47. Building a Notebook Document { "msg_type": "status", "msg_id": "0004", "parent_id":

    "0001", "content": { "execution_state": "idle" } } Message code: "print('hey')" status: “idle" outputs: - type: "stream" text: "hey\n" name: "stdout" Cell State
  48. Building a Notebook Document Final State code: "print('hey')" status: “idle"

    outputs: - type: "stream" text: "hey\n" name: "stdout"
  49. Building a Notebook Document Final State code: "print('hey')" status: “idle"

    outputs: - type: "stream" text: "hey\n" name: "stdout"
  50. Building a Notebook Document That’s just one cell though —what

    would an entire notebook structure look like? What’s a notebook? • A rolling work log of computations • A linear list of cells
  51. cells: - text: "# Now with markdown!" - code: "from

    IPython.display import HTML" - code: "print('hey')" outputs: - type: "stream" text: "hey\n" name: "stdout" - code: "HTML('<b>WHOA</b>')" outputs: - type: "execute_result" data: - "text/html": "<b>WHOA</b>"
  52. cells: - text: "# Now with markdown!" - code: "from

    IPython.display import HTML" - code: "print('hey')" outputs: - type: "stream" text: "hey\n" name: "stdout" - code: "HTML('<b>WHOA</b>')" outputs: - type: "execute_result" data: - "text/html": "<b>WHOA</b>"
  53. Summarizing the Notebook send code → … run , run

    … → get result(s) →
  54. Callouts For more in-depth on protocols and formats, check out

    these talks: Jupyter: Kernels, protocols, and the IPython reference implementation The Jupyter Notebook as document: From structure to application
  55. Survey of Frontends

  56. None
  57. hydrogen

  58. hydrogen

  59. nteract

  60. Spyder

  61. Callouts For more in-depth on alternative frontends, check out these

    talks: Lessons learned from tens of thousands of Kaggle notebooks JupyterLab: The next-generation Jupyter frontend
  62. Questions