←back to thread

356 points california-og | 7 comments | | HN request time: 1.207s | source | bottom
1. doug_durham ◴[] No.42173160[source]
With all due respect to the considerable thought and effort you put into this, the ergonomics of this approach are hideous. Why would I ever care about the styling elements when I'm just trying to do some exploratory data analysis. This is exactly why things like Jupyter notebooks excel. Regardless kudos to your curiosity and implementing alternate ideas.
replies(3): >>42173477 #>>42173662 #>>42174221 #
2. paddy_m ◴[] No.42173477[source]
From a brief look, I think he's trying to position it for "Exploratory DOM Analysis". The intro demo looks scheme/smalltalk like in that you are creating the structure and primitives as you go (as demonstrated by changing 'ivory' to 'red' and watching the syntax highlighting change in realtime).

I understand how we got here, but it's a shame that javascript frameworks and libraries aren't easier to just play with in the browser. It's just JS, you should be able to play with it quickly in a lightweight environment. This approach excels at that. This approach brings back the whimisical possibilities of HTML/JS. I'd love to see more stuff like that and less TS, rollup, webpack,...

edit:Actually after reading a bit, this is being proposed for data analysis. I think that's a poor fit for this approach

3. mbo ◴[] No.42173662[source]
Author: The ergonomics of this _are_ hideous, to my dismay, which was a lot of the motivation behind @celine/celine (https://maxbo.me/celine, aka me packaging the article up into a library).

It's still not quite there as a platform for exploratory data analysis - you don't have the instant reactivity of either a fully-fledged web code editor from Observable Notebooks or the hot-reloading file-watching Observable Framework. And the new Jupyter Kernel for Deno + VSCode is a pretty smooth experience too.

So while I agree that the ergonomics for exploratory analysis is uhhhh bad, I don't think the _publishing_ ergonomics is that bad. In fact, they're good. It's just a single file! I don't need to maintain some massive toolchain or pay some 3rd party service to just send someone a graph and some data munging - I just lob a HTML file at someone over Slack or host it somewhere. And the flexibility to style the analysis means that you can publish in environments where styling is important (blogs, or as a research paper).

replies(2): >>42174556 #>>42176038 #
4. dawnofdusk ◴[] No.42174221[source]
>when I'm just trying to do some exploratory data analysis

Isn't the point to have a unified platform to do exploratory data analysis which can then easily be published? It's not for throwaway Jupyter notebooks.

I think there's great value for an alternative to Jupyter notebooks that aren't just throwaway. The UX being really trash right now is something which can be improved IMO. The question is whether this setup is better than the JSON madness in Jupyter notebooks... I'm leaning yes personally.

5. clcaev ◴[] No.42174556[source]
Pluto has a way to publish as HTML, even with some interactivity, via SliderServer. How is this different?
replies(1): >>42174725 #
6. mbo ◴[] No.42174725{3}[source]
Well the edited artifact and the published artifact are one and the same. I think there's value in a "buildstepless" notebook format.

Thanks for the heads up about SliderServer btw, was experimenting with something similar with Jupyter: https://hello-notebook-http-mode.fly.dev/

7. cpill ◴[] No.42176038[source]
yeah, but all the data analysis libs are in python.