4 ms·

With the gentle caveat that this list of concerns feels fairly low effort — surely, with a little elbow grease, you can think of much more damning complaints! ;

With the gentle caveat that this list of concerns feels fairly low effort — surely, with a little elbow grease, you can think of much more damning complaints! ;) — I'll try to respond in good faith: 1. The non-linearity of the code is really the whole point here. Reactivity means that you wan work on any little piece of the code at any time, and you don't have to reload the page, or re-evaluate the entire notebook. It closes the feedback loop, and speeds up the process of iterating on your ideas immensely. 2. We’ve added more keyboard shortcuts, so you can now "Shift-A" to select every cell, and then press "P" to pin every cell open at once (and then to close them again). 3. The full syntax is just the "Observable JavaScript" described in the OP. The Markdown tagged template literal is part of the standard library, and you can define your own that work just like it. In that sense, the syntax is extensible. For example, here’s a different "pl" tagged template literal that runs Prolog programs: https://observablehq.com/@mbostock/hello-tau-prolog https://observablehq.com/@mbostock/hello-tau-prolog 4. Every notebook is available for download and self-hosting. You can download the code as an ES Module, or as a tarball that you can install with npm, or load and render on a web page: https://observablehq.com/@observablehq/downloading-and-embedding-notebooks https://observablehq.com/@observablehq/downloading-and-embed...

fourthark 7y ago
What's the rationale for results above code?
- jashkenas 7y ago
  Great question! On Observable, each cell is a unit that can be evaluated independently, with two sides to it — you have the source code editor, and you have the rendered display (either a chunk of DOM or canvas that you’ve drawn, or an interactive inspector for JS values). Now, the important thing is that the code half of the cell is often collapsed. You navigate around the notebook, toggling open and closed the code editors, and typing into them. If the code is on top, the entire cell jumps when it opens and closes, pushing the rendered display up and down. If the code is on the bottom, it emerges from the half of the cell that is always there, and the display is stable. Ultimately, that’s why each cell has content before source code — the content is always there, and the code may or may not be visible, so working with the notebook as a whole feels much more stable and less jumpy with the rendered value as primary and the source code as secondary.

fourthark 7y ago

What's the rationale for results above code?

jashkenas 7y ago
Great question! On Observable, each cell is a unit that can be evaluated independently, with two sides to it — you have the source code editor, and you have the rendered display (either a chunk of DOM or canvas that you’ve drawn, or an interactive inspector for JS values). Now, the important thing is that the code half of the cell is often collapsed. You navigate around the notebook, toggling open and closed the code editors, and typing into them. If the code is on top, the entire cell jumps when it opens and closes, pushing the rendered display up and down. If the code is on the bottom, it emerges from the half of the cell that is always there, and the display is stable. Ultimately, that’s why each cell has content before source code — the content is always there, and the code may or may not be visible, so working with the notebook as a whole feels much more stable and less jumpy with the rendered value as primary and the source code as secondary.