An in-depth look at an old friend: escaping.

the escaping required in an HTML attribute value is different from the escaping required in an HTML element body, which is in itself different from the escaping required for a query string parameter value inside an URL inside an HTML attribute value

the conceit of context-dependent autoescaping systems is that they can have a full understanding of the semantics of the language they are templating. However, this is not possible because languages such as (X)HTML are user-extensible.

manual escaping is an accident waiting to happen, and autoescaping requires language- and context-dependent analysis of the string being templated, which is liable to be unreliable.

people are led to view the consequence of the ruthlessness of the machine as a kind of force of nature, and rendered powerless to object. Yet it is not a force of nature; in reality it is a system deliberately designed by humans to advance a ruthless end, without admitting to it.

“The system won’t let me do it.” How many times have you heard that excuse when pleading with another person for some kind of humane understanding and exception to your scenario?

companies realise they can escape from accountability by hiding behind the facelessness of the machine, which disempowers the individual to fight or object to it.

And that’s how we want our money to work?

using cryptography, systems — institutions — can be created which possess absolute integrity, where all past efforts to create such institutions have failed, having been comprised of humans who are infinitely more corruptible…

All transactions are final; none can be reversed. It does not matter if your coins were stolen, or if your family will come to ruin because of it; the system does not care. There can be no exceptions. If we desire a system of absolute integrity, we must accept these outcomes as the cost

This one hits right on the nose. The idea of PHP’s incremental, linear dynamicity feels so lost in many of today’s technological abstractions.

Here's the problem: mildly dynamic functionality…is too minor to be worth bringing in a web application framework, and spawning and maintaining persistent processes just to serve a website.

What PHP offered is an increase in this effort proportional to the amount of dynamicity to be added to a website. This is something no framework can do…If you have a static website and you want to make it dynamic and you don't use PHP, pretty much all options available to you imply a massive increase in complexity that must be paid up front before you can do anything at all. You bring in a massive framework for the dynamic equivalent of “Hello World”, and then on top of that (if it's a non-PHP framework, meaning persistent processes are probably involved) the process for deploying your website radically changes and becomes far more complex.

This in turn has led to much of the functionality which might have previously been implemented on the server side on a “mildly dynamic” website being moved to JavaScript.

Client-side JavaScript, that is. The idea of dynamicity in a website became something to be outsourced, both in technology and compute (e.g. “just embed this <script>”).

PHP remains the only server-side technology really offering a linear increase in effort for a linear increase in dynamicity.

Suppose you are writing an article about some concept and you want to put some special dynamic widget in the middle of the article, which people can play with to gain an understanding of the concept. This is just one article you're writing, one of countless others; you're not going to spin up an application server (and maintain it indefinitely) just for this throwaway toy widget. The only reasonable implementation options are JavaScript and PHP…

Or, suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn't need a framework — it's one SELECT query, that's it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn't too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn't have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

the ability to just give a piece of code an URL in 30 seconds, without complex deployment tooling, proprietary APIs or vendor lock-in seems to me a lot more valuable for the things I do