[HN Gopher] Observable 2.0, a static site generator for data apps
___________________________________________________________________
Observable 2.0, a static site generator for data apps
Author : tmcw
Score : 353 points
Date : 2024-02-15 14:57 UTC (8 hours ago)
(HTM) web link (observablehq.com)
(TXT) w3m dump (observablehq.com)
| foolswisdom wrote:
| I really like this idea.
| jeffbee wrote:
| 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.
| yodon wrote:
| 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.
| renewiltord wrote:
| 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(r) Framework(tm) every sentence. That would be
| strange.
| prakis wrote:
| Yes, it is confusing. It took me sometime to realize their
| product name itself is framework.
| alexgarcia-xyz wrote:
| 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.
| 0cf8612b2e1e wrote:
| 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.
| rmnclmnt wrote:
| 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
|
| [0] https://github.com/rclement/datasette-dashboards
| pzmarzly wrote:
| How often do you refresh the data (how often your CI runs)?
| mbostock wrote:
| 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.
| lf-non wrote:
| The new direction seems very similar to what evidence has been
| doing for a while
|
| https://evidence.dev
| mbostock wrote:
| 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).
| amcaskill wrote:
| One of the founders of Evidence here. Thanks the kind words
| Mike - that means a lot coming from you.
|
| I think that distinction is right -- we are focused on making
| a framework that is easy to use with a data analyst skill
| set, which generally means as little javascript as possible.
|
| As an example, the way you program client-side interactions
| in Evidence is by templating SQL which we run in duckDB web
| assembly, rather than by writing javascript.
|
| Evidence is also open source, for anyone who's interested.
|
| Repo: https://github.com/evidence-dev/evidence
|
| Previous discussions on HN:
|
| https://news.ycombinator.com/item?id=28304781 - 91 comments
|
| https://news.ycombinator.com/item?id=35645464 - 97 comments
| vramana wrote:
| Thanks for sharing. Evidence looks pretty great! Git controlled
| BI reporting.
| rogue7 wrote:
| Interesting pivot from the Observable team.
|
| I loved observable and wrote a couple of notebooks, it worked
| great ! I'm gonna try Framework asap !
| mbostock wrote:
| 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:
|
| 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!
| ZeroCool2u wrote:
| 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.
| skybrian wrote:
| Though it's not designed for animation, Observable Plot is
| just a JavaScript library and it renders fast enough that you
| can do things like that just by re-rendering. Here are some
| old notebooks with experiments with audio data hooked up to
| UI controls:
|
| https://observablehq.com/collection/@skybrian/observable-
| plo...
| mbostock wrote:
| We're working on zooming and panning for Observable Plot
| (https://github.com/observablehq/plot/pull/1738) and other
| interactions such as brushing
| (https://github.com/observablehq/plot/pull/721) -- all of
| this is already possible, we just haven't packaged it up in a
| convenient way yet
| (https://github.com/observablehq/plot/pull/1871). And as
| skybrian pointed out, you can also get interactivity "for
| free" with Observable's reactivity and re-rendering.
|
| We've been focused primarily on the static display of
| visualizations because that's what viewers see first, and
| often that's often the only thing they see. Relying too
| heavily on interaction places an onus on the user to find the
| insights; a good display of data should be opinionated about
| what it shows and guide the user to what is interesting.
|
| We're not trying to convince you to switch to JavaScript here
| -- a main value prop of Observable Framework is that you can
| write data loaders in _any_ language (Python, R, Go, Julia,
| etc.). So do all your data preparation and analysis in
| whatever language you like, and then do your front-end in
| JavaScript to leverage the graphics and interactive compute
| capabilities of modern browsers. It's pipes and
| child_process.spawn under the hood. And you still get instant
| reactivity when you save changes to your data loaders (when
| you edit Python) because Framework watches files and pushes
| new data to the client with reactive hot data & module
| replacement.
|
| And you can compress (aggregate or filter) the data as much
| as you like, so it's up to you how much data you send to the
| client. For example your data loader could be a minimal CSV
| file that's just the numbers you need for a bar chart. Or it
| could be a Parquet file and you use DuckDB
| (https://observablehq.com/framework/lib/duckdb) on the client
| to generate dynamic visualizations.
| zurfer wrote:
| I also love how Observable Plot looks, but agree with top
| poster, the things that keep me from switching are: -
| Python wrapper - Out of the box interactivity
| mbostock wrote:
| We're working on the interactivity, but we're not going
| to do a Python wrapper as the goal of Observable
| Framework (and Plot) is to leverage web technologies with
| JavaScript in the front-end for interactive graphics --
| while doing whatever language you like, including Python,
| on the back-end for data analysis. There is a R wrapper
| for Observable Plot (https://github.com/juba/obsplot) and
| so I imagine someone could write one for Python, but
| ultimately we don't think you'll need it with Framework's
| polyglot data loaders since you can seamlessly move
| between languages (front-end and back-end).
| oulipo wrote:
| Interesting!
|
| What are your thoughts on PRQL (integrated with DuckDB)?
|
| Also: sure, I get your point on opinionated viz, but this
| means someone already "played with the data" to figure out
| what to viz "cleanly", and then coded that
|
| now what if we want to build a viz to do this first "data
| playground" allowing to ruffle with the data? we would need
| some sort of interactivity
| jwilber wrote:
| Observable is much more than its library, plot. You mean to
| compare plot to plotly.
|
| There are a number of reasons to choose Observable's plot
| over plotly, but to address your point, there is no lock-in
| here with using plot for the view - you can seemingly use any
| JS library, including plotly, vega, D3, etc., so I don't
| think that's a huge issue.
|
| I agree with your point regarding convincing other scientists
| to use JavaScript - that was the biggest point of failure for
| Observable notebook adoption that I saw. (As an anecdote,
| rather than adopt Observable, my science team @bigtech
| decided to write a Jupyter -> interactive static site
| transpiler, so the scientists could continue their work in
| python). Observable 2.0 seems built on recognizing that
| friction, and making it so that the it's much easier for non-
| js users to collaborate. But the npm dependency will still
| scare many data folks away.
|
| To anyone from observable reading: I think getting mass
| adoption involves making this as seamless for python users as
| possible. (E.g. something similar to marimo notebooks or
| evidence). Also: great work!
| mbostock wrote:
| I don't think the `npm install` will scare people away
| (Evidence uses that, too), and we've definitely tried to
| make the onboarding process as guided as possible (shout-
| out to clack.cc for a great CLI prompt library):
|
| https://observablehq.com/framework/getting-started
|
| And plus you can import libraries directly from a CDN
| rather than needing to use npm or yarn to manage
| dependencies. (Though we plan on supporting the latter in
| the future, too.)
|
| https://observablehq.com/framework/javascript/imports
|
| See this example for getting started with Python:
|
| https://github.com/observablehq/framework/tree/main/example
| s...
|
| But of course we'd love to add more affordances and
| documentation for other languages. We're naturally biased
| towards JavaScript as our focus has historically been on
| visualization, but I like to think we're making progress on
| the polyglot dream.
| xixixao wrote:
| Super cool! Especially for low cardinality, low interactivity
| dashboards this approach makes a ton of sense.
|
| How is Observable going to make money off of the framework?
| mbostock wrote:
| Hosting & compute -- operationalizing/productionizing data
| apps. Observable Framework is open-source, but our hope is
| that we offer a compelling complementary paid service for you
| to host your (typically private) data apps on Observable. We
| make it easy for you to share data apps securely with your
| team or customers or clients or whoever, and manage the
| complexities of keeping your app & data up-to-date with
| continuous deployment, scheduled builds, access control,
| collaboration, monitoring, analytics, etc.
| JackFr wrote:
| > we offer a compelling complementary paid service
|
| In case you ever forget the difference between
| complementary and complimentary, that's it right there.
| mbostock wrote:
| Haha, my compliments.
| tootie wrote:
| 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?
| mbostock wrote:
| More developer-focused, and yes, you can use git for version
| control and develop locally, setup continuous deployment, and
| self-host apps anywhere.
| ayhanfuat wrote:
| I was looking for a way to integrate Observable Inputs to
| VitePress and this came as a big surprise. Love what you are
| doing.
| vermarish wrote:
| 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?
|
| [0]: http://r2d3.us/ [1]: https://algorithms-
| tour.stitchfix.com/ [2]: https://vermarish.github.io/big-
| brother-barometer/
| mbostock wrote:
| We're not expressly targeting the blogging use case -- we
| primarily want to support data apps, dashboards, and reports.
| But Observable Framework is quite flexible and you can use it
| for a lot of things; the Framework documentation is itself
| written using Framework, for example. So I would say that if
| you are working with data and you want an automated process
| to keep your data up-to-date, or to work with multiple
| languages (e.g., Python and JavaScript), or if you want to do
| a lot of interactive visualizations then you should give
| Framework a go. But we don't have much built-in affordances
| for blogging, so you might find some things missing. Feel
| free to file feature requests! We'd love to hear your ideas,
| though we're primarily focused on reporting and data app
| development for work.
|
| I'm not sure what better integration with other blogging
| frameworks would look like -- like, part of the page is
| rendered by Framework, but the site as a whole is handled by
| the blogging framework? Perhaps we could develop Framework's
| API further so it could function like a plugin. But this is
| speculative and not a priority for us currently. If you
| explore the possibilities here please let us know!
| ipsum2 wrote:
| How do dashboards work if data is computed at build time?
| Does that mean every time you want to update the data you
| need another build? I'm interested in live dashboards, is
| Obversable framework the wrong tool for the job?
| espinielli wrote:
| This looks like a dream!
| polskibus wrote:
| 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?
| mbostock wrote:
| If you generate Apache Parquet files you can use DuckDB to
| make range requests and not download everything to the
| client. This is pretty magical and allows you to have
| surprisingly large datasets still queryable at interactive
| speeds.
|
| But the general idea is to not send everything the client --
| to be more deliberate and restrictive in what you send, and
| also what you show. So you probably shouldn't use this for a
| general-purpose pivot table that's trying to show
| "everything" in your data warehouse and enable ad hoc
| exploration. You'd instead design more specific, opinionated
| views, and then craft corresponding data loaders that
| generate specific pre-aggregated datasets.
| d--b wrote:
| At last!
|
| Time to call it quits for https://www.jigdev.com :-D
|
| Godspeed Observable, hope you guys make it big
| asimpletune wrote:
| 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.
| 0cf8612b2e1e wrote:
| My question as well. If I had say a Hugo blog, how much
| effort would it be to embed the output to its own page?
| hanniabu wrote:
| Also curious if it can be worked into my jekyll sites
| mbostock wrote:
| Thank you. At a minimum, you could iframe pages built with
| Framework, or have them live alongside your other pages and
| link to them. Maybe it would be possible to use Framework's
| internal API to generate HTML that could be embedded within
| another static site generator page but we haven't explored
| that idea yet.
| daniel_grady wrote:
| 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.
| hanniabu wrote:
| 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.
| mbostock wrote:
| Did you try running `npm init @observablehq`? It'll create a
| starter app for you with everything you need to get started,
| as described in the Getting started tutorial.
|
| https://observablehq.com/framework/getting-started
|
| If you want more starter apps to look at, you can browse our
| examples on GitHub:
|
| https://github.com/observablehq/framework/tree/main/examples
| terpimost wrote:
| Wow guys. That is so cool! Thank you for what you do. This is a
| great example of high quality product!
| xrd wrote:
| 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.)
| mbostock wrote:
| 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.
| skybrian wrote:
| 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.
| mbostock wrote:
| You can read about our reactive runtime here (it's the same
| as Observable notebooks even though Framework uses vanilla
| JavaScript syntax):
|
| https://observablehq.com/@observablehq/how-observable-runs
|
| And the source is here:
|
| https://github.com/observablehq/runtime
|
| The "trick" is to structure all code as reactive variables
| (or nodes, defined as pure functions) within a dataflow
| graph. So if you replace one variable (by replacing a
| function with a new import), you then have to recompute any
| downstream variables that depend on the replaced variable,
| while cleaning up old variables and updating the display.
|
| Invalid syntax doesn't prevent other code blocks from running
| (though if it means a variable is then undefined, that might
| cause downstream errors). Syntax errors are displayed in the
| page, and also in the console for the running preview server.
| We'd like to improve the error display in the console to show
| more context around where the error occurred, since unlike
| notebooks the code isn't immediately adjacent to the output.
|
| We don't support TypeScript yet, but there's a PR
| (https://github.com/observablehq/framework/pull/129) and we
| are interested in stronger validation at build time to catch
| more errors.
|
| And yes, we're making different tradeoffs, optimizing for
| data apps and dashboards (more polished presentation) rather
| than ad hoc exploration in notebooks. So it's more work to
| find and edit the code, but conversely it's a more careful,
| deliberate process that allows code review, unit tests,
| continuous integration, etc. And we think that's appropriate
| for data apps that are depended on by many people.
|
| But still, a view source link back to your source control
| would be nice, yes!
| rmbyrro wrote:
| If more developers understood the value of using vanilla JS
| when appropriate, we would all be much happier.
| EasyMark wrote:
| 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.
| alanbernstein wrote:
| Thanks for highlighting this. Realistically, this is what will
| make me want to try it out.
| mrtimo wrote:
| It would be really cool if you guys supported Malloy. Maybe you
| already do? https://www.malloydata.dev/
| mythmon_ wrote:
| 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.
| ddanieltan wrote:
| 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?
| mbostock wrote:
| 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."
| cscheid wrote:
| (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!
| an1sotropy wrote:
| I'm looking forward to learning more about which one makes it
| easier to see how various possible changes in the data are
| mapped to legible changes in the visualization.
| cscheid wrote:
| ... sorry about the weird question, but do I know you in
| person? (there's a tiny chance your comment is specifically
| an obscure inside joke from a past life of mine, and I
| can't stop myself from taking the bait if so)
| nalgeon wrote:
| And if you want a simpler tool for creating interactive docs,
| maybe try Codapi:
|
| https://codapi.org/
| austinpena wrote:
| I'm curious where this fits in relative to streamlit which I use
| heavily
| jwilber wrote:
| 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?
| mbostock wrote:
| 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.
| beefman wrote:
| No mention of math formatting but from the docs it looks like
| there is TeX support!
|
| https://observablehq.com/framework/lib/tex
| mbostock wrote:
| And Graphviz (dot) and Mermaid, too!
| RobinL wrote:
| 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:
|
| 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!)
| lloydatkinson wrote:
| There are simply too many tools and sites called Observable
| greenie_beans wrote:
| this is exciting. love observable.
| simonw wrote:
| 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.
|
| This is really big.
| tophtucker wrote:
| 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!!
| skybrian wrote:
| Data loaders seem like an interesting way to define a multi-
| language build system without having to write a makefile.
| Lots of build systems do this, but the boundaries between
| build steps often isn't as clean and uniform as having a
| single output per build step and relying on a file naming
| convention.
|
| It's not truly reactive if you have to do a build to make
| anything happen. But maybe that doesn't matter, as long as
| it's reactive during development?
| kepano wrote:
| 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].
|
| [1]: https://stephango.com/file-over-app
|
| [2]: https://twitter.com/kepano/status/1758202572446581025
| tophtucker wrote:
| 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
| CJefferson wrote:
| Can anyone with knowledge of both systems compare this to quarto
| for me?
| janice1999 wrote:
| 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.
| rad_gruchalski wrote:
| Getting started guide:
| https://observablehq.com/framework/getting-started.
|
| Looks very nice!
| nrjames wrote:
| 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.
| j-pb wrote:
| 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.
| omneity wrote:
| 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.
|
| Thank you and congrats on the release!
| kuatroka wrote:
| A couple of questions:
|
| 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
___________________________________________________________________
(page generated 2024-02-15 23:00 UTC)