Really cool! BTW since you're here, have you checked https://github.com/malloydata/malloy/ and their visualizations? it seems it could be a nice fit for ObservableHQ
Thank you. I don’t want to commit to a public timeline on the web editor yet, but rest assured it is a top priority, and we also value the convenience of a web editor, instant collaboration, and community!
We’re interested in adding a TypeScript cell mode, probably first with type stripping rather than validating types. I was hoping for a pure JavaScript implementation; maybe we’ll try https://github.com/bloomberg/ts-blank-space? I’ve also been looking at https://github.com/val-town/codemirror-ts for the editor, but it’s a lot of machinery.
I would only expect type stripping, although it seems you already have the TypeScript language server hanging out in the editor for completion and docs and such, it’s not much extra challenge to get the VFS hooked up enough to show red squiggles in CodeMirror. I built a CodeMirror + typescript for the React docs site and it’s definitely machinery but not too bad maybe 600-800 LoC (never got merged, sad)
but this approach stalled because it doesn’t implement validation of TypeScript: the TypeScript annotations are simply ignored. I felt this defeats the point of using TypeScript. We probably need to use tsc instead of esbuild to get type checking. Hints welcome!
In what way are these free open-source tools “locked-in” to Observable? Observable Plot is a vanilla JavaScript library that is released under the ISC license and can be used with any style of web development (e.g., React, Svelte, whatever). And likewise Observable Framework is released under the ISC license and you’re able to self-host projects anywhere and develop locally?
Thanks for the feedback. We have a PR open to make it easier to register new interpreters (without needing to fallback to .sh or .exe); it’ll let you specify the interpreter associated with a given file extension (e.g., .kts for Kotlin). https://github.com/observablehq/framework/pull/935
As for inputs-driving-data-loaders, that does go against the grain a bit since Framework favors static data snapshots so that the built site is self-contained and performant. But a technique that works well is to generate Parquet files in data loaders representing the superset of data that you want to interact with, and then using DuckDB/SQL in the client to extract the subset you want to visualize. This tends to perform well, though obviously it’s dependent on the size of the superset you want to interact with.
