Our great sponsors
-
marimo
A reactive notebook for Python — run reproducible experiments, execute as a script, deploy as an app, and version with git.
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
mermaid
Generation of diagrams like flowcharts or sequence diagrams from text in a similar manner as markdown
-
Very exciting! I took a quick look and I have a couple of questions.
1. Can you describe your interactive widget story? I see that you integrated altair, and there is some custom written react code around it [0] [1]. I'd be interested in porting my table widget to your platform at some point.
2. How much, if any does this depend on the jupyter ecosystem?
3. How does this interact with the jupyter ecosystem?
[0] https://github.com/marimo-team/marimo/blob/b52faf3caf9aa73f4...
You're probably referring to nbgather (https://github.com/microsoft/gather), which shipped with VSCode for a while.
nbgather used static slicing to get all the code necessary to reconstruct some cell. I actually worked with Andrew Head (original nbgather author) and Shreya Shankar to implement something similar in ipyflow (but with dynamic slicing and a not-as-nice interface): https://github.com/ipyflow/ipyflow?tab=readme-ov-file#state-...
I have no doubt something like this will make its way into marimo's roadmap at some point :)
I already use jupytext to store notebooks as code but the improved state management and notebook-as-app features are pretty compelling and I'm trying it out.
Unfortunately, I'm quite used to very specific vim keybindings in Jupyter (https://github.com/lambdalisue/jupyter-vim-binding) that make it pretty hard to use anything else :/
Wow.. Really great work, finally someone is doing it!
Since I've thought about this for a long time (I've actually even made a very simplified version last year [1]), I want to contribute a few thoughts:
- cool that you have a Vscode extension, but I was a little disappointed that it opens a full browser view instead of using the existing, good Notebook interface of Vscode. (I get you want to show the whole Frontend- But I'd love to be able to run the Reactive Kernel within the full Vscode ecosystem.. Included Github Copilot is cool, but that's not all)
- As other comments said, if you want to go for reproducibility, the part about Package Management is very important. And it's also mostly solved, with Poetry etc...
- If you want to go for easy deployment of the NB code to Production, another very cool feature would be to extract (as a script) all the code needed to produce a given cell of output! This should be very easy since you already have the DAG.. It actually even existed at some point in VSCode Python extension, then they removed it
Again, great job
[1] https://github.com/micoloth/vscode-reactive-jupyter
You're probably referring to nbgather (https://github.com/microsoft/gather), which shipped with VSCode for a while.
nbgather used static slicing to get all the code necessary to reconstruct some cell. I actually worked with Andrew Head (original nbgather author) and Shreya Shankar to implement something similar in ipyflow (but with dynamic slicing and a not-as-nice interface): https://github.com/ipyflow/ipyflow?tab=readme-ov-file#state-...
I have no doubt something like this will make its way into marimo's roadmap at some point :)
Congrats OP on launching this, looking forward to dive further in! It's great to see people experimenting in the Reactive + Live Programming space as like you mention, I think it can bring a lot of improvements to how we build software. Did you run into any limitations adopting this model?
> A killer feature of Observable notebooks for me is that they provide the shortest possible route from having an idea to having a public URL with a tool that I can bookmark and use later
Thanks for sharing simon! I'm working on an Open Source Notion + Observable combination (https://www.typecell.org), where documents seamlessly mix with code, and can mix with an AI layer (e.g.: https://twitter.com/YousefED/status/1710210240929538447)
The code you write is pure Typescript (instead of sth custom like ObservableJS) which opens more paths to interoperability (aside from having a public URL). For example, I'm now working to make the code instantly exportable so you can mix it directly into existing codebases (or deploy on your own hosting / Vercel / whatever you prefer).
Does this allow to run a long running task in the background so that a user can close & reopen the tab and continue seeing all the output that has been produced thus far?
This is currently being worked on in Jupyter: https://github.com/jupyterlab/jupyterlab/pull/15448
Marimo looks and feels great!
Have you considered adding support for mermaid.js in the markdown? I tried including some mermaid.js in a `mo.md` invocation, but it didn't render the diagram :-)
https://mermaid.js.org/
Exactly my thoughts too, especially regarding reproducibility issues Quarto has been great in the past for projects at my workplace.
I have yet to try Marimo but synchronised code cells are what seems to set it apart. Quarto + jupyter-cache [1] was the closest I have managed to get to that experience but that approach has its constraints.
[1]: https://github.com/executablebooks/jupyter-cache