The first line imports the library and adds the Bokeh object to the window. The second line defines Bokeh to be that object. The third line then modifies the Bokeh object. If you do those as separate cells, it’s hard to say exactly what any reference to Bokeh will refer to.
Here’s a simpler example where it’s a bit easier to see what can happen:
obj = ({})
obj.a = 1
obj
Here’s a screenshot of what that looks like when you enter those as separate cells:
Note that the named version of obj is not updated with the value of the a property. Any cell that refers to obj.a will have a problem.
Observable behaves more like a spreadsheet than a sequential programming environment:
The idea is that you can redefine a cell (by editing the code, by changing a value it references, or by interacting with the page), and then Observable will automatically recompute the cell’s value and every other cell that references that value.
This means you want to avoid side-effects in your cells—things like mutating the DOM and mutating values defined by other cells. From the Learn D3 tutorial:
A subtle consideration when working with data in Observable is whether to put code in a single cell or separate cells. A good rule of thumb is that a cell should either define a named value to be referenced by other cells (such as data above), or it should display something informative to the reader (such as this prose, the chart above, or cells which inspect the data).
A critical implication of this rule is that you should avoid implicit dependencies between cells: only depend on what you can name.
Why? A notebook’s dataflow is built from its cell references. If a cell doesn’t have a name, it cannot be referenced and cells that implicitly depend on its effect may run before it. (Cells run in topological order, not top-to-bottom.) Implicit dependencies lead to nondeterministic behavior during development, and possible errors when the notebook is reloaded!
For example, if one cell defines an array and a second cell modifies it in-place, other cells may see the array before or after the mutation. To avoid this nondeterminism, make the dependency explicit by giving the second cell a name and copying the array using Array.from or array.map. Or combine the two cells so that only the already-modified array is visible to other cells.