“SECRET” PRE-ANNOUNCEMENT for our friends in the forum:
Observable has been working on revamping notebooks on the web. It works with (almost?) all your existing notebooks, but it is also built (like Desktop) on the new open-source foundation of Notebook Kit. It has better AI, both in the notebook sidebar and as a standalone “Chat” interface where every message is a cell. And it has better community listings. It’s still missing a ton of features (private imports, database clients, minimap), but that and more is coming close behind.
You can try it now by logging in with your existing account at https://new.observablehq.com/. There’s some documentation there. You can go back and forth between editors, but the new features won’t work on the old site.
There will be a more official announcement next week. We’re eager for early feedback from you, and I’m happy to answer any questions.
I just built my first “New” Notebook, which you can see right here:
Well, it’s still pretty rough, as you can already see from the preview image above. The first AI thing I did was ask how to change the thumbnail; its response seemed tuned to the old notebook, which seems like a little issue.
Having said that, the essentials are there and it was super easy to bring code over from an old notebook to the new.
One question: It seems that collapsed cells that produce output are not viewable when I’m not signed in. Is that intentional?
I’d like to see the tinker button on my own notebooks as well
Once enabled you can’t disable it again via the button
For someone unfamiliar with live editing it’s probably not obvious what clicking the tinker button doesnvm, didn’t realize notebooks are locked by default
Filters:
the “unviewed” filter should perhaps ignore notebooks that were last updated before view tracking got added
So I can still see the output. Is that what you mean?
What you might be noticing is that none of the editing affordances show when you’re not an author (or when you’re signed out). No toggle in left gutter, no cell inserters between cells. You have to click the pencil icon in the bottom right to edit or tinker. That’s a deliberate new approach to present a cleaner published artifact and decrease false-positive edits, at the expense of making tinkering — which is very important! — one click harder. (See docs.)
Cool! I went to give it a try and noticed that if I press the “new notebook” button, it redirects to a 404 page: https://new.observablehq.com/@yv2/-/new/2026-06-12T21:09:49.356Z (using this account for testing purposes.) If I go back to the main page, there aren’t any notebooks listed.
Might be because I first logged in to the ‘new’ version a week or so ago? I was able to fork your one from above though! Edit: But my main page still says “No notebooks found.” (The fork is here: Observable )
Yup, there’s a new concept of the “default” workspace. Forking or clicking the “New notebook” icon in the upper right makes the notebook within the current workspace, if you are an editor in that workspace. If you’re not in one of your workspaces, or if you go to https://new.observablehq.com/new, it goes to the “default” workspace, which for now is basically your most expensive workspace, lol — Enterprise, then Pro, then Starter, and unordered within those tiers. We are on the warpath to reduce modals and intermediate steps!!! But gotta add “transfer”, obviously…
Ah that’s helpful, hm, that may be a bug with how we try to simplify navigating “individual workspaces” (teams of one). Or maybe caching. (The timestamp at end of /new is a cache-busting nonce.) You’re logged in with @yv2, right? I’ll DM in a minute for details…
@tophtucker When I navigate to your Testing Mark’s question notebook, I can see the output of your code cells - a random number and an array [0,1,2]. I’m not able to see the code that generated that output. When I’m signed in to my own notebook, I can just click on the gutter to the left of the cell to expand it, but that doesn’t work when I’m not signed in. It also doesn’t work in your notebook, even when I am signed in.
I’m not sure this is different from “editing”, as you say, but not being able to see the code at all would certainly be a huge departure from the spirit of sharing code.
Apologies, there was a bug in determining the default workspace for your testing account. The bug should now be fixed, so please try again?
(We’re moving away from requiring people to have “teams of one” to create notebooks, and back to letting people create personal notebooks directly under their individual accounts. We encourage anyone with a team of one to go into settings and set the team username to match your account username, thereby folding your team of one into your personal workspace.)
We’re very much still in the spirit of letting people see and edit code. But we also want to provide a cleaner and safer reading experience, so readers now start in a read-only view where the editor user interface is hidden. (Previously it was a little too easy for readers to accidentally make edits and break the notebook, and the editor controls could be visually distracting or intimidating.) So if you’re not already an editor on a notebook, the editor controls are hidden until you click the edit button (or fork the notebook).
Note that you can use the Observable Agent on other people’s notebooks, too! This is an indirect way to enter tinker mode and is great for understanding how other people’s code works.
We’ll add a way to exit tinker mode, but we want it to be obvious that you’re discarding your edits by doing so. We also need to improve the fork button so that it applies your tinkered edits, if any; that flow is not yet implemented.
We also plan on having a user preference to let you set your default workspace. We haven’t implemented the ability to transfer notebooks between workspaces yet, but you’ll also be able to use that if the default workspace isn’t what you want for the fork you just made. As for creating a new notebook, if you haven’t saved your notebook yet (by which I mean you haven’t committed anything), you can use the workspace menu to switch workspaces and your new notebook will be saved there — no modal needed!
As Toph said, we’re trying to reduce unnecessary modals and forced choices as much as possible. The old interface got bogged down with edge cases and whereas we are optimizing for the common cases. For example, you don’t have set permissions on new notebooks either; they simply default to private (workspace-visible).
Very excited to dig deeper, and thanks for setting up the user guide and system guide. At first glance a couple of questions that come to mind:
Are comments no longer linked to specific cells? Unless I’m missing something I only see them as a list in the side bar. It felt useful to comment on particular cells so would love to see that remain in some form if possible.
Have collections (both in the header and as a sidebar to browse) disappeared or is that just not yet set up for this early test?
Will the deprecated 2018 library that keeps old notebooks working last indefinitely or will we need to migrate/refactor eventually?
P.S. really like the that new UI foregrounds a clean reading experience while still leaving the option to dig deeper for more curious readers
You’re not missing anything. Comments have a very bare minimum placeholder read-only implementation right now. We’ve always wanted at least the option of having a comments sidebr, and we’ve always been wary of how inline comments interrupt the zone that the author’s intent should really “own”. But yes, granular references are nice. I think it‘s TBD right now honestly how it’ll shake out. It might look more like comment threads + @mentions of variables. Though I also sorta want notebooks to be able to “reply” to notebooks!!
You’re correct that notebooks don’t yet say what collections they’re in, and you can’t yet edit collections within the new site. Coming very soon!! (That is just how rough and early things are right now! )
You can browse collections today at the workspace/public levels. You now see four thumbnails per collection so you can see “inside” better, and you can browse popular public collections with nice infinite scroll: Public collections | Observable.
Good question. I shouldn’t commit to anything yet lol. But we are pretty happy with how versioning has worked out, and we’ve been aiming at near-perfect backwards compatibility. (Still a couple things to do; let us know if you spot issues.)
You certainly shouldn’t waste time hurrying to convert things now, as if sand is running out of an hourglass. We’d much rather you invest time in making new things!!
Amazing, all pretty much the answers I was hoping for!
@mentions for variables in comments that still live in a sidebar makes a lot of sense to me, and I completely agree with the prior issue of “interrupting the zone that the author’s intent should own.”
Really appreciate all the thought you guys put into this platform
This is fantastic, thank you very much for all the work you’ve put into this.
I have a few questions:
Do you plan to continue maintaining the legacy notebooks, or would you recommend migrating everything to the new library? You mention that the 2018 library is now deprecated. Does that mean that older notebooks may eventually stop working?
Will it be possible to embed cells, as before, in order to integrate visualizations into websites? I used this feature quite extensively.
Will we be able to download the notebook code and run it offline? This was possible with Notebooks 2.0 and was very useful.
With Notebooks 2.0, it was also possible to build data loaders using, for example, R cells. Is this kind of functionality planned for the new version?
Still at the early stages of trying this out, but it’s looking great. I like the direction this is heading (standardising JS/TS; clean read-oriented view for non-authors; modernising imports).
I have likely missed it, but how do we prettier-format code cells? And can this be turned on as a default in settings?
Now that we can use TypeScript directly, are there any plans for actual type checking in a cell (with perhaps options of specifying strict settings)?
I’d distinguish between the old site — the current frontend of https://observablehq.com/ — and the deprecated 2018 standard library. The former should go away; the latter shouldn’t.
The frontend site has been on its ~3rd version since transitioning from “Classic” to “Next” circa 2021. (An annoying period, with overlapping environments, but sometimes necessary. And where do you go after calling something “Next”?! “New”, I guess, lol.) This will another ~full rewrite and should completely supplant the old site in time. Some long-tail edge-case features will get left behind as we prioritize more important things. But broadly, if we do our jobs, you won’t miss it.
The deprecated 2018 library isn’t going away any time soon. I have a thousand notebooks I love written in the 2018 library, and I am not spending any time migrating any of them. They work fine. I can still import from them. Better to do new stuff, using the new library, to use new & upcoming features.
I think the #1 benefit of new library for me is that I can use html instead of htl.html, lol. The old html literal was bad, but we couldn’t replace it, so you had to remember to use htl. Minor annoyance repeated a million times. #2 is ES imports. #3 is vanilla syntax. I actually liked OJS, but vanilla’s certainly more portable and welcoming to new users. And the viewof and mutable keywords always felt alien. Like, writing viewof input.outerHTML, it was verrrry weird that the space was part of the variable name, with topmost precedence!!
Yeah embedding is important, and a big part of business use cases. Not sure exactly how it’ll work yet but we gotta do it.
We actually still call the new notebooks (on https://new.observablehq.com/) “Notebooks 2.0” because it brings the core of the desktop app to the web. Literal same editor code as a shared package between desktop and web apps. So now we say “desktop” and “web”, and it’s all part of “Notebooks 2.0”. We don’t know if they’d ever talk to each other, and we see them having different strengths — desktop uses real files on your real filesystem and data loaders running on your real machine; web is lightweight and cloud-y; those support different workflows and we don’t wanna graft them together. But shared foundation is an important place to start. And, you know, for embedding, it’s often better to download the notebook as a self-contained package than to hotlink to a live notebook. So idk, we’ll see!
Running sorta arbitrary code on your real machine is one of the strengths of desktop over web in general. But the importance of data loaders — upstream of the whole reactive graph, polyglot, “expensive” to run and important to cache — is one of the key lessons of Observable Framework, which laid some of the foundation for Notebooks 2.0. So yes, we wanna bring data loaders to the web, and that’s part of the motivation for adopting this foundation, but it’ll take some time. SQL first!
Shift-Cmd-I! You didn’t miss it, it was undocumented. (And it’s different from in old editor; I forget why.) Just added to user guide. As for setting, we should get to it at some point, but hasn’t been a high priority yet.
We certainly think about it! It’ll be prioritized depending on user feedback. It does feel sorta weird calling the cell mode “TypeScript” if it’s not actually type-checking, but the first priority was just to enable portability with other TypeScript environments. Val Town had a good post about how they handled type checking.
We’ve put a lot of effort into maintaining backwards compatibility and will continue to do so. We’re aware of some missing pieces. (I’m working on supporting import-with, for example.) Please let us know if you notice broken behavior and we’ll see if we can fix it. We want notebooks to keep working and don’t want to place undue burden on the community to update notebooks as the technology evolves.
That said, it is good for the community to update, particularly when old patterns are dangerous or unreliable. Everyone learns from each other, so keeping notebooks up-to-date helps newcomers learn current best practices rather than falling into old traps. For me personally, I’d love to never see require again, and to see more widespread adoption of vanilla JavaScript and TypeScript so that people aren’t burdened by the quirks of Observable JavaScript. So while no work should be required on your part, we welcome maintenance work as well as publishing new notebooks. (And maybe with the Observable Agent and/or file-based workflows we can make it easier to maintain larger corpora of notebooks…)
pencil icon in the bottom right to edit or tinker. That’s a deliberate new approach to present a cleaner published artifact and decrease false-positive edits, at the expense of making tinkering — which is very important! — one click harder. (See 
)