Show HN: PageQL – Embed SQL directly in HTML
pageql.devHi HN,
I've been experimenting for some time with writing web frameworks, and I thought it's time to publish one that I really like: it just embeds SQL directly inside HTML without any glue language.
One of the main motivators for getting this minimal was the Hundred Year Web Seervice with htmx presentation by Alexandrer Petros (https://www.youtube.com/watch?v=lASLZ9TgXyc), that showed that both HTML and SQL have staying power, but he couldn't really find a perfect glue language for his app. After some searching I only found ColdFusion to have implemented the same idea, but instead of the reactive direction that I want to go to, it went towards imperative programming which is not the direction I want to go to. I tried to learn from the original (pre-Adobe) ColdFusion, but make it closer to standard SQL.
I plan to keep the language super simple, just like a template language, make it provide 80% of the CRUD functionality a small web-site needs and add more extension points around it to handle other complexity by other languages.
I have already created a reactive SQL implementation, but the framework got too complex to use, so this is my next experiment (and HTMX can already provide a lot of interactivity).
> I tried to learn from the original (pre-Adobe) ColdFusion, but make it closer to standard SQL.
Are you referring to querying a datasource, where the SQL is just passed to the external database engine, or to the ability to query an existing dataset using the embedded SQL engine?
Right now it's using Python DB API with SQLite, so it can be easily modified to use any database, as they are using the same standard Python API.
In the future though I'm planning to add reactive query support where it is really advantagous to have low latency between the PageQL rendering engine and the database.
For MySQL/PostgreSQL for example an extension would run much faster, and give back the results, that's why I don't want to add async / http downloading / scripting support inside PageQL, just keep it simple to implement / embed.
Thanks for the response, but I was just curious about what you said about ColdFusion's SQL. Until it gave you the ability to run queries against already queried recordsets, it never had its own SQL dialect, but simply passed along SQL to the underlying adapter (I assume you're doing the same).
I see, yes, right now I'm doing the same, just passing the SQL query along with a bit of preprocessing, like changing :headers.something to :headers__something as the bindings don't accept dots.
Regarding temporary resultsets I'm thinking of adding a #view command instead that creates an SQL view that is shared between invocations and doesn't accept parameter bindings.
The main reason why I want my own full SQL query parsing is because of the reactive views: I want to be able to show 1000 long tables and when a change to a row is made from outside, be able to react to the change without reading the whole 1000 long table again, just push that 1 line change with the websocket. This can be useful for chatbots/chats/live infinite scrolling where the content changes / new content comes in.
Still, it just constructs new SQL queries that are easy to optimize, like SELECT * from (SELECT * FROM T) where id=1 (SQLites optimizer is rewriting these queries quite fast, so I don't want to write my own optimizer, just query builder for reactive SQL).
That's fun. I remember doing this ~2001 with some JSP tags. Everyone thought it was terrible idea but it was really productive tbh.
Thanks for the comment. I also thought the same, so I don't blame people for thinking it's a terrible idea.
What's really exciting is that it gives reactivity, reloading, declarative state and a lot of optimizations almost for free, but as I haven't implemented them in PageQL yet, the advantages are less clear.
Around the same time I built several line of business applications using Oracles mod_plsql. It was also very productive.
HTML + SQL + imperative PL/SQL, running inside the database, right next to the data.