Observable Runtime, Inspector and tachyons's atomic powers.

Observable’s inspector is written with very particular, prefixed classes which don’t line up with tachyons. The reason for this is that we intend for the inspector to behave like a browser’s developer tools: it should be largely unaffected by absolutely anything that someone does in a notebook. If you create a red class in your notebook content, for example, it should always affect your notebook content but never accidentally modify the inspector, which should look and behave the same way always.

The inspector’s own stylesheet is included in its repo, though, if you’d like to modify it. It’s a pretty nitty-gritty detail, but if you do want to reuse tachyon’s values, we use the –preserve-variables option of tachyons-cli so that its variables are usable everywhere – so elsewhere on the page we can say var(--red) as a value for a CSS property, and it takes the exact same value as it would if we used the .red or .bg-red class.

If not, I’m starting to wonder how close is Observable to React.js

I wrote a bit about the relationship in this previous thread: Curiosity: How does the Observable web page render to React components? - #2 by tom - the business parts of the Observable application are written with React, but the special notebook interface & behavior is low-level code (open sourced as observablehq/runtime), and the concept of ‘reactivity’ is implemented as an invisible part of the language rather than as a library that you include.

2 Likes