alethiophile

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).

If arbitrage bots try to arbitrage between BTC-USDT and BTC-USD markets, and the USDT markets are the ones pushing the price up, then it's the arbitrage bots that would end up holding huge amounts of USDT. So what are they doing with it? They should mostly be trying to maintain equal holdings to handle arbitrage, so they would have to sell it on USDT-USD markets (or redeem it from Tether, if that's actually possible).

If the tethers are actually unbacked, then the USDT-USD markets should be dropping hard as arbitrageurs try to unload tether bags.

It only works if you've got a specific, somewhat unlikely configuration. You need to have ALL in the user specifier, but not root (or else it's not a vuln, just a bug). So

> username ALL=(ALL, !root) ALL

would be vulnerable; this is trying to let username run commands as any other user _except_ root, but using this vuln the user can get around it.

You can duplicate it by running (as a user with sudo ALL privileges) `sudo -u#-1 id`; it'll show 0, for root.

...The pro-gun crowd are the ones who constantly quote the amendment verbatim. They don't "hate" it.

And yes, it doesn't explicitly say in the text of the amendment what kinds of threats the militia is meant to defend "the security of a free state" from. This is why you need to make obvious deductions based on context. There's certainly no basis, either in the literal text or in contextual deduction, for the idea that the founders only meant it as security against foreign invasion.

It quite obviously meant both. The British army, against whom the people who wrote that clause had just finished fighting a revolution, was an army of "the same state" when the fighting was happening.

Any attempt to deny that the founders were very worried about tyranny imposed by the government of the country in question, and intended the second amendment (among other things) to allow the citizens to resist against the army of that government, is outright ahistorical.

In the context of the time when it was written, "militia" meant the entire male population of military age. You can look up period law codes and find this kind of definition. It wasn't a legal fiction, either; that was the only civil defense most communities had, and threats were fairly common (e.g. Indian raids).

The plain meaning of the second amendment, in this context, is that _anyone_ is allowed to own arms, because everyone is expected to take responsibility for defending themselves and the community. There's also another layer; "militia" is as opposed to "standing army", and "a well-regulated militia being necessary to the security of a free state" thus means that the militia (that is, the population at large) needs to be armed well enough to resist tyrannical impositions by a standing army.

Most "death by firearms" are suicides, and suicides mostly don't need instructional videos. The rest are mostly murders, and there's nothing to suggest that gun videos on Youtube make people more or less likely to murder.

There's no good reason to think that this step by Youtube will help with the "public health" side of the issue at all; it's fairly transparently about an animus against guns qua guns.

If they're trying to get away from privacy-related bad PR, maybe "oh, by the way, we're capable of bugging the entire rainforest and analyzing the take in real-time" isn't the best approach.

Heaven knows it's only driving me more paranoid.

I just got one of those periodic "wow, those are the same person?" Internet moments; I've both used AFL a fair bit, and read Tangled Web, but never connected the two.

Impressive fellow.

If Bitcoin gains significant adoption overseas, that pushes up Bitcoin's value everywhere, USA included; geographical differences in price will be arbitraged away. The increase in price might or might not lead to greater US adoption, but it'll still benefit US holders.

Not true at all. The security of the bitcoin blockchain is fundamentally based on mining; after the inflation schedule runs low enough that it's not the major component of mining rewards (which won't be for decades), miners will continue mining, but for the transaction fees instead.