thomasp85

No objections at all. But probably good to describe that it is ggsql-inspired rather than a full reimplementation as it could lead to user confusion about what syntax is supported etc

And you are correct about how our extension is implemented and it isn’t currently wasm ready

ggsql developer here. It's quite fun to see an alternative implementation of our syntax so early. Why did you decide on this path rather than working with the ggsql duckdb extension? (honest curious question - not trying to push you away from your path)

I can only imagine the load you might end up in if you have to keep feature parity with ggsql along with all the other features you have

We are not out to convince anyone to switch from ggplot2 (and we are not planning to stop developing that).

ggsql is (partly) about reaching new audiences and putting powerful visualisation in new places. If you live in R most of the time I wouldn't expect you to be the prime audience for this (though you may have fun exploring it since it contains some pretty interesting things ggplot2 doesn't have)

Ah - I don't think it really matters here, but if you find yourself in need then you can open a GitHub issue and we can discuss

Ah - yes, in theory you could create a "ggplot2 writer" which renders the plot object to an R file you can execute. It is not too far away from the current Vega-Lite writer we use. The other direction (ggplot2->ggsql) is not really feasible

That is certainly in the pipeline. We chose to start with vegalite so we could focus on the internals of the representation

I'm not quite sure I understand what you mean by "degrade in context" - care to elaborate?

My answers will probably disappoint

1) No (unless you count 'render to image and insert that into your excel document') 2) This is not possible - manual adjustments are not reproducible and we live by that ethos

Let me try to not miss any of the questions :-)

ggsql is modular by design. It consists of various reader modules that takes care of connecting with different data backends (currently we have a DuckDB, an SQLite, and an ODBC reader), a central plot module, and various writer modules that take care of the rendering (currently only Vegalite but I plan to write my own renderer from scratch).

As for deployment I can only talk about a utopian future since this alpha-release doesn't provide much tangible in that area. The ggsql Jupyter kernel already allows you to execute ggsql queries in Jupyter and Quarto notebooks, so deployment of reports should kinda work already, though we are still looking at making it as easy as possible to move database credentials along with the deployment. I also envision deployment of single .ggsql files that result in embeddable visualisations you can reference on websites etc. Our focus in this area will be Posit Connect in the short term

I'm afraid I don't know what IR stands for - can you elaborate?

I don't think we will get the various niche geoms that have been developed by the ggplot2 community anytime soon.

The point of this is not to superseed ggplot2 in any way, but to provide a different approach which can do a lot of the things ggplot2 can, and some that it can't. But ggplot2 will remain more powerful for a lot of tasks in many years to come I predict

That is conceivable, not a top priority as we want to focus on this being a great experience for every backend, but certainly something we are thinking of

We certainly plan to create a few videos showing how to set it up and use it. If you use it in Positron with the ggsql extension it can interact directly with the connection pane to connect to the various backends you have there

That is fair - it is somewhat of a special concept.

ggsql connects directly with your database backend (if you wish - you can also run it with an in-memory DuckDB backend). Your visual query is translated into a SQL query for each layer of the visualisation and the resulting table is then used for rendering.

E.g.

VISUALISE page_views AS x FROM visits DRAW smooth

will create a SQL query that calculates a smoothing kernel over the data and returns points along that. Those points are then used to create the final line chart

I'd say it does, though it is certainly much more low-level than e.g. ggplot2. But the basic premises of the building blocks described be Leland Wilkinson is there

I'm one of the authors - happy to take any questions!

The new visualisation tool from Posit. Combines SQL with the grammar of graphics, known from ggplot2, D3, and plotnine

Really happy you like it. Would love to see something published using it

You can of course animate it like this https://twitter.com/thomasp85/status/694905779539812352 but a static representation is often easier to interogate. I would try to bin the time points and facet on them...

Without needing to get into an R vs Python discussion I think it is fair to say that this is a perfectly valid subjective opinion and that a lot of people will disagree completely... none of the ggplot2 Python ports holds a candle to the original, feature-wise. So the question is whether you will reach out for the lesser tool or learn a new programming style...

Depending on the number of time points you can use the facetting functions in ggraph to create small multiples

I'm in talk with the plotly devs regarding ggraph support — once that materialises it should cover most interaction

Yes, you use already available network packages like igraph and network (where you can import dot files) and then use the declarative API of ggraph to specify your plot