You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all! I have been a big fan of Observable and Observable Framework. I see it as a parallel of Jupyter / Streamlit in python and I have long wanted to see that in the javascript ecosystem. At my work we have a large React application and even though I have been a React dev for many years it is hard and time consuming to build new pages. Observable Framework has huge potential for us to create data apps and admin apps quickly. I used it quickly build pages to manage users, data migrations, test sessions of experimental features, and several configuration interfaces. I think it fills an important missing niche of open-source rapid development frameworks for node/js.
In the interest of helping this project grow. I wanted to share the roadblocks I hit that ultimately led to us switching off of it. I hope that there can be a solution to these as I miss a lot of what Observable Framework has to offer. I think the market for it is potentially much broader than data apps and can fill a niche for web dev teams that need to build internal tools quickly.
These were our main roadblocks
Ultimately to build it into our React app, I had to iframe the observable static site which is not ideal and limited the ease with which I could pass information through to the embedded site. I tried having it separate, but then it was not so discoverable for our team.
I could not get it working sharing packages within our frontend pnpm monorepo (commented on this discussion). Kept getting changing dependency issues I think because of the symlinking in the filesystem. We eventually got a weird dependency issue only on windows that I just had to give up on. I'm sure there could have been solutions for these if I kept pushing.
Dependencies in general were hard to manage. I'm used to just doing an npm install. It's hard to tell which dependencies are bundled the right way, so I had to figure out which ones needed an npm: in the import and which ones could just be installed. I had to add typescript path aliases for the npm: ones if I wanted typing to keep working
Typescript support: I really really depend on typescript support. We use it throughout our repo especially because our data model is so huge it's much more cumbersome to develop without it. I ended up setting up a complex pre-compile step in our observable project that would compile typescript to a _build output directory from which the .md files could import and I pushed as much of the code into typescript as I could. This was OK, but I'm eagerly awaiting full typescript support within the .md though not sure if that can really be done across cells. If anybody is curious about my set up here, let me know and I can share, it was working pretty work.
Custom inputs. I didn't dig into this much because I didn't find docs on it, so I'm sure this is solvable, but we have a full design system of ready-made components and I would love to be able to reuse them. Related to the issue of not being able to share code with other packages in the monorepo.
I'm not sure if any of these are really solvable with the existing architecture of Observable Framework. Ultimately because I really loved the simplicity of the paradigm it inspired me to build out this library which closely follows the API of observable framework (especially display and view) but is implemented as a native React component so we could use it directly within our existing app. The underlying React model is really hard to square with what observable can do with its compilation - instead of using Generators, the whole script reruns each time more like Streamlit and we rely on React memoization and smart re-rendering on only what's changed in order for everything to stay snappy. The model took a bunch of refinement but seems to be comparably responsive. I'm curious if folks in the community have feedback or if there is a way we could work together on some of this as our goals are really aligned I think (maybe an adapter so that the views defined in Reactlit could also be used as inputs in Observable framework?).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all! I have been a big fan of Observable and Observable Framework. I see it as a parallel of Jupyter / Streamlit in python and I have long wanted to see that in the javascript ecosystem. At my work we have a large React application and even though I have been a React dev for many years it is hard and time consuming to build new pages. Observable Framework has huge potential for us to create data apps and admin apps quickly. I used it quickly build pages to manage users, data migrations, test sessions of experimental features, and several configuration interfaces. I think it fills an important missing niche of open-source rapid development frameworks for node/js.
In the interest of helping this project grow. I wanted to share the roadblocks I hit that ultimately led to us switching off of it. I hope that there can be a solution to these as I miss a lot of what Observable Framework has to offer. I think the market for it is potentially much broader than data apps and can fill a niche for web dev teams that need to build internal tools quickly.
These were our main roadblocks
npm:
in the import and which ones could just be installed. I had to add typescript path aliases for thenpm:
ones if I wanted typing to keep working_build
output directory from which the .md files could import and I pushed as much of the code into typescript as I could. This was OK, but I'm eagerly awaiting full typescript support within the .md though not sure if that can really be done across cells. If anybody is curious about my set up here, let me know and I can share, it was working pretty work.I'm not sure if any of these are really solvable with the existing architecture of Observable Framework. Ultimately because I really loved the simplicity of the paradigm it inspired me to build out this library which closely follows the API of observable framework (especially
display
andview
) but is implemented as a native React component so we could use it directly within our existing app. The underlying React model is really hard to square with what observable can do with its compilation - instead of using Generators, the whole script reruns each time more like Streamlit and we rely on React memoization and smart re-rendering on only what's changed in order for everything to stay snappy. The model took a bunch of refinement but seems to be comparably responsive. I'm curious if folks in the community have feedback or if there is a way we could work together on some of this as our goals are really aligned I think (maybe an adapter so that the views defined in Reactlit could also be used as inputs in Observable framework?).Beta Was this translation helpful? Give feedback.
All reactions