Key features:
- Full npm ecosystem access
- AI-assisted coding (OpenAI, Anthropic, or local models), it can iterate on the cells for you with a code diff UX that you accept/reject for a given code cell, generate entire Srcbooks, fix compilation issues, etc…
- Exports to valid markdown for easy sharing and version control
Try it now: `npx srcbook start`
Examples Srcbooks to explore: https://hub.srcbook.com
We built this because we needed a Jupyter-like environment for TypeScript, we hope others like it as much as we do! Feedback and contributions are super appreciated.
(edit: formatting)
Srcbook is built for different use cases: we focus on a backend runtime (node) and want to solve for non-data-visualizations workflows. Use cases like prototyping with a third party npm library, running a script to test your app's behavior, or building an AI agent.
As I recall, Observable uses the browser's JS runtime for computation.
Do you use it? Does it work well for you? I'm interested in learning more about your use case if you don't mind sharing.
You don't need to use the web client, all IDEs have jupyter integration these days, Zed even has it built-in. Just one "pip install" away.
People who want to move away from that welcome any alternatives, be it Mathematica or true open source replacements in TypeScript. Please port numpy to TypeScript, too!
https://github.com/srcbookdev/srcbook/blob/ddda46a0b1249c3d7...
That said, we hear you. I just added support for disabling all analytics with an environment variable `SRCBOOK_DISABLE_ANALYTICS=true`. See https://github.com/srcbookdev/srcbook/pull/191.
If it's a hobby project or backed by a small team, even I would opt-in to help the devs out after some trust in the project is established.
Can you say a little more about the concrete use case you have? It helps us prioritize
For non-npm things, we heard that a lot of people open up a browser console to use it as a REPL. I think we can do better, hoping Srcbook can cover these use cases well.
The Markdown is a really neat idea borrowed from Livebook. It allows for really good diffing if you want to version control them, and makes reviewing diffs easier. As a bonus a lot of things can read markdown and render it nicely for you.
Two features would be huge:
1. Web cells for intermixing UI components alongside NodeJS cells. Would be cool if there was a bridge API to call code in the Node cells as well.
2. VSCode extension to render this all in there directly.
But with recent NodeJS compatibility changes, this may be really cool for a lot of use-cases.
Also see this jupyter notebook request https://github.com/typst/typst/issues/962
At first glance, this seems particularly useful for scientific-style notebooks, which aren't our primary focus. If the demand is there though, I don't see why we couldn't integrate.
Other than that, it's good for shared scripts, things that might otherwise live in your npm scripts. One example is that we use a shared Srcbook to upload data to our Hub.
https://blog.jupyter.org/bringing-modern-javascript-to-the-j...
- a markdown encoding that we use when you export. Easier to share, serialize, etc...
- on disk, Srcbooks are actually directories under ~/.srcbook/srcbooks. The files and code is all there, and runs with your local node executable. You therefore need to be careful to not run any arbitrary srcbook you download, but there is no code ever leaving your machine
The Srcbook app is meant to be open-source and help drive adoption of the future hosted offerings, and we're focusing on making that useful for now.
Observable is a great notebook env for dataviz, but the bespoke js + observability patterns can feel obtuse for non-dataviz stuff.
Likewise, the Jupyter js kernels feel second-class and require python dependencies.
Really looking forward to using this for documenting open-source and prototyping.
Anyway, impressive
Can I let-declare an variable in one code block, and refer to it in another code block with static type hint?
