Years ago, mid-90's, I visited Compuserve in Ohio. The web was just getting going and one of the engineers I met there showed off a music store he was building by returning html from SQL stored procedures :).

The quality of open source databases with views, partitions, etc as well as improvements in server hardware have made this approach much more appealing.

if you think about it, serverless lambdas are just stored procedures with bells and wistles.

Lambdas feel more like CGI scripts. Too bad they didn't just use the CGI standard instead of something proprietary.

if you think about it, php is just stored procedure with bells and whistles.

nah you have to worry about deployments of where .php were placed and mod_php and php-fpm stuff. DB can scale and you don't have to worry where SP were executed.

I have a huge feeling there will be a compressive period after the sort of cambrian explosion we've seen in the last decade.. everybody do very similar things, spread across N layers just so you can modify a bunch of rows in db. Mind boggling.

Yes, we had that at Oracle as a product. SQL + PL/SQL = HTML. It also had a built in versioning that if two users would change the same record it would moan.

If you think that's cool, you might also want to check out Omnigres:

https://github.com/omnigres/omnigres

I don't really understand what this project is designed to do. I see a lot of reinvented square wheels, that other Postgres extensions already do better. Another (synchronous) HTTP client library, why? What does the "completed" JSON module even do, what are its aims? Maybe I just don't see the forest for the trees, but I can't figure out the value-add here.

I think the main value proposition is its HTTP server, which AFAICT lets you serve web requests from inside the PostgreSQL DB process.

(I'm not sure whether PostgREST also serves requests from inside the process, but another comment mentioned that it's a separate server process. I can see advantages to both ways.)

You still need to run PostgREST, so still 3 servers. (web/app/db)

I can't imagine I'd put the database on a separate host from postgREST - the overheads are so low as to not meaningfully exist.

I _might_ introduce a load balancer to support migrating between servers with only 1-2 seconds downtime, but probably only for the duration of the move.

Isn't this example just web + db ?

PostgREST is an app that turns the db into an API. This takes the place of a traditional app server, but it's still an app server.

Thanks for the clarification

Am I trippin or is htmx not a JS library?

Yes, it is. People often talk about how HTMX allows for interactive websites without any JS. Well, there is JS, it's just that it was written by the developer of HTMX, not the developer making their web app.

presumably the implication of a "js library" is that your frontend is written by you using js, rather than declaratively via html(x).

This is true, but htmx is targeting developer experience and simplicity, not solving <noscript> user case. For this perspective "interactive websites without any JS" is accurate.

I wouldn't say that's accurate because Astro is a better fit for that description.

Not really. It just augments the hypermedia capabilities of HTML. Adds the missing semantics. You don't invoke library functions.

It still needs JS to work though

Look up nontrivial examples on their own docs.

“Simple” form validation is a clusterfuck and that’s what they’re leading with.

Why HTMX advocates say 'augments the hypermedia capabilities of HTML' instead of 'another implementation of HTML-over-the-wire approach'? Placing hidden meaning into common words sounds very cult-ish.

we say this, because, more than other HTML-over-the-wire libraries, htmx focuses on generalizing the two core hypermedia controls, anchors and forms

i discuss this extensively in chapter 4 of our book:

https://hypermedia.systems/extending-html-as-hypermedia/

the tldr is that htmx generalizes:

- the event that triggers an HTTP request

- the element that triggers an HTTP request

- the type of the HTTP request

- the placement of the hypermedia response to that HTTP request

In this sense, htmx adds functionality to (or, more dramatically, "completes") HTML.

This is in contrast with, for example, https://unpoly.com, which also uses HTML-over-the-wire, but provides higher level concepts (e.g. layers) and isn't as focused on generalizing hypermedia controls. This has advantages, unpoly gives you more functionality out of the box, but puts it further way from being a pure conceptual HTML extension.

It's more like a polyfill for a proposed/nonstandard version of HTML.

Written in JavaScript, if you can believe it.

Yes but I'd argue that this is a case that shows the construction "JavaScript library" to be non-intersective :)

My colleague James is tall and he's a basketball player. But, in one pretty straightforward sense at least, he's not a tall basketball player.

Edit: I thought of a better analogy. Compare Lodash and uBlock. Lodash is clearly a "JavaScript library", uBlock is clearly not. Why not, given that like Lodash it's just so much JavaScript? Because uBlocks' intended users don't use it as a JavaScript library. They use it to modify the default behavior of the chrome browser to something more to their liking, not as a tool for more easily expressing themselves when writing JavaScript code. I'd argue the relation of htmx to HTML is very much like that of a Chrome/VSCode extension to Chrome/VSCode: its purpose is to change the built-in behavior of some tool (HTML) used by the user, whereas a library at bottom serves an expressive purpose.

htmx's angle is that the developer don't interact with the javascript, so it's not a javascript library. Otherwise one could say that html is a C++ library because the markup is interpreted and run by the browser (written in C++).

The other option being… webassembly? convince WHATWG members to change their browsers?

It would be harder to believe something running dynamically in the browser is not written in JavaScript.

It is a JavaScript library

crud without the cruft

How is authentication/authorization handled with this stack? Or sign up with email validation and password reset?

It's a little bit involved but doable.

https://postgrest.org/en/stable/references/auth.html

So where is the secret key stored for signing the JWT? In the front end as well?

RDBMS auth and roles are a thing. They even support mTLS.

We've been down this road before. It's neat but not for long term maintenance, support or training as soon as HTMX loses its luster and the, then manager, has to concede the whole thing has to be re-written from scratch.

I've gone down this road before and that's not what I would criticize.

Where things went south for me:

- hard to hire developers that know how to work with this or that are willing to learn

- very hard to debug performance issues

- version control gets weird, since migrations are not really meant for functions and procedures (although Pyrseas[0] helped a lot)

[0] https://pyrseas.readthedocs.io/en/latest/

Is it possible to capture changes in git somehow? If not what did you do?

I smell a startup opportunity.

I think using Postgres as a runtime would feel like a PaaS runtime not much different from other offerings in the market. But, for something self-hosted, it feels like super powers in the beginning.

I've used git as usual to evolve my SQL functions and procedures and my CI/CD pipeline used Pyrseas to sync code with database.

I am starting to believe that "system has to be rewritten from scratch in the future" is not nearly the dealbreaker people make it out to be. Especially if it didn't take that much work building the v0 version.

You should almost always rewrite the system in the future, that's just the nature of growth and systems evolution.

So like nearly every JavaScript framework that comes along?

... we are back with mainframes but this time browsers as terminals

Now deploy a DB per customer and you have scaling sorted.

Yep, and that’s easier than ever now with neon, fly.io and similar.

The backend and frontend are still there... Just all tangled directly into database code

It's all a shell game.

Yeah, I exaggerated a bit. It's just that where it used to be postgres + node + react + html, then the middle two have been cut.

And I'm actually not contesting the value of a regular back-end and a front-end framework: postgrest and htmx make it easy to achieve more with configuration, but this only works up to a degree. After that point the benefits of a custom application start to overweight its absence.