If you are a data analyst interested in making web apps, you might be interested in my OSS project, Evidence, which is a Static Site Generator for building reports and data apps with SQL and markdown.
It’s interesting to me how far you have pushed the SQL language in this framework, such that it truly is “SQL only”.
The challenge as I see it with enabling analysts to build websites is that you need to build abstractions to get from familiar (SQL, yaml) - the language of analytics, to new (HTML, CSS, JS) - the language of the web browser
As one of the maintainers of Evidence (https://evidence.dev), one of the things I’ve often considered is how accessible our syntax is to analysts. Our syntax combines SQL and Markdown, with MDX style components e.g. <Component/>
The </> are inherently webdev-ey, and I do think they put off potential users.
On the flip-side, by adhering to web standards, you get extensibility out of the box, and working out what to do is just a Google search away.
Indeed, making this really 100% SQL-only had very interesting and unexpected consequences. I see people who were initially far away from programming circles creating GitHub accounts just to post on the discussion page.
I'm currently working on some new exciting features. I hope we can push the frontier of what can be done in SQL even further...
When I look at the Tiny Twitter example and see the code below, I'm curious if there is a more "SQL" way to implement it.
```
select 'checkbox' as component,
'Terms and conditions' as label,
true as required;
```
I'm thinking "What would the workflow of a sql-enthusiast be, to build that page".
I think they'd want todo this first:
```
select * from sqlpage.components;
```
which would list the `name` of each component. Which then takes me to:
```
INSERT INTO sqlpage.dom
SET name = 'checkbox',
label = 'Terms and conditions ',
required = TRUE
FROM sqlpage.components
```
(or VALUES syntax for INSERT)
This would allow you to re-order your dom, update dom entries, etc. Very similar to jsx, but instead of jsx creating in-memory javascript objects, it's sqlpage's sql creating rows in a postgres table. Then the SQLPage virtualdom gets transformed into actual html.
The "select 'checkbox' as component" is just an example, but nothing prevents you from creating a my_form table and writing it as "select * from my_form" instead.
You don't need any special feature from SQLPage for that.
would love to see duckdb included as a data source. it really is a swiss army knife when it comes to processing data formats. json, gpx, csv, xml, sqlite …
Well, I've watched most of the video.
IMHO it's a step back.
You know separation of concerns, clean templates, don't mix presentation and data.
Well, this is the extreme in the opposite direction.
Instead of using proper <component>s you're using
"select 'Label' as text".
No. Even if the guy is sympathetic, keep presentation separate.
If it had markup mixed with SQL queries, ok, sure.
But this is going too much in the other extreme direction.
I not just would like but need to have control over my presentation.
And with doing pseudo SQL queries this is too complicated vs regular markup or something like vue etc.
Only upside of this is performance and/because it's SSR
It is indeed the complete opposite to "separation of concerns". But it's not necessarily a bad thing.
Why is separation of concerns a good thing in general? Mainly because of three things: maintainability, scalability, and collaboration.
However, there are cases where strict separation of concerns is impractical, and people are ready to sacrifice these for simplicity and speed of execution.
Agreed- I worked at a company a few years back that build on a product using postgrest and an angular frontend for everything with nothing in between- which felt wrong as well
