Why We're Building Observable
41–50 of 86 posts
Re: Why We're Building Observable
#42Earlier quoted context omitted.
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…
I saw you mention Falcon and NanoCubes so had to check our kyrix. I think this is a really important space. I used to assume Palantir had solved this but now that they're public it seems to be more of a smoke and mirrors startup. 3 questions: 1. Why isn't there a demo I can just click and visit? 2. Why not TypeScript? (I think this would be a worthy short term and long term investment —for this project and beyond— to…
1. In the original comment there is a link to a demo created by Kyrix: http://wildfire.kyrixdemo.live/ Are you looking for a different type of demo?
2. Honest answer: we are very understaffed academics who also need to write papers and theses. We want to convert to TS, that is just one item on the wish list.
3. We want everyone to be able to spin up a Kyrix app on their laptop using 3 CLI commands (you can try, instructions are in the README). With a backend and a database comes the cost of complex installation. Docker helps make everyone's dev environment consistent so it's easier to troubleshoot.
Re: Why We're Building Observable
#43Earlier quoted context omitted.
Not true. The Observable runtime is open source, and trivial to integrate into your existing react/whatever webapp. There is also a vscode plugin that allows for live editing and rendering. It doesn't give you the ObservableHQ interface, but tbh I like working with files more. It also allows me to git everything. https://marketplace.visualstudio.com/items?itemName=GordonSm...
It sounds like you confirmed that it can't be self-hosted - are you sure about it not being true?
It's like saying git (observable) can't be self hosted because github (observablehq) is not open source.
Re: Why We're Building Observable
#44Earlier quoted context omitted.
Not true. The Observable runtime is open source, and trivial to integrate into your existing react/whatever webapp. There is also a vscode plugin that allows for live editing and rendering. It doesn't give you the ObservableHQ interface, but tbh I like working with files more. It also allows me to git everything. https://marketplace.visualstudio.com/items?itemName=GordonSm...
It is true. You can't self-host the same way you can self-host the Jupyter Notebook or Jupyter Lab environment. Or has that changed? Can I work on something offline without communicating with their servers?
Re: Why We're Building Observable
#45Overall you can see its evolution from prior sites- someone spent a huge amount of time demonstrating cool visualizations, then tried to make it all "proprietary". Nothing wrong with that, but why not make people addicted to the service by giving them the raw drug, rather than making them hate you for dancing through hoops?
Again- huge fan of access to many cool visualizations that have greatly improved what I can express visually for presentations etc., but very unhappy that I can't do this so much easier for my particular workflow. I'd love to be shown otherwise, but I've also spent a lot of time looking for answers, reading forum responses, etc., and they seem to all reflect wanting you to go through them, not along for the ride with them.
Re: Why We're Building Observable
#46Earlier quoted context omitted.
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…
I saw you mention Falcon and NanoCubes so had to check our kyrix. I think this is a really important space. I used to assume Palantir had solved this but now that they're public it seems to be more of a smoke and mirrors startup. 3 questions: 1. Why isn't there a demo I can just click and visit? 2. Why not TypeScript? (I think this would be a worthy short term and long term investment —for this project and beyond— to…
Re: Why We're Building Observable
#47Earlier quoted context omitted.
It sounds like you confirmed that it can't be self-hosted - are you sure about it not being true?
Hosting the notebook and hosting the development environment are two different things. It's like saying git (observable) can't be self hosted because github (observablehq) is not open source.
Re: Why We're Building Observable
#48Earlier quoted context omitted.
It is true. You can't self-host the same way you can self-host the Jupyter Notebook or Jupyter Lab environment. Or has that changed? Can I work on something offline without communicating with their servers?
Check the link provided. It's just running inside of vscode, with no communication to their servers whatsoever.
Re: Why We're Building Observable
#49My 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.
- Collaborative no-setup notebooks: different images with the most popular libraries pre-installed. See each other's cursors, very useful for troubleshooting, pair programming.
- Long-running notebooks: GPU ready. You can schedule notebooks right from the notebook view so you don't context switch. You can close your browser, disconnect from the internet, or shut your laptop and still see the notebook's execution.
- Automatic params/metrics/model tracking: no boilerplate.
- One click deployment: clicking a button deploys a model and gives you a nice "REST" API endpoint you can invoke.
If you're doing anything related to ML and use notebooks, you probably had the above problems. We're building around Jupyter notebooks because in our experience, our machine learning projects were not held back for lack of slick stylesheets.
- [0]: https://iko.ai
Re: Why We're Building Observable
#50Observable is fantastic, but as others have hinted at, IMO, I think it's trying to lock you in. I want the raw JS, in one click, so that I can build out a visualization locally, just hacking on HTML/JS. Steps to doing this are highly obfuscated when they could be a single button. Overall you can see its evolution from prior sites- someone spent a huge amount of time demonstrating cool visualizations, then tried to ma…
For instance, I host content on my personal website [0] that is written in using Observable, and in fact the site provides guides to allow anyone to export content[1] and embed elsewhere online.
My content can be entirely under my control if I save my libraries out of the Observable API as a tarball[2].
I genuinely think the differences between Observable and 'pure' javascript are driven by the vision for a more powerful way of using javascript for rapid prototyping, rather than any attempt to make it proprietary. I think these ideas are revolutionary and Observable is one of my favourite working environments as a data scientist.
I also think that Mike Bostock has shown good faith, and dedication to the open source community through decades of work, which he's always given away for free.
With all that said, if ObservableHQ and its API were to disappear overnight, the lack of an editing environment would make it difficult to update existing content and so I think there is space for a offline version of the editor. As far as I understand it, nothing's stopping a third party building this.
[0]https://www.robinlinacre.com/energy-usage/ [1]https://observablehq.com/@observablehq/downloading-and-embed... [2]https://github.com/RobinL/robinl.github.io/tree/dev/tgz