Have you tried developing a GUI app for Windows in the last 5 years? All the official first-party frameworks are either mostly deprecated (WPF, WinForms), or half-baked and despised by every developer I’ve talked to about them (MAUI).

I’ll stick with nushell for terminal-first data interactions.

I think the point is that they don’t want to have to use a full JS framework (which is what HTMX is) for this behavior.

And this is where HTMX fits in. It’s an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.

But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.

EDIT: Put another way, if you look at HTMX’s "motivation"s:

motivation

• Why should only <a> & <form> be able to make HTTP requests?
• Why should only click & submit events trigger them?
• Why should only GET & POST methods be available?
• Why should you only be able to replace the entire screen?

By removing these constraints, htmx completes HTML as a hypertext

It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.

TypeScript React (although I like Svelte better, it’s hard to pitch for business projects), C# ASP.NET Core API, Postgresql.

“the only primary difference was that one happens before the aggregation and the other happens after, and all the other implications stem from that fact.”

This is correct. The biggest implication of that difference is that, when you filter rows via a HAVING clause, the query will first select all the rows and aggregate them, and only then begin to filter them. That can be a massive performance hit if you thought that the filter would prevent filtered rows from ever being selected. Of course this makes perfect sense, there’s no logical way to filter an aggregate without first aggregating, but it’s not obvious.

“PRQL’s simplification, rather than obscuring, seems like a more clear and reasonable way to express that distinction.”

My main point is that PRQL makes no distinction. If you didn’t inspect that SQL output and already know about the difference between WHERE and HAVING, you would have no idea, because in PRQL they’re both just “filter”. Hence, PRQL is not simplifying the complexity (you still need to learn the full SQL syntax and the specifics of how it works), but it does obscure (you have no hints that one of your filter statements will behave completely differently from the other).

As far as removing arbitrary SQL features, I agree that that is it’s main advantage. However, I think either the developers or else the users of PRQL will discover that far fewer of SQL’s complexities are arbitrary than you might first assume.

Because at the end of the day, SQL it what’s being run by the database. For example, in the Showcase on the front page, they have an “Orthogonality” example that demonstrates filtering both before and after an aggregation, which compiles to a WHERE clause and a HAVING clause respectively. WHERE and HAVING have very different impacts on SQL queries, and vastly different performance implications, but the simplification in PRQL obscures that complexity.

At the end of the day, the transpiled langauge will have to either support only a subset of SQL’s features, or else be at least as complex as SQL. It cannot support all of SQL’s features and yet be less complex, because it is just a wrapper around SQL.

I suppose for the right crowd, possibly people who run queries only once and do not care about performance implications, data integrity, etc., this could be a really useful tool. And in all fairness, they mention exactly that on their homepage:

"PRQL’s focus is analytical queries

PRQL was originally designed to serve the growing need of writing analytical queries, emphasizing data transformations, development speed, and readability. We de-emphasize other SQL features such as inserting data or transactions."

But for developers who need to maintain an application database, I don’t foresee this becoming a useful substitute for SQL.

I don’t know anything about the newsletter. The core of the article seems to be observing a shift in AI/ML/LLM opportunities. Where before, most people in the field were developing the base models and doing the arduous and highly complex work of training models (what the author calls ML Engineers), now the majority of this field will be people who use those pre-made and pre-trained models, tweaking and applying them for more and more specific and quantifiable uses (what the author calls AI Engineers). He drew a malleable line between the two as whether you’re interacting with the model directly or via an API.

This seems nice in theory, but the tradeoffs make me question it’s real world viability. It has to be a transpiled language, because SQL is so ubiquitous is may never die. And yet, because it’s a transpiler, I’m skeptical that it will actually be easier to write than SQL, because you’ll still need to know all the gotchas and eccentricities of SQL.

Maybe for users who already experts in SQL this would be a quaint alternative syntax. However, personally I’ve already invested so much time developing familiarity with SQL that I see no advantage in moving to a new syntax that would take more time to become deeply familiar with, and that my co-workers won’t understand.

My understanding is that these passkeys can be securely synced - either via your device cloud (e.g. iCloud), or hopefully soon via your password manager. So not that different in terms of UX than current 2FA, but more secure in the backend.

My go to for static content is astro.js. It gives a really nice developer experience that is really just writing HTML but with the quality of life of reusable “components”, all with 0 JS by default.