alethiophile's comments

Personally, I would say that if you are doing DOM updates via AJAX calls that return HTML, HTMX is just the correct way to do it. (Unless you're using some other solution already for other reasons and it also includes that functionality.)

Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).

Why is it better to render JSON on the server, read that JSON in a separate client app that you also have to write, and then do a bunch of manual DOM calls in Javascript, rather than rendering HTML on the server and letting the browser's blazing-fast compiled HTML parser turn it into DOM for you?

The cost of launch is small-ish compared to the total program cost, but the limitations on launch condition the engineering requirements in ways that inflate the engineering costs. JWST had to be built as an insane on-orbit autonomous origami project because its mirror couldn't fit in a fairing unfolded. Repeat for ten thousand other decisions that are made in order to optimize weight or volume.

If you can launch a hundred tons to orbit for $5M, you can just make a huge dumb cheap telescope and throw a dozen of them up there. Quantity covers a multitude of sins.

> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".

I would say it's precisely the opposite.

Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.

There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.

It's definitely a really imprecise usage.

I assume "jQuery" here is being used as a metonym for the old frontend style where you would use the jQuery AJAX and DOM functions to query HTML fragments and swap them in. This is only really related to jQuery in that it used jQuery utility functions; under modern conditions you would just use fetch() and querySelector() etc to do the same thing.

It's true that the core concept of HTMX is very simple, and you could probably reimplement any given particular use case in a few lines. However, it is in fact a big advance over the manual HTML-fragment style, precisely because it abstracts over the particulars. Standardizing on a particular, good design is an important benefit even if the functionality of the code is easy.

The customer probably cares if your app takes five seconds to load because of the resource size, or reliably pegs a CPU core whenever you're using it.

Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.

Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data.

It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.

How often do you learn new things later that, even as transmitted through untrustworthy media, allow for clear falsification of the former media presentation?

This isn't zero but it's not very common either. Usually, the domain in question is sufficiently subtle that you can't make a rigorous prediction from an untrustworthy media presentation at all; thus, the media accounts are effectively unfalsifiable (unless you go out and seek personal experience).

Regarding a topic that you never come into personal contact with, your entire knowledge of it throughout your life will be media-mediated. How, then, would you ever learn what you had been misinformed of?

I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save.

I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.

What exactly is the resource-intensive request here? Loading an E-mail, or list of E-mails? I don't see why that should be any more resource-intensive than any other CRUD app.

Piston-engine planes are a remarkably small market. Automotive dominates the fuel market in total, and jet fuel (which is a lead-free kerosene derivative) dominates the aviation market.

As far as I can tell, no one has demonstrated any tangible cost from the (very small) amount of leaded fuel still burned in piston-engine planes. Even imputed cost from environmental lead levels is iffy -- the only places you can find detectable lead are the immediate environs of long-used GA airports.

Gas in the US (aviation or automotive) is always sold in gallons, but quantity of chemicals (outside of cooking) usually done in grams/kilograms. Thus, grams per gallon is fairly intuitive in context.

The decline in smoking has absolutely been accompanied and/or caused by a massive array of state coercion, from requiring all their advertising to prominently state "THIS WILL KILL YOU" to limiting who's allowed to sell it to banning it in almost all public spaces. (Which isn't even mentioning the "softer" approaches of massive state-funded PR campaigns against it.)

It seems quite likely that absent all of these, smoking would still be as popular as it ever was.

But if arbitrage bots were pushing the BTCUSD price up to match BTCUSDT, they'd have giant piles of USDT. And they'd have to convert it back in large quantities, or else they'd go broke.

The world where no one tests the peg too hard is incompatible with the world where Tether caused huge BTC runups all on its own.

Arbitrage isn't magic. The only way arbitrage can push BTC-USD prices up to match BTC-USDT is if the arbitrageurs are selling a proportional amount of USDT for USD. Either they're redeeming them with Tether, which some claim isn't actually possible (?), or they're selling them on USDT-USD markets. Since those markets still trade around $1, it's safe to assume there is not some massive imbalance for selling USDT over buying it.

Tether might be shady in all kinds of ways -- their operation has a lot of red flags to it. But it basically can't be responsible for massive BTC rises all on its own, because the rises happen even at pure USD markets, and that can only happen when a lot of real USD actually got injected.

I mean, no, this is just bullshit.

Surplus is what enables complex economies and trade. It also means you have governments trying to take over places, but this comes with surplus because without surplus everyone is too poor to even try.

The life of the peasants in a simple no-surplus economy is brutal and boring and precarious. Getting ruled by kings and emperors, in exchange for getting to participate in the high-end economies they come alongside, is almost always a very good deal.

Obviously the Bronze Age Collapse is not nearly so historically attested, and there's a lot we don't know. But your proposed series of events is not plausible. Temples, palaces, scribes, etc. are the sequelae of a highly productive economy with a lot of surplus. They disappear when the surplus disappears, which is not good for the common people either. People don't usually revolt in order to intentionally destroy their own standard of living.

Likewise, there was in fact a "Dark Age" between antiquity and the Renaissance. It's the period between the fall of the Western Roman Empire and the high Middle Ages proper, around 500-900 (whereas the high Middle Ages are more 1000-1400). This Dark Age is marked by the collapse of population centers, long-distance trade, economic activity and standards of living in general, just like after the Bronze Age Collapse. And neither of these have much to do with the Europe of the High Middle Ages, which was a thriving civilization with plenty of surplus and thus effort to spare on science, the arts, etc. (albeit not yet as rich as classical civilization).

> Now, arbitrage bots will look at this in crease in btc-usdt, and be mandated to buy btc with USD so that BTC-USDT and BTC-USD are in parity.

This is the bit that doesn't make sense.

Arbitrage bots trying to push BTC-USD up to match BTC-USDT will end up holding a lot of USDT. So what do they do with it? You can't just magically make USD markets go up; that needs actual USD to enter the system (as part of the arbitrage process, if nothing else).