-
dataflow
An experimental self-hosted Observable notebook editor, with support for FileAttachments, Secrets, custom standard libraries, and more! (by asg017)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
runtime
The reactive dataflow runtime that powers Observable Framework and Observable notebooks (by observablehq)
-
framework
A static site generator for data apps, dashboards, reports, and more. Observable Framework combines JavaScript on the front-end for interactive graphics with any language on the back-end for data analysis. (by observablehq)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The author’s spot on about framework.
I tried out Observable Framework and built a little interactive plot (https://github.com/willmeyers/observable-ssta). It was incredibly easy to setup and get data plotted.
My only gripe is that I wish you could configure Python data loaders to use virtualenvs.
with alex garcia's dataflow it was possible to self-host observablehq notebooks: https://github.com/asg017/dataflow
Observable themselves make that possible: https://github.com/observablehq/runtime
The official editor for making the notebooks in the first place is proprietary, and Dataflow seems to be an open source reimplementation (depending on the official runtime).
Take a look at my dashboard example, it should help show why this is useful. You can get a lot done with very little combined Markdown and JavaScript - building the same thing in HTML plus JavaScript would have taken a bunch more code.
Demo: https://simonw.github.io/observable-framework-experiments/pa...
Source code: https://github.com/simonw/observable-framework-experiments/b...
Thanks for the feedback. We have a PR open to make it easier to register new interpreters (without needing to fallback to .sh or .exe); it’ll let you specify the interpreter associated with a given file extension (e.g., .kts for Kotlin). https://github.com/observablehq/framework/pull/935
As for inputs-driving-data-loaders, that does go against the grain a bit since Framework favors static data snapshots so that the built site is self-contained and performant. But a technique that works well is to generate Parquet files in data loaders representing the superset of data that you want to interact with, and then using DuckDB/SQL in the client to extract the subset you want to visualize. This tends to perform well, though obviously it’s dependent on the size of the superset you want to interact with.