Hey, HN. We’re thrilled to release Observable Framework today — a new open-source tool for developing data apps. I highly recommend viewing this example report adapted from our internal dashboard analyzing web logs:
This technique of “just plot everything” (7.6M requests as a scatterplot) has revealed surprising insights we’ve used to optimize our servers and better control traffic. We’re also sharing a more traditional dashboard that visualizes the adoption of our open-source visualization library (and in some ways the successor to D3), Observable Plot:
In addition to releasing Observable Framework, we’ve also made Observable free again for individuals (including private notebooks and databases connectors). Let me know if you have any questions!
You've sponsored some very cool, state of the art tools. I've had friends work at Observable. I want you to succeed.
I tried to get our team to use Observable Notebooks a few years back. The researchers I work with are more comfortable in Python. Clearly that's one of the things you're trying to solve in this release. The other half of that uphill battle was discomfort posting code externally. In some ways you've also mitigated that in this release, but I wonder how sustainable it is.
Small teams eat for free by virtue of being small. Large organizations with trepidation or bureaucracy about using SaaS hosting will self host. That leaves the people in the middle: big enough to need to pay, but small enough to not have institutional problems with external hosting. Moreover, if the Observable bill ever gets much higher than the equivalent on Firebase et. al., the medium guys can self-host too.
How do you anticipate the paid side of the new business to work out? What's the hook (beyond thinking you guys are cool and trying to keep you in business) that gets someone to pay for Observable?
Hi! Some background first: I'm putting together a blog right now using Hugo and D3. I'm a huge fan of D3's infinite flexibility, as seen in some famous scrollytellers [0-1], and I've spent some time experimenting with that format myself [2].
My question is: what does Observable Framework offer for data storytellers who want to blog? Is this meant to go up against Hugo/Jekyll in terms of full-fledged max-efficiency site generation? If not, are there plans to add integrations with other blogging frameworks?
Very impressive and will definitely server many use-cases. However, it's static site with data refresh at build time. Does this mean there cannot be user-based row-level security (i.e. selective access)?
One of the main selling points of the clunky, general purpose drag-and-drop BI tools (Power BI, Tableau etc.) is selective access. This is especially important in larger enterprises and for customer-facing dashboards.
For example, you're an enterprise manufacturing and selling IoT devices and have many different corporate customers. When you build a dashboard you want to make sure that each customer can see the data that belongs to their account and potentially, have further user-based restrictions. Obviously this goes against the idea of creating pre-aggregated datasets and instant loads but it's a massive multi-billion gap that currently is being filled by inferior tools to D3/Plot/Framework. This is something that Observable could develop in the future given what I'm seeing now and considering how relatively close already you are to this. Framework could serve both types of needs - static sites and dynamic, user-based more fully-featured sites for Enterprise needs.
One question I have is if there's a way to integrate an observable framework project into an existing static site? I see how I could easily add a project as a subdomain, but what if I wanted to interleave a project I make with observable framework into my existing domain and that static site generator I already use for that domain?
By the way, thank you making this. I've been reading and enjoying very much the documentation. It looks like it has huge potential.
Thank you Mike for pushing the visualisation envelope for so many years.
Is the new Framework going to support virtualized data access for data sets too large to be sent over network (think of a pivot table that allows to browse huge data warehouse) - it is impossible to prepare entire file upfront, so data queries must happen incrementally with users actions? Or is it completely the other direction from where your vision for Framework is?
This seems nice and the plots look great, but I have a hard time imagining switching to Observable from Plotly since there doesn't seem to be a way to make any plots interactive. By which I mean Zoom and Pan. The nearest point high light feature is nice, but what if I want to zoom in? None of the examples here seem to be able to do that and quick google search doesn't make it seem like that's straight forward. That's not even additional code when I use Plotly, it's just built-in.
There's also the issue of convincing staff to use JS instead of Python which is still just a tough sell. I think everyone on my team (of data scientists) would look at me like I've got two heads if I were to suggest that. Maybe we're not the target demographic though.
I do like the idea of shipping the data straight to the client, but I don't have a lot of confidence in our corporate network doing well and not slowing stuff down. Perhaps the graphics all are sent pre-rendered over the wire though? I'm not sure, but would be cool if Observable figured out a way to side step that issue.
Congratulations on this release! Your writing at bost.ocks.org, D3, and Observable have been big sources of inspiration over the years, and it’s always exciting to see new ideas from this team.
Is this meant to be a competitor to tools like Tableau or Metabase? Something more dev-friendly and maybe git-versioned as opposed to a configurable SaaS tool?
While the docs look great, I'm having trouble getting over the hump of starting. It would be great if you had a repo with a started app we could fork and play around with to help us understand everything before diving in from scratch.
Another tidbit buried in this announcement is that Observable Framework is 100% vanilla JavaScript syntax — so you get Observable’s reactive runtime without the quirky Observable JavaScript syntax (as in Observable notebooks). And you can use static ES imports from npm or local modules, declare multiple top-level variables in a code block (not just a single named variable per cell), call the built-in display(…) function to put things on the page, etc. It’s a huge relief to have vanilla syntax and greatly improves interoperability. And we’re figuring out how to port these improvements back to Observable notebooks in the near future.
With regard to code edits (rather than UI reactivity), this looks similar to how many web development environments watch the file system for changes and then rebuild and reload the page. Is there more to it?
How are syntax errors reported? Is there support for TypeScript syntax and type-checking? Can a page partially run that has errors in some JavaScript snippets, like a notebook with errors in some cells?
In the examples, there is a “view source” link that goes to GitHub. Understanding the code involves finding the Markdown file and then going back and forth between the published page and the Markdown file, which hopefully correspond to the same version.
It seems like the thing that’s lost compared to notebooks is letting the user see and edit the code in the browser. But I suppose that’s a niche use case for coding tutorials. Not everything needs to be a notebook.
Even so, better built-in “view source” support might be nice, even if it doesn’t allow editing. It doesn’t have to be as prominent as it is in a notebook to be useful.
I too appreciate this. It is so easy to turn javascript into a DSL that doesn't much look like vanilla javascript. Give me a great API anytime over a DSL except in some very specific cases.
I appreciate the nod to "File over app"[1] in the announcement. It's so cool that a Markdown file with code blocks can be the source for complex data visualizations and dashboards. Interoperability of this kind makes me giddy. I played around with editing an Observable site from Obsidian and it works great[2].
We’ve talked about and shared your “File over app” manifesto so many times internally over the last few months. It’s one of those tweets that gets immortalized as the perfect crystallization of an ethos that we might otherwise have only been able to gesture at vaguely. It gives the ethos weight and clarity and credibility, and it’s such a relief to be able to point to it! I’m very grateful. —an Observable employee
My mind immediately went to how these Dasboards could be integrated in Obsidian, and seeing the `import` dependency graph reflected in Obsidian's graph view.
I love Observable. And, this is a phenomenal approach, untethering Observable from observablehq.com. I'm so excited.
It probably goes without saying that EVERYONE should have a blog, and this approach from Observable means journalists everywhere can now easily create a dynamic and information-driven blog. It isn't a coincidence that Observable came from a guy that did amazing data visualizations at the NYTimes. We are on the precipice of a major power shift back to journalists and away from dubious corporations, and tools like this enable that transition.
(Shameless plug: Svekyll is going towards the same goal. Svekyll is a static site generator inspired by Jekyll. If you want to use Svelte in your blog, check it out. Svekyll bundles the incredible Apache ECharts so you can use echarts in your blog with a few lines of code (and no complicated build process). https://extrastatic.dev/svekyll/svekyll-cli. These are ideas I've been thinking about too.)
There's an almost bewildering amount of interesting ideas buried in this.
Things like data loaders which are ANY script that can output data (as JSON or something else) to standard output. Markdown files with ```js blocks in that get executed. The reinvention of the core Observable notebook to avoid custom syntax.
Yeah data loaders are like a UNIX pipe to a reactive notebook cell (?). There needn’t be any question of “do the data loaders support this or that”; it doesn’t even have a concept of “supporting” beyond supporting stdout… Still thinking through how to understand it myself!!
The thing about Markdown code blocks is that they're meant to be read (and therefore rendered—as text). "Markdown files with ```js blocks in that get executed" is just <script>.
I'm super excited to try this out! Couple of questions since I see @mbostock active in the comments.
1. Is the flexibility of languages used in data loaders/backend going to eventually come to the front end/ui? Or will the paradigm always be bring-your-own-language for the data loading but build your dashboard with observablejs/observable plot?
2. Considering ObservableJS is supported by Quarto, can we look forward to Observable Framework integrated with Quarto too? Or is the fact that the latest Quarto version also featured Dashboards more of a competitor to Framework?
3. Saw some comparison to Evidence.dev in the comments. I saw some shades of similarity with the markdown focused dev experience too but I recall Evidence chose Apache Echarts for their main charting library. Any thoughts of the pros/cons of Echarts vs ObservableJS/Plot?
(disclosure: Quarto dev here). I'm a huge Observable fan.
Speaking entirely for myself, this space is so important that I'm thrilled to have more activity rather than less. Quarto's great and Observable's great. I hope folks pick the tool that's best for their use case!
1. We don’t have immediate plans to bring other languages to the front-end — maybe TypeScript, but that’s just stripping annotations; maybe some WebAssembly. Our idea is to have a clear serializable “membrane” separating your back-end (in any language, running on build on your servers) from your front-end (in JavaScript, running on load in the client). Data loaders produce data during build, which gets handed-off to the client to render. Trying to do data processing on the client is often a frustrating and poor user experience. Likewise trying to render great interactive charts without web technologies is quite limiting!
2. I can’t speak to Quarto’s plans. Observable Framework is open-source so they might pick up some of this stuff. I look at Framework more as an alternative to Quarto than a complement.
3. As the creator of Observable Plot (and D3 before that), I’m a huge fan of visualization grammars! Apache Echarts is a chart typology, and while it’s got a lot of chart types in it, it has no overarching conceptual model of how to represent a visualization. And so it’s not very interesting. But “the proof of the pudding is in the eating” as I say in the post, so I encourage you to look at Observable Plot and decide for yourself if you like both the syntax and the resulting plots. I certainly do!
Leland Wilkinson said it best: “If we endeavor to develop a charting instead of a graphing program, we will accomplish two things. First, we inevitably will offer fewer charts than people want. Second, our package will have no deep structure. Our computer program will be unnecessarily complex, because we will fail to reuse objects or routines that function similarly in different charts. And we will have no way to add new charts to our system without generating complex new code. Elegant design requires us to think about a theory of graphics, not charts.”
From the Observable Framework point of view, you’re very welcome to use Apache ECharts or any other library instead of Observable Plot, since you can import whatever you like and it’s all just JavaScript.
There are two pieces of that example code specific to Framework: the html`` tagged template literal creates a DOM element (see https://github.com/observablehq/htl, also usable outside Framework), and the display function inserts it into the document above the code block (see https://observablehq.com/framework/javascript/display). Note that, whereas Observable Plot takes an options object and returns a DOM element, ECharts instead takes a DOM element and mutates it — but in general they should be equally easy to use in Framework.
Like Plot (and Vega-Lite, another great option), ECharts is also now one of Framework’s built-in “recommended libraries” (see https://observablehq.com/framework/javascript/imports#implic...), meaning that if you reference `echarts` Framework will lazy-load it for you. Adding that was a two-line diff: https://github.com/observablehq/framework/pull/811/files#dif.... But I wanna emphasize that Framework doesn’t have to explicitly “support” a given library for you to use it. “Supporting” in this case just means the convenience of saving you a one-line import statement. But don’t wait for our blessing!! Use whatever.
3. Apache echarts are much more interactive out of the box. The API is indeed clunky, but they’ve got all the chart type and all interactions you might need.
IMHO, Plot in comparison, is very limited in interactivity and even chart types ( there are no heat maps or donuts).
echarts have a huge example library with clear examples and though Plot has it too, the library is not thought out well. You might looks at an example in the Plot Library only to realize later that it’s a D3 example.
On the good side, the API in Plot is much cleaner and easier to work with.
1. Let's say I got a Sqlite/Duckdb database file on my server. It's got multiple tables and some of them 100M to 150M records. I want to create a plot/table that would have a slider/filter to only bring and show a slice of data at a time. Since it's statically generated data, how is this interactivity achieved? All the possible facets of data filtered by which ever way will be generated? Won't it be huge and how long will it take to generates this static data or is there an actual call back to the server to the duckdb file (I assume it works with .duckdb file too?)
2. If Observable Framework provides the front-end, does it mean I can use any auth library if I want to create a web site with a log in and subscription options?
3. If it's a static web page, does it mean that at any time a user views a chart, they will also be able to go to the Dev Tools and download the file with data that's behind the viz?
4. When (if you can share of course) is the planned release of Plot's interactions: zoom, pan, interactive legend, brush?
5. Deployment - with big parquet, sqlite, csv files, it's impossible to do CI/CO through github or vercel and such. Will your hosting services offer an option to host those files and runtimes to generate them?
2. Sure, it’s all open source, I bet you could make that work. Or `yarn deploy` to Observable and configure sharing there (though it wouldn’t let you charge others).
3. Yup. Which is part of the appeal of model of running data loaders at build time: you can query some private data and viewers would only be able to see the final result set. (The lack of something like this has always been a huge problem for Observable notebooks. You’d make some great query-driven charts and then couldn’t make it public without some awkward manual dance of downloading and re-uploading a file to a fork of the notebook.)
Came here with similar questions and Cmd-F "DuckDB". See the comment about "data loaders". Seems like a "data loader" would provide most of what you're asking about.
I'm also thinking that a "data loader" combined with duckdb-wasm and arrow would be a pretty nice combination. I imagine that it might not be too difficult to switch two between two implementations of the "data loader" as needed. Switch between reading from a remote system (in your case DuckDB on a server) and DuckDB running locally in the browser (that can interact with its own remote or local data sources).
I am totally psyched up to try this. Observable (1.0) has been a very effective outlet for my research. There is no other platform that could have hosted it and offered me the quick and easy tools to make persuasive visualizations. I was a little concerned when I heard some people got laid off from the company, but it seems like it is still going.
Observable is such an incredible, powerful and enjoyable tool. I use it heavily, including to power my blog. I love it, but I've always had a slight concern about needing to rely on the Observable notebook website. So this has really made my day.
To give a sense of the kind of performant, statically hosted interactive content that has only really been within my reach since using Observable, here are some examples:
Of course, there are a huge number of additional examples:
https://observablehq.com/trending
but i think the whole thing makes much more sense to the end-user when embedded (sadly at which point they don't even know it's observable!)
This looks amazing! I really like the clear seperation of loading/prepping data, and presenting it.
Some requests:
Add simple examples and more clarity to the publish docs.
I assume most ppl would prefer to deploy via github actions[1], which the docs currently just link to a complex deploy file - can you please add some more documentation on this, or add an example of the simplest possible deploy file?
Suggestion: is it possible to use a interface (like in vercel) to connect to a github repo and build/publish on changes?
If you play the history of Observable backwards you start with a company creating a static site generator for dashboards, which then struggles to find a market fit as it tries to bring datascience to middle management, to finally reach a focused, simple and elegant tool for exploratory programming, data visualisation, and interactive documentation in javascript.
Yep, Evidence is doing good work. We were most directly inspired by VitePress; we spent months rewriting both D3’s docs (https://d3js.org) and Observable Plot’s docs (https://observablehq.com/plot) in VitePress, and absolutely loved the experience. But we wanted a tool focused on data apps, dashboards, reports — observability and business intelligence use cases rather than documentation. Compared to Evidence, I’d say we’re trying to target data app developers more than data analysts; we offer a lot of power and expressiveness, and emphasize custom visualizations and interaction (leaning on Observable Plot or D3), as well as polyglot programming with data loaders written in any language (Python, R, not just SQL).
Sounds a bit like the “baked data” pattern. Which I think is a really good idea. I have long been toying with how to use Datasette to make a deliverable dashboard, so this is interesting.
Yes! It first felt counterintuitive and constraining to prepare data ahead of time, rather than just loading whatever you want on the fly. But we’ve found this to be a great discipline in practice because it forces you to think about what data you actually need to show, and to shift as much of the compute to build time to reduce file sizes (through aggregation and filtering) and accelerate page load. And once you become accustomed to instant dashboards it becomes unthinkable to go back to slow queries.
Me too, and that lead to developing the « datasette-dashboards » plugin[0]. I use this for my company where all the data is gathered by connectors scheduled in CI, storing data in Git, and triggering a SQLite db build and Datasette deployment. « BI as Code » if you will
This is really a game changer for creating data apps. I loved observable, but convincing scientists with no js knowledge to try the platform was almost impossible. Markdown + language agnostic loaders seems like the perfect way to collaborate.
Are there any plans to allow existing observable notebooks to be deployed? For example, a one-click “deploy” button?
The Observable Framework CLI supports a `convert` command for downloading an Observable notebook and converting it to Markdown. E.g., `observable convert @d3/bar-chart` will download the notebook and save a bar-chart.md and alphabet.csv to your current working directory. (We did it from the command line so it’s easy for you to automate or batch-convert or refresh and keep things in sync.) You may have to make some tweaks to the code due to Framework’s vanilla JavaScript syntax, but we’ll work on making that more seamless over time.
And you can `observable deploy` to deploy your app to Observable for sharing — though most often you’ll want to setup continuous deployment to keep your app up-to-date automatically.
This is very cool to see! We've been building something very similar (in some regards, very different in others) in https://rysana.com/bundown
Somehow ideas like this emerge in waves seemingly with no coordination, kind of like what happened when Calculus was first invented
(Of course there's a lot of prior art here but it's interesting to see a specific jump towards polyglot single-file Markdown 'apps' and so on happen around the same time)
Observable engineer here. I haven't looked into Malloy much, but Framework's data loaders are very flexible. If you can write a script or binary that uses Malloy and writes to stdout, it can be a data loader. For example, although we use SQL a lot in our internal usage of Framework, Framework doesn't actually have any specific SQL support. We just use our database's normal bindings.
Congrats on the launch! Excited to hear that you go fully open-source with this! There is a certain need for great visualization tools that enable building apps.
I love how much is possible with the Observable framework and support for libraries like d3.js. However many data apps cannot precompute their outputs. For example, a pipeline that extracts text from documents based on what a user queries, cannot precompute the results and any visualizations must be updated every time. The best hack to accomplish this seems to be rebuilding the app on each update. Or is there another solution?
The code in a Framework can do whatever you want it to do—it can load data on demand, call an external API, etc. Precomputing data is only an option, not an obligation.
But even when you want things to be very interactive it is a good idea to minimize the data. Expose only the "rows and columns" that you need, and compress it as much as possible. This can be done in a data loader. For example, see the data app we deployed yesterday on hugging-face: its data loaders ingest a large source database (320 files totaling 200GB), and digests it into a single 8MB parquet file that we can then use on the page to "live query" 3 million newspaper titles and dates. https://huggingface.co/spaces/observablehq/fpdn
I took the query only what you need approach with PulseUI: https://www.timestored.com/pulse/ It emphasises not sending all data to the client. For real-time and very large data sets this is the only option.
I've setup a codespace starter template that pulls in the required dependencies to start building dashboards with Observable Framework, right inside your browser. You can access the starter template here:
Are you planning to add new UI components like Data Table or other in the future or it’s purely Plotting and Data ingestion and the UI through Tailwind or CSS or would it be possible to add UI libraries like shadcn or DaisyUI to make it a full fledged web site? Thanks
It’s only the first public release, rest assured we have plans to develop it beyond that point :-)
Data tables are high on the list, but it’s going to be a lot of work and I can’t say when we’ll have something to share.
In the meantime almost any library available on npm should work out of the box—not just the ones that we added explicit support for (even though of course some might need more work than others).
What would be a good design pattern to put these dashboards behind auth? I suppose since they're static files you could just serve them with something like FastAPI or Spring Boot and have your CI/CD refresh the static files throughout the day on shared storage?
If you're putting these behind a reverse proxy (nginx, etc.) you can just setup client certificate authentication by using your own locally generated CA or by using something like Vault for UI-based certificate generation. When you visit this site with a certificate installed on your device, it will authenticate successfully, and for those who do not have a correct certificate installed, a "No certificate presented" error will be shown.
Are there any similar projects that allow you to plot thousands or tens of thousands of datapoints and also allows the viewer zoom into time series plots? I'd love to have an in-browser matplotlib replacement. So far I haven't found one. Observable plots look static.
This is super cool! I’ve been looking for ways to integrate Observable with my blog posts and make them more interactive and engaging. This might just be it.
I love this and hope that a django-observable package comes along that makes it very easy to integrate and serve these static apps through a larger Django site.
Hi there! I'm Allison, I've spent lots of time working in R, R Markdown, and more recently Quarto for environmental data science work & teaching. Working in Quarto is actually what introduced me to Observable ("what is this 'OJS' business?")! Now I'm a Developer Marketing Manager at Observable and am really enjoying working in Observable Framework.
I still love Quarto. It lets me tinker, explore & troubleshoot in R easily while building things (I still have a bit of a hard time troubleshooting data loaders). I like that I can use Quarto for dashboards, but also for a personal blog, a scientific article, a nicely formatted PDF, etc. -- it feels like I only need to know one system to be able to create a bunch of different products. There are options for people like me who are more data scientist, less developer to quickly customize some biggies like fonts, background colors, etc. right in the yaml. There are really nice helpers (e.g. for cross referencing and citations, among others) that are great for researchers.
What I like about Observable Framework is that getting started is so fast - minutes from install, to a dashboard I can preview & update locally, to deploy - with really clear prompts to walk me through it. I do really like data loaders. It feels better to just prep my data in an R script (or Python, or whatever else), then access the data I need from the loader (rather than to pass outputs from R code to an OJS cell in Quarto). Using any JS libraries and components feels more streamlined in Observable Framework (not sure why - the syntax isn't that different, though Framework uses import rather than require now). And dashboard layouts are easier for me in Framework using our grid class.
I like how focused Observable Framework feels. Quarto feels awesome with is breadth of possibilities (output to PDF, or Word, or slides, or blogs, or ebooks, or websites, or ...!), whereas Framework feels sleek in its focus and design for developers creating beautiful, fast data apps & dashboards.
Lots of good stuff here, but are you really naming your framework "Framework" (as in "With Framework, you can build...")?
You do realize that naming only makes sense inside your own company, right? To everyone who uses it, it's "a" framework or "Observable's framework". No consumer of the framework is going to refer to it as "Framework" without ridiculous amounts of confusion resulting.
Observable has other open source libraries with similar "generic" names: Plot, Runtime, Inputs. When speaking generically, most people say "Observable Plot" or "Observable Runtime." In projects where people already know about them, then I say "Plot" or "Inputs" without much fuss.
I imagine most people will say "Observable Framework" when talking out in the open, and "Framework" on established projects.
It's called Observable Framework one sentence before and on the product page. It's normal to write like this in a blog post. For instance, the Kubernetes deployments page uses the word "Deployment" doesn't say Kubernetes Deployment everywhere. It just says Deployment.
I think introducing it like that is fine. You don't have to say Observable® Framework™ every sentence. That would be strange.
mbostock|2 years ago
https://observablehq.com/framework/examples/api/
This technique of “just plot everything” (7.6M requests as a scatterplot) has revealed surprising insights we’ve used to optimize our servers and better control traffic. We’re also sharing a more traditional dashboard that visualizes the adoption of our open-source visualization library (and in some ways the successor to D3), Observable Plot:
https://observablehq.com/framework/examples/plot/
In addition to releasing Observable Framework, we’ve also made Observable free again for individuals (including private notebooks and databases connectors). Let me know if you have any questions!
bsimpson|2 years ago
I tried to get our team to use Observable Notebooks a few years back. The researchers I work with are more comfortable in Python. Clearly that's one of the things you're trying to solve in this release. The other half of that uphill battle was discomfort posting code externally. In some ways you've also mitigated that in this release, but I wonder how sustainable it is.
Small teams eat for free by virtue of being small. Large organizations with trepidation or bureaucracy about using SaaS hosting will self host. That leaves the people in the middle: big enough to need to pay, but small enough to not have institutional problems with external hosting. Moreover, if the Observable bill ever gets much higher than the equivalent on Firebase et. al., the medium guys can self-host too.
How do you anticipate the paid side of the new business to work out? What's the hook (beyond thinking you guys are cool and trying to keep you in business) that gets someone to pay for Observable?
vermarish|2 years ago
My question is: what does Observable Framework offer for data storytellers who want to blog? Is this meant to go up against Hugo/Jekyll in terms of full-fledged max-efficiency site generation? If not, are there plans to add integrations with other blogging frameworks?
[0]: http://r2d3.us/ [1]: https://algorithms-tour.stitchfix.com/ [2]: https://vermarish.github.io/big-brother-barometer/
laurels-marts|2 years ago
One of the main selling points of the clunky, general purpose drag-and-drop BI tools (Power BI, Tableau etc.) is selective access. This is especially important in larger enterprises and for customer-facing dashboards.
For example, you're an enterprise manufacturing and selling IoT devices and have many different corporate customers. When you build a dashboard you want to make sure that each customer can see the data that belongs to their account and potentially, have further user-based restrictions. Obviously this goes against the idea of creating pre-aggregated datasets and instant loads but it's a massive multi-billion gap that currently is being filled by inferior tools to D3/Plot/Framework. This is something that Observable could develop in the future given what I'm seeing now and considering how relatively close already you are to this. Framework could serve both types of needs - static sites and dynamic, user-based more fully-featured sites for Enterprise needs.
asimpletune|2 years ago
By the way, thank you making this. I've been reading and enjoying very much the documentation. It looks like it has huge potential.
polskibus|2 years ago
Is the new Framework going to support virtualized data access for data sets too large to be sent over network (think of a pivot table that allows to browse huge data warehouse) - it is impossible to prepare entire file upfront, so data queries must happen incrementally with users actions? Or is it completely the other direction from where your vision for Framework is?
ZeroCool2u|2 years ago
There's also the issue of convincing staff to use JS instead of Python which is still just a tough sell. I think everyone on my team (of data scientists) would look at me like I've got two heads if I were to suggest that. Maybe we're not the target demographic though.
I do like the idea of shipping the data straight to the client, but I don't have a lot of confidence in our corporate network doing well and not slowing stuff down. Perhaps the graphics all are sent pre-rendered over the wire though? I'm not sure, but would be cool if Observable figured out a way to side step that issue.
daniel_grady|2 years ago
tootie|2 years ago
xixixao|2 years ago
How is Observable going to make money off of the framework?
d--b|2 years ago
Time to call it quits for https://www.jigdev.com :-D
Godspeed Observable, hope you guys make it big
ayhanfuat|2 years ago
fredguth|2 years ago
Observable Notebooks reactivity feels intuitive, much like spreadsheets, but the lack of self-hosting options is no-go Drawback in my work context.
hanniabu|2 years ago
espinielli|2 years ago
mbostock|2 years ago
skybrian|2 years ago
How are syntax errors reported? Is there support for TypeScript syntax and type-checking? Can a page partially run that has errors in some JavaScript snippets, like a notebook with errors in some cells?
In the examples, there is a “view source” link that goes to GitHub. Understanding the code involves finding the Markdown file and then going back and forth between the published page and the Markdown file, which hopefully correspond to the same version.
It seems like the thing that’s lost compared to notebooks is letting the user see and edit the code in the browser. But I suppose that’s a niche use case for coding tutorials. Not everything needs to be a notebook.
Even so, better built-in “view source” support might be nice, even if it doesn’t allow editing. It doesn’t have to be as prominent as it is in a notebook to be useful.
rmbyrro|2 years ago
EasyMark|2 years ago
alanbernstein|2 years ago
kepano|2 years ago
[1]: https://stephango.com/file-over-app
[2]: https://twitter.com/kepano/status/1758202572446581025
tophtucker|2 years ago
dleeftink|2 years ago
xrd|2 years ago
It probably goes without saying that EVERYONE should have a blog, and this approach from Observable means journalists everywhere can now easily create a dynamic and information-driven blog. It isn't a coincidence that Observable came from a guy that did amazing data visualizations at the NYTimes. We are on the precipice of a major power shift back to journalists and away from dubious corporations, and tools like this enable that transition.
(Shameless plug: Svekyll is going towards the same goal. Svekyll is a static site generator inspired by Jekyll. If you want to use Svelte in your blog, check it out. Svekyll bundles the incredible Apache ECharts so you can use echarts in your blog with a few lines of code (and no complicated build process). https://extrastatic.dev/svekyll/svekyll-cli. These are ideas I've been thinking about too.)
simonw|2 years ago
Things like data loaders which are ANY script that can output data (as JSON or something else) to standard output. Markdown files with ```js blocks in that get executed. The reinvention of the core Observable notebook to avoid custom syntax.
This is really big.
tophtucker|2 years ago
cxr|2 years ago
unknown|2 years ago
[deleted]
ddanieltan|2 years ago
1. Is the flexibility of languages used in data loaders/backend going to eventually come to the front end/ui? Or will the paradigm always be bring-your-own-language for the data loading but build your dashboard with observablejs/observable plot?
2. Considering ObservableJS is supported by Quarto, can we look forward to Observable Framework integrated with Quarto too? Or is the fact that the latest Quarto version also featured Dashboards more of a competitor to Framework?
3. Saw some comparison to Evidence.dev in the comments. I saw some shades of similarity with the markdown focused dev experience too but I recall Evidence chose Apache Echarts for their main charting library. Any thoughts of the pros/cons of Echarts vs ObservableJS/Plot?
cscheid|2 years ago
Speaking entirely for myself, this space is so important that I'm thrilled to have more activity rather than less. Quarto's great and Observable's great. I hope folks pick the tool that's best for their use case!
mbostock|2 years ago
2. I can’t speak to Quarto’s plans. Observable Framework is open-source so they might pick up some of this stuff. I look at Framework more as an alternative to Quarto than a complement.
3. As the creator of Observable Plot (and D3 before that), I’m a huge fan of visualization grammars! Apache Echarts is a chart typology, and while it’s got a lot of chart types in it, it has no overarching conceptual model of how to represent a visualization. And so it’s not very interesting. But “the proof of the pudding is in the eating” as I say in the post, so I encourage you to look at Observable Plot and decide for yourself if you like both the syntax and the resulting plots. I certainly do!
Leland Wilkinson said it best: “If we endeavor to develop a charting instead of a graphing program, we will accomplish two things. First, we inevitably will offer fewer charts than people want. Second, our package will have no deep structure. Our computer program will be unnecessarily complex, because we will fail to reuse objects or routines that function similarly in different charts. And we will have no way to add new charts to our system without generating complex new code. Elegant design requires us to think about a theory of graphics, not charts.”
tophtucker|2 years ago
Since there was a lot of interest in this thread, Mike added a page to the docs with an ECharts example: https://observablehq.com/framework/lib/echarts
There are two pieces of that example code specific to Framework: the html`` tagged template literal creates a DOM element (see https://github.com/observablehq/htl, also usable outside Framework), and the display function inserts it into the document above the code block (see https://observablehq.com/framework/javascript/display). Note that, whereas Observable Plot takes an options object and returns a DOM element, ECharts instead takes a DOM element and mutates it — but in general they should be equally easy to use in Framework.
Like Plot (and Vega-Lite, another great option), ECharts is also now one of Framework’s built-in “recommended libraries” (see https://observablehq.com/framework/javascript/imports#implic...), meaning that if you reference `echarts` Framework will lazy-load it for you. Adding that was a two-line diff: https://github.com/observablehq/framework/pull/811/files#dif.... But I wanna emphasize that Framework doesn’t have to explicitly “support” a given library for you to use it. “Supporting” in this case just means the convenience of saving you a one-line import statement. But don’t wait for our blessing!! Use whatever.
kuatroka|2 years ago
echarts have a huge example library with clear examples and though Plot has it too, the library is not thought out well. You might looks at an example in the Plot Library only to realize later that it’s a D3 example. On the good side, the API in Plot is much cleaner and easier to work with.
kuatroka|2 years ago
1. Let's say I got a Sqlite/Duckdb database file on my server. It's got multiple tables and some of them 100M to 150M records. I want to create a plot/table that would have a slider/filter to only bring and show a slice of data at a time. Since it's statically generated data, how is this interactivity achieved? All the possible facets of data filtered by which ever way will be generated? Won't it be huge and how long will it take to generates this static data or is there an actual call back to the server to the duckdb file (I assume it works with .duckdb file too?)
2. If Observable Framework provides the front-end, does it mean I can use any auth library if I want to create a web site with a log in and subscription options?
3. If it's a static web page, does it mean that at any time a user views a chart, they will also be able to go to the Dev Tools and download the file with data that's behind the viz?
4. When (if you can share of course) is the planned release of Plot's interactions: zoom, pan, interactive legend, brush?
5. Deployment - with big parquet, sqlite, csv files, it's impossible to do CI/CO through github or vercel and such. Will your hosting services offer an option to host those files and runtimes to generate them?
Thanks
tophtucker|2 years ago
1. It’s just JavaScript so you can fetch stuff dynamically too (see https://observablehq.com/framework/lib/duckdb). But yeah, only client-side. (Though see https://github.com/observablehq/framework/issues/234.)
2. Sure, it’s all open source, I bet you could make that work. Or `yarn deploy` to Observable and configure sharing there (though it wouldn’t let you charge others).
3. Yup. Which is part of the appeal of model of running data loaders at build time: you can query some private data and viewers would only be able to see the final result set. (The lack of something like this has always been a huge problem for Observable notebooks. You’d make some great query-driven charts and then couldn’t make it public without some awkward manual dance of downloading and re-uploading a file to a fork of the notebook.)
4. I wish I knew! It’s being tracked here https://github.com/observablehq/plot/issues/1711. Lately there’s been a lot more work on Framework naturally but now that that’s out…
5. Another good question. We’re definitely interested in tailoring it more to this sort of use case but lots is TBD!
chrisjc|2 years ago
I'm also thinking that a "data loader" combined with duckdb-wasm and arrow would be a pretty nice combination. I imagine that it might not be too difficult to switch two between two implementations of the "data loader" as needed. Switch between reading from a remote system (in your case DuckDB on a server) and DuckDB running locally in the browser (that can interact with its own remote or local data sources).
edit: welp https://observablehq.com/framework/lib/duckdb
jeffbee|2 years ago
RobinL|2 years ago
To give a sense of the kind of performant, statically hosted interactive content that has only really been within my reach since using Observable, here are some examples:
Highly interactive vis: https://www.robinlinacre.com/visualising_fellegi_sunter/
Editable computations that flow through the document https://www.robinlinacre.com/computing_fellegi_sunter/
Multiple synced representations of data: https://www.robinlinacre.com/prob_bf_mw/ https://www.robinlinacre.com/partial_match_weights/ (half way down, under 'Understanding the partial match weight chart and waterfall chart)
Of course, there are a huge number of additional examples: https://observablehq.com/trending but i think the whole thing makes much more sense to the end-user when embedded (sadly at which point they don't even know it's observable!)
77ko|2 years ago
Some requests:
Add simple examples and more clarity to the publish docs.
I assume most ppl would prefer to deploy via github actions[1], which the docs currently just link to a complex deploy file - can you please add some more documentation on this, or add an example of the simplest possible deploy file?
Suggestion: is it possible to use a interface (like in vercel) to connect to a github repo and build/publish on changes?
[1]: https://observablehq.com/framework/getting-started#deploying...
j-pb|2 years ago
nextworddev|2 years ago
beefman|2 years ago
https://observablehq.com/framework/lib/tex
mbostock|2 years ago
lf-non|2 years ago
https://evidence.dev
mbostock|2 years ago
vramana|2 years ago
0cf8612b2e1e|2 years ago
mbostock|2 years ago
rmnclmnt|2 years ago
[0] https://github.com/rclement/datasette-dashboards
rad_gruchalski|2 years ago
Looks very nice!
rogue7|2 years ago
I loved observable and wrote a couple of notebooks, it worked great ! I'm gonna try Framework asap !
jwilber|2 years ago
Are there any plans to allow existing observable notebooks to be deployed? For example, a one-click “deploy” button?
mbostock|2 years ago
And you can `observable deploy` to deploy your app to Observable for sharing — though most often you’ll want to setup continuous deployment to keep your app up-to-date automatically.
austinpena|2 years ago
johnmorrison|2 years ago
Somehow ideas like this emerge in waves seemingly with no coordination, kind of like what happened when Calculus was first invented
(Of course there's a lot of prior art here but it's interesting to see a specific jump towards polyglot single-file Markdown 'apps' and so on happen around the same time)
mrtimo|2 years ago
mythmon_|2 years ago
cheptsov|2 years ago
farhanhubble|2 years ago
recifs|2 years ago
But even when you want things to be very interactive it is a good idea to minimize the data. Expose only the "rows and columns" that you need, and compress it as much as possible. This can be done in a data loader. For example, see the data app we deployed yesterday on hugging-face: its data loaders ingest a large source database (320 files totaling 200GB), and digests it into a single 8MB parquet file that we can then use on the page to "live query" 3 million newspaper titles and dates. https://huggingface.co/spaces/observablehq/fpdn
RyanHamilton|2 years ago
dleeftink|2 years ago
[0]: https://github.com/dleeftink/observable-codespace
tetris11|2 years ago
Yeah Observable data pages look cool, but it really feels like excessive JS bloat for the features.
I think I miss throwing a D3 viz together without having to load an entire framework library.
meowtimemania|2 years ago
https://observablehq.com/plot/getting-started#plot-in-vanill...
recifs|2 years ago
petre|2 years ago
kuatroka|2 years ago
recifs|2 years ago
one_buggy_boi|2 years ago
apitman|2 years ago
a-ve|2 years ago
It's fairly easy to setup and there are multiple guides available for it. Here's one: https://fardog.io/blog/2017/12/30/client-side-certificate-au...
mbostock|2 years ago
janice1999|2 years ago
omneity|2 years ago
Thank you and congrats on the release!
nrjames|2 years ago
nalgeon|2 years ago
https://codapi.org/
fburnaby|2 years ago
vwkd|2 years ago
CJefferson|2 years ago
allisonhorst|2 years ago
I still love Quarto. It lets me tinker, explore & troubleshoot in R easily while building things (I still have a bit of a hard time troubleshooting data loaders). I like that I can use Quarto for dashboards, but also for a personal blog, a scientific article, a nicely formatted PDF, etc. -- it feels like I only need to know one system to be able to create a bunch of different products. There are options for people like me who are more data scientist, less developer to quickly customize some biggies like fonts, background colors, etc. right in the yaml. There are really nice helpers (e.g. for cross referencing and citations, among others) that are great for researchers.
What I like about Observable Framework is that getting started is so fast - minutes from install, to a dashboard I can preview & update locally, to deploy - with really clear prompts to walk me through it. I do really like data loaders. It feels better to just prep my data in an R script (or Python, or whatever else), then access the data I need from the loader (rather than to pass outputs from R code to an OJS cell in Quarto). Using any JS libraries and components feels more streamlined in Observable Framework (not sure why - the syntax isn't that different, though Framework uses import rather than require now). And dashboard layouts are easier for me in Framework using our grid class.
I like how focused Observable Framework feels. Quarto feels awesome with is breadth of possibilities (output to PDF, or Word, or slides, or blogs, or ebooks, or websites, or ...!), whereas Framework feels sleek in its focus and design for developers creating beautiful, fast data apps & dashboards.
yodon|2 years ago
You do realize that naming only makes sense inside your own company, right? To everyone who uses it, it's "a" framework or "Observable's framework". No consumer of the framework is going to refer to it as "Framework" without ridiculous amounts of confusion resulting.
alexgarcia-xyz|2 years ago
I imagine most people will say "Observable Framework" when talking out in the open, and "Framework" on established projects.
renewiltord|2 years ago
I think introducing it like that is fine. You don't have to say Observable® Framework™ every sentence. That would be strange.
prakis|2 years ago
coolca|2 years ago
terpimost|2 years ago
greenie_beans|2 years ago
unknown|2 years ago
[deleted]
foolswisdom|2 years ago
lloydatkinson|2 years ago