In principle, yes, that’s the idea! However I will say we have focused mainly on the grammar and using DuckDB for reading from local files for this alpha release, so I expect there may be some bugs around connecting to remote databases still to iron out!
Currently our only writer module is for vegalite, the output is a vegalite spec (JSON). Tools already exist to render this kind of output to an interactive chart, SVG, PNG, etc. with their own controls for sizing and the like.
Our ggsql Jupyter kernel can use these vegalite specifications to output charts in a Quarto document, for example.
In the future we plan to create a new high performance writer module from scratch, avoiding this intermediate vegalite step, at which point we’ll have better answers for your questions!
ggsql has the concept of a "reader", which can be thought of as the way ggsql interfaces with a SQL database. It handles the connection to the database and generating the correct dialect of SQL for that database.
As an alpha, we support just a few readers today: duckdb, sqlite, and an experimental ODBC reader. We have largely been focusing development mainly around driving duckdb with local files, though duckdb has extensions to talk to some other types of database.
The idea is that ggsql takes your visualisation query, and then generates a selection of SQL queries to be executed on the database. It sends these queries using the reader, then builds the resulting visualisation with the returned data. That is how we can plot a histogram from very many rows of data, the statistics required to produce a histogram are converted into SQL queries, and only a few points are returned to us to draw bars of the correct height.
By default ggsql will connect to an in-memory duckDB database. If you are using the CLI, you can use the `--reader` argument to connect to files on-disk or an ODBC URI.
If you use Positron, you can do this a little easier through its dedicated "Connections" pane, and the ggsql Jupyter kernel has a magic SQL comment that can be issued to set up a particular reader. I plan to expand a little more on using ggsql with these external tools in the docs soon.
WebAssembly is generally most useful when you want to write high performance web applications using languages like C, C++ or Rust.
WebAssembly sits in the background quietly powering the web-based versions of products like Adobe Photoshop, AutoCAD, Figma, Canva, and likely others. By using Wasm components combined with other browser technologies such as HTML canvas and webGL, app performance and responsiveness can be improved.
WebAssembly also powers the Pyodide and webR projects, enabling Python and R code to run in a browser without a supporting computational server. Where I’ve seen this used most effectively so far is in teaching materials, particularly for teaching data science, where interactive R and Python examples can be embedded directly into teaching materials without the educator having to worry about the time or expense to deploy a powerful backend service to evaluate learner’s code.
I’ll definitely be trying out more of LFortran in the future.
For this post I really wanted to go deeper into the approach we’ve taken with flang, but I can see that LFortran is also a very strong choice here for running Fortran on Wasm.