Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We're Building Observable

observablehq.com

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Why We're Building Observable

#21

Post by hobofan »

catacombs wrote: post #19
petulla wrote: post #7

My gripe with Observable is I can't fit into a Python-based workflow. I.e., a machine learning or gpu-training worfklow. It is a nice place to create explainers, though. I almost think of it as being like a Medium alternative.

> My gripe with Observable is I can't fit into a Python-based workflow. Observable is for JavaScript ecosystem. I wouldn't count on them implementing anything for Python.

With the growth expectations that come with the funding amount they just collected, I'd count on it. There is just so much more demand for data visualization and notebook-style projects in the Python community compared to the JS community.

Re: Why We're Building Observable

#22

Post by pea »

petulla wrote: post #7

My gripe with Observable is I can't fit into a Python-based workflow. I.e., a machine learning or gpu-training worfklow. It is a nice place to create explainers, though. I almost think of it as being like a Medium alternative.

For Python, Datapane may solve your use-case (I am one of the founders). It's an open source framework for creating HTML reports from text, dataframes, plots (altair/bokeh/plotly/folium), and files. We provide a free public platform for sharing reports on the web, and you can check out some of the things our users are building here: https://datapane.com/gallery/

It's different to something like Observable in that you import it into your existing Python environment (Colab, Jupyter, Airflow, etc.), build the reports from your assets, and push them up -- as opposed to having to do the analysis itself in our interface.

Re: Why We're Building Observable

#23

Post by ontouchstart »

mrkwse wrote: post #2

I really like Observable a lot, and have made a couple of brief, messy visualisations with it (messy in terms of code at least). I hope at some point they can offer some sort of offline support. The focus on ease of sharing is great, and the volume and breadth of content has really helped me to get more proficient with d3. The inability to open and edit notebooks offline/locally is a real inconvenience, however. I ha…

You can host production notebooks offline/locally or on your own SSG/CDN.

Here is a project that we built last year (by its nature, it had a limited shelf life so it made no sense to have long term cloud support.)

https://spike150.mocanyc.org/

If you inspect the source in the browser, you will see that the notebooks are hosted on the same server.

P.S. If you want online interactive notebook on your own site, I guess that is their business model either as a viral sharing of free notebooks or paid private team sharing. (I was on a team plan during the development of the project. But once the project is done, there is no need for us to continue on team plan and be interactive. I am glad that they offer support of offline production notebook.)

P.P.S. If Observable Team is listening, here is a business idea for them: observable playground as a service. It would be less a technical challenge than a business development challenge.

Re: Why We're Building Observable

#24

Post by jeffbee »

carls wrote: post #9

I'm a big fan of Observable, having used it to prototype and learn a number of different visualizations. Note that you don't just have to use D3, but can use other visualization libraries as well (i.e. Vega-Lite, Highcharts). I also want to shout out Mike Bostock, one of the company founders (and creator of D3). I emailed him randomly to ask for some help with a d3 package and he replied the next morning. Busy creato…

Bostock jumps into random Twitter threads to answer questions from Observable users. He's really helpful and generous.

Re: Why We're Building Observable

#25

Post by tlarkworthy »

I am a huge fan of Observable and I think it has massive potential beyond visualizations. To me it's the holy grail of a development environment, there is no separation between development and output. There is no toolchain separating source and binary, infact, the binary is partially recomputed on changes.

On top, it is forkable for others to build upon. It support comments, its reactive. When I explain it to people I say its like a combination excel + vscode + google docs + github. There is nothing like it!

I been trying to see how far I can push it for non- visualization software. Turns out... pretty far....

Firebase + Stripe => https://observablehq.com/embed/@tomlarkworthy/saas-tutorial

On Demand Minecraft Servers => https://observablehq.com/@tomlarkworthy/minecraft-servers

Zero deploy serverless cells => https://observablehq.com/@tomlarkworthy/serverside-cells

With serverless cells I can serve HTTP endpoints from a notebook! E.g. custom HTML like:

https://serversidecells-ibyw6dtm4q-ey.a.run.app/notebooks/@t... is generated from a notebook!

I am so productive in Observable because there is no context switch between development, using the product and debugging, it's all just one thing. Amazing, utterly amazing. I hope the Observable team can accommodate my use cases, as its clearly not what they had in mind.

Re: Why We're Building Observable

#26

Post by tracyhenry »

billconan wrote: post #5

An issue of visualization on the web I don’t know how to solve is how to load large data.

We are building a data vis tool (https://github.com/tracyhenry/kyrix) to solve this exact problem many web vis tools have.

The idea is not surprising: using database indexes and a backend to send the frontend necessary data to render on demand. DB and the backend are containerized so the installation, data loading and authoring are all one command.

For creators, we offer D3 and JSON-based declarative primitives that enable creation of pan/zoom like visualizations very easily (e.g. 10s of lines of JSON for a 15-zoom-level vis). You can check out an interactive demo here, which visualizes 1.88 million wildfires: http://wildfire.kyrixdemo.live/

Since big data vis is very use case dependent, I'd like to reference two other tools that might be useful:

Falcon: https://github.com/uwdata/falcon NanoCubes: https://nanocubes.net/

Disclaimer: I'm still in academia so I'm apparently biased towards academic works. But fortunately they are all open source.

Re: Why We're Building Observable

#27

Post by domoritz »

petulla wrote: post #7

My gripe with Observable is I can't fit into a Python-based workflow. I.e., a machine learning or gpu-training worfklow. It is a nice place to create explainers, though. I almost think of it as being like a Medium alternative.

Take a look at https://www.streamlit.io/.

Re: Why We're Building Observable

#28

Post by domoritz »

tracyhenry wrote: post #26
billconan wrote: post #5

An issue of visualization on the web I don’t know how to solve is how to load large data.

We are building a data vis tool ( https://github.com/tracyhenry/kyrix ) to solve this exact problem many web vis tools have. The idea is not surprising: using database indexes and a backend to send the frontend necessary data to render on demand . DB and the backend are containerized so the installation, data loading and authoring are all one command. For creators, we offer D3 and JSON-based declarative primitives th…

Vega-Lite and Falcon author here. Many people ask for scalable visualizations and I think declarative visualization approaches are really promising since systems can transparently optimize data movement and rendering. I have done some more experiments to scale Vega such as https://github.com/vega/scalable-vega but I think what we need is a system that automatically offloads heavy computations to a backend such as https://github.com/omnisci/jupyterlab-omnisci.

Re: Why We're Building Observable

#30

Post by kowlo »

You can't self-host with Observable. For many, that means it's not a feasible replacement or improvement over an existing literate programming environment.

It is a bit silly to downvote this for not being true, when it is factual.

Post reply on HN