I noticed that when I’m in an empty cell and use the up/down keys to change the “mode”, it only allows me to switch between TypeScript, Markdown, HTML and SQL. The rest is not available. Also, when I select one of the other options with the mouse, then click on the cell to get the cursor again, using the up/down arrows does nothing.
Is that intentional or a bug?
Apologies if this is obvious or mentioned elsewhere, but reviewing the docs I didn’t see anything about it. In the old version, the red line for an unexpected symbol in code jumps directly to the line, but in the new one, it just highlights the whole block. Is there any plan to go back to somehow indicating which exact area has the problem? It’s veryyy helpful.
Will there be dark theme support anytime in the future?
That’s intentional; the other modes are rare enough that we don’t expose them through the up/down arrows in empty cells. In Observable Desktop, Command-1 makes a TypeScript cell, Command-2 Markdown, and a few more:
Unfortunately these key bindings aren’t available in browsers. (Chrome for example uses them to focus tabs.) I’ve been meaning to assign alternative key bindings; suggestions welcome.
Yep, we’ll be doing this as part of the jump to definition feature. (And likewise broken references will be visually indicated.)
Oh, sorry, you meant static site generation, like Notebook Kit supports. Yes, we’d like to do that for the web, too. I can’t say when that will be coming, though; there are a lot of moving parts that need to be built. (When I heard “exports” I thought of imports which is unrelated.)
Yes, Notebook Kit and Desktop already supports both light and dark themes. (See it live on the Notebook Kit docs.) And we recently added light-dark() support for responsive theme switching based on user preferences. I expect we’ll bring equivalent settings to the web soon, and hopefully custom themes.
Strictly speaking, you can already implement themes yourself by writing custom styles or importing stylesheets; themes are just a more convenient way of loading named, built-in stylesheets.
Themes do not currently affect the appearance of editors, nor any of the surrounding platform chrome such as the top bar and side panels. That might change in the future, but I’m not sure if these platform elements will respond to the notebook’s theme or to the user’s preferred color scheme which are often different.
Yes, we’re working to bring this feature back. This feature will also include ensuring that code is visible when a cell errors even if the cell is not pinned.
Good to know you’re interested in dark mode for editors.
I expect it’s possible to load Notebook Kit into a notebook and create meta-notebooks that way, but that‘s not really a use case we’re optimizing for. I put together a little proof of concept here if you’re interested in learning Notebook Kit’s API:
That’s right, I’m not trying to use it in a notebook; instead, I was looking to export my notebooks in a way that the raw source will be contained.
Yesterday I wasted a lot of time creating the same thing: renderer.js 
We’ll have a download button soon that uses the Notebook Kit file format; is that what you want?
Sorting by create time has now been added.
I think there is a problem with transitive imports. The top level notebook loads ojs imports import { linkTo } from "/lopepage-urls" from the api **WITHOUT **resolutions arguments in the URL, and the API responds with source code containing import statements WITH resolution arguments in the URL. This breaks the browsers mechanism for deduping module imports, and so if ojs imported modules then go on to import the same modules, those shared transitive modules are given different module objects and the dataflow graph is cloned instead of being shared.
In this screen shot lopepage-url is an main notebook’s ojs import . You can see the response imports now have the extra resolution argument, then you can see a few lines down access-runtime is imported but its import URL has the extra resolution argument. Every main import generates a unique resolution argument, so common modules can be replicated as many times as there are main level imports. A hackyfix is to append resolution=0000000000 for all top level imports URLs and then it stabilizes across the import chain, but probably there is a better fix serverside. I think the resolution parameter is not considered in NotebookKit so I will see if it is fixable there
We haven’t reimplemented imports yet; it’s still using the old public API (without support for private imports or version locking). We’ll let you know when it’s released.
Is it possible to change structure of the output html from notebook kit? I want to use a custom layout for build
You can use a page template as described here:
An example is the template used for the Notebook Kit documentation:
I am not often in the forum but was excited recently to find new.obserablehq.com available to sample and I’m well into converting my notebooks to new. BRAVO!
I am also interested/concerned with a desire to be able to integrate online and local workflows and I read this sub-thread with great interest. Ideally, I would like the best of both worlds: collaboration for notebooks online (with absolute zero install for code-naive collaborators) and automatic version-controled updating of local notebook files as part of a github managed project that generates a static site from the latest state of the local repo. Why? Because I will be continuing to work on a large-scale project in which notebooks are like the chapters of a very extensive book, and because my use of Observable is as humanistic/writerly as it is tech/code-driven. Doing editing and collaboration online makes perfect sense, but definitive versioning, publishing and archiving responsibilities are best done locally until they are finally, properly published and archived. One of the great things about the new notebooks is that they are more or less archive-ready, their content more or less human-readable, and the dependencies for reading them (as designed, with live code) in the future appear to be manageable and able to be preserved. (This was not the case with Observable 1.X.)
I can see that import and export of notebooks in the new format (notebook html with vanilla code in the script cells) could be set up as a viable workflow so long as this is truly bi-directional (if I can cleanly replace a local notebook with the recently edited online version and vice versa, and I can batch this process) but this is not a git-like push-and-pull and I will have to keep my wits about me.
And then I notice that there is no mention of Framework in this whole discussion!? What will happen to Framework? Will, for example the “observable convert ” command download and interpret the new notebook html format? Will Framework be able to wrangle notebook.html (rather than .md) files into its static sites? I’m sure you are still frying other fish, but there would be exciting prospects for the integration of Framework with 2.X.
Thanks for the feedback and for checking out the new Observable, @shadoof!
We view Notebook Kit/Notebooks 2.0 as bringing the ideas & improvements of Framework back into a more unified workflow with Notebooks (including static site generation). Notebooks 2.0 is not a drop-in replacement for Framework, and we’re not striving for exact feature parity with Framework, but realistically our team doesn’t have the bandwidth to support both and we need to focus on Notebooks. If there are features or use cases from Framework that you want better supported in Notebooks, please tell us so we can better prioritize development.
For observable convert, see the new notebooks download.
Many thanks for the quick reply! TBH what you say about Framework is a relief in that I am looking for a definite way forward for the large project I mentioned and – on balance and now especially given what you say – I prefer the Kit/Notebook 2.0 trajectory. I did see and have often used the notebooks download command (and I’ll be looking for the notebooks upload command 
– perhaps it’s there already?)
If I have one recommendation at the moment, it would be for a patch to the notebooks build command that looks to see if there is an index.html notebook in the root directory and, if there isn’t, builds a neat little index.html notebook and provides links to any other .html notebooks in the root. This file could also demo configurable aspects of the Kit. It might even build, say, a top-left drop-down menu with links to the notebooks and load a default non-index.html notebook into a main display space.
Related to this, I have been developing a simplest possible intro instructions to Observable Desktop with AI and Notebook Kit for code-naive newbies, currently at this site Setting up Observable Notebooks (made with the Kit but not on new.observablehq). You’ll see how I ask students to save their first notebook as index.html because otherwise they are liable to get a not found error when they preview for the first time.
I hope all this is of interest and thanks for all you are doing!
