fquery VS htmx

Similar benefits without codegen (based on decorator magic) for a python based stack:

https://github.com/adsharma/fquery

* Use dataclasses for both database schema and the user facing operations

Re: Conways law at Facebook

I was at Facebook when GraphQL was invented, maintaining a backend storage service where a core assumption was that storage should be reorganized based on access patterns and that predicates should be pushed down to storage where they can be executed more efficiently.

GraphQL was hard to push predicates down, because you don't know which of the edges were written in PHP.

My response was fquery[1], which is like what's being discussed here but with python as the source language instead of swift and amenable to preserving the largest possible query structure for backend optimizers, including SQL optimizers.

It has some early demos converting a GraphQL/fquery into SQL where possible. It should be possible to add enough metadata to fquery to identify if an edge is non-trivial (calls into another microservice) or trivial (can be optimized to a storage backend or SQL).

[1] https://github.com/adsharma/fquery

The Single-Page Application trend gained popularity partly because it allowed developers to avoid full page reloads during navigation or form submissions. HTMX has been generating buzz recently precisely because it enables bypassing full document reloads. At the same time, it sticks to a document-based approach for browser/server interactions. This eliminates the need to retrofit JSON API constraints. Additionally, it dramatically reduces the amount of JavaScript required on the frontend.

FastHTML gets you up and running quickly while also making it easy for your users. It does this by selecting key core technologies such as ASGI and HTMX. The foundations page from FastHTML introduces these technologies and gives the basics (though you don’t need to know about these to get started).

In this series of posts we will create a To-Do app using HTMX and Django, following a TDD (Test-driven development) workflow.

I'd definitely love to do something front-end related and therefore I'd like to play a little bit with htmx. But first I need an idea for a small application. This way I plan to code again in Golang (this year I didn't manage to code anything useful).

That's why I grew fond of libraries such as Alpine.js and htmx, which require no setup and are easy to use. However, I felt these had some limitations. Since they were mostly designed for client-side usage, it wasn't really possible to use them in server-side rendering contexts (including static generation).

I'VE been a long-time proponent of the power of HTML forms and how natural they make it to build web pages that allow users to input data. Recently, I got a chance to refurbish an old internal application we use at work using htmx and Scala's Play Framework. In this app we often use HTML forms to submit information. For example:

I've spent years slowly migrating a personal project from PHP to Scala/React, and I'm devastated if React is out-of-date already. The web tech treadmill is relentless!

Seems the author recommended HTMX as an alternative in a couple of scenarios.

I checked out HTMX. The canonical example on the homepage (https://htmx.org/) was a button where a click calls the server and the response contains HTML to replace the outerHTML of the button.

I must be missing something here. Is HTMX really suggesting muddying the back-end code with front end code? So, any changes to front- or back-end would have to be carefully managed to avoid breaking the other side?

Feels like PHP all over again!

Almost as easy as the AlpineJS, but with a little more work. Download the HTMX lib from HTMX website in the palindrome/static/js folder: