🏠 back to Observable

Enabling other languages?


Congratulations on Observable, it is a great idea and the execution is very nice!

I’d prefer to use Clojurescript over javascript given enough support (I actually got something working here https://beta.observablehq.com/@jeroenvandijk/untitled/3).

Are you considering supporting other languages natively as how you support javascript (e.g. syntax highlighting, no need to wrap with backticks etc)?


Super cool that you got something working inside of a notebook!

Though it would be super cool to add more languages in, it’ll be a pretty gradual process. Unlike most other notebooks, Observable is very semantic - a lot of the magic is how a mixture of static analysis and a smart runtime can simplify programming. We wouldn’t want to, say, add ClojureScript support but require you to manually re-evaluate cljs cells - we’d want cross-language evaluation to be at least reasonably reactive, in the way that evaluation is currently reactive.

Of course no shade on ClojureScript (I’ve built a few things with Clojure and mightily enjoyed it), but the focus for now is on making an exceptional environment, and then on potentially cross-language capabilities.


I wonder if we could have other languages in Observable. Is this issue in the pipeline?


There’s an older thread on this here: Enabling other languages?

(And now we’re merged!)


I suppose you can always try the tagged template approach, but then the other language is more like a pre-processor (edit: just noticed that this is exactly how the ClojureScript works in linked notebook at the start (waarom is Kees eigenlijk een topper, @jeroenvandijk?))

Take a look in the ganja.js topic for more ideas:

Also, you just inspired me to try embedding the Walt compiler in the Observable notebook, seems to work pretty well!

So that means runtime JS-like WASM for the masses :slight_smile:


very nice notebook! to make it work on a retina screen, you might want to use context = DOM.context2d(width, height, 1) or adapt all the canvas.onmouse* (otherwise it paints only the top-left quarter of the screen).


Thanks for the tip! (I wonder if this fixes the phone size bugs in my other notebooks too edit: nope :frowning: )


A small suggestion: https://beta.observablehq.com/d/a725945e96948f7b#compiledWaltBuffer uses the visual (barcode) of the compiled code as a viewof. This way, no need to have two separate cells. And the function is reusable. This is similar to https://beta.observablehq.com/@fil/pt


Nice, thanks! So are the graphics is still clearly visible on retina screens at that size? Or should we perhaps also scale that with devicePixelRatio?


Yes they have the correct size, but you can see they’re using “non retina pixels”.
But as you’re making the images with a matrix and putImageData(), I don’t think you want to have to think about devicePixelRatio.


It’s just a constant multiplication factor, no big deal.


(mods, maybe talking about Walt/WASM should be split into its own thread by now?)