Blackcap Blog

Published at 09:06 on 28 January 2026

Fifteen or so years ago, as an exercise in curiosity, prompted by how often I saw the technology mentioned in job listings, I decided to check out Microsoft’s .NET framework. I was expecting to come away feeling smug about how much better competing technologies more popular in the Linux world were.

Surprise No. 1: I didn’t have to just read about it. .NET is an implementation of an open standard called the Common Language Runtime (CLR), and there was what turned out to be a very nice open source implementation of the CLR called Mono. Which I proceeded to install on my Mac and play with.

Surprise No. 2: It (both the C# programming language and the .NET framework) was well designed! This one floored me, given how sucky I generally find things that Microsoft has been heavily involved in. C#’s designers obviously learned from Java’s mistakes, particularly when it came to designing a standard library. And, frankly, they had to do a good job. Unlike its operating systems and desktop environments, which have long been market leaders, and could get away with coasting on their well-established momentum, Java was the clear market leader in virtual machines that ran byte-compiled code. If Microsoft didn’t do a good job, people would just stick with Java, which runs just fine on Windows.

I ended up writing a bunch of command-line utilities in C# and a web site using ASP.NET. It even led to a job where my history as an individual who knew both .NET and Linux servers was the special sauce that got me hired.

But that job didn’t last forever, and there was still a lot of anti-Microsoft tradition that caused most of the open source world to dismiss .NET and Mono out of hand. I could tell I was probably not going to luck out like that again, so I shelved .NET in favour of technologies more common in the open source universe.

Fast forward 15 years and Microsoft has now open-sourced .NET and merged its codebase with that of Mono, meaning the two formerly separate projects are now effectively one.

I have been struggling in the past few days with how to integrate authentication into a web app I am writing. Rolling your own is generally frowned upon (it’s surprisingly complicated; you have to deal with sign-ups, account deletions, forgotten password resets, perhaps two-factor authentication, etc.) But the off-the-shelf solutions available for Python or Node.js just plain suck.

Mainly, they don’t have the flexibility I need. You see, I need access to the actual password used to log in, because I am using it to derive an encryption (and decryption) key used to protect sensitive per-user data in my database. One of my web app’s selling points will be that even I won’t be able to know your secret data. Most authentication services and libraries simply don’t support this: you never see the user’s password, because you don’t prompt for it yourself.

So I check out what sort of authentication systems the .NET world has to offer, and immediately find one that doesn’t suck: one of its key design principles is in fact to let their clients do the prompting for authentication credentials, because, guess what? They just might want access to them, themselves. Cluefulness, what a concept.

Then I find out that I don’t need that product at all, because ASP.NET comes with a surprisingly capable identity management system built in. Which, while it doesn’t let you do your own prompting for credentials by default, does offer it as an option.

Database access is better, too. Most open source object-relational managers (ORM’s) are flat-out terrible. They force you to code all sorts of repetitive boilerplate to mirror what’s already in your database schema*. Instead of simple, logical, expressive SQL, you have to use awkward and clunky chains of method invocations. It’s bad enough that I’ve written my own ORM for Python. It wasn’t that hard, and it’s a whole lot nicer to use.

* How utterly asinine this is becomes clear when one realizes that one of the key characteristics of a relational database is the ability to use queries to programmatically deduce the schema of an existing database. Most ORM’s are, in other words, forcing the programmer to do manually what they could do automatically themselves.

Well, the two most popular ORM’s in the .NET world, Dapper and Entity Framework, are both best of breed. They don’t suck. Entity Framework even has, with C#, query expressions as first-class language constructs.

Then we have file-based routing, where you create a new file and get a new route automatically, something that Apache did 30 years ago (and still does today) but many modern open-source frameworks (particularly in the Python universe) still can’t do. Another win.

Documentation is another big win. .NET has some of the best in the business. Nearly everything is covered by both tutorials and comprehensive API documentation, the latter of which is liberally supplied with examples. It’s not just documentation, either; there is all sorts of help for the programmer in the form of what the .NET world calls “scaffolding,” in which example code can be created for you on request. It’s almost always easier to do something by modifying existing code that comes close to what you want, rather than to start from a completely blank slate.

It’s just generally a better developer experience all around. Normally, you pay for convenience like this, typically in the form of poorer performance. Not this time: ASP.NET sits at the very top of web framework performance benchmarks.

It’s not all roses. .NET is arguably overengineered (just look at function parameters: you have normal parameters, out parameters, keyword parameters, ref parameters, and readonly ref parameters). And there’s at least four different ways to template and generate web pages in ASP.NET.

But while the overengineering is tiring at times, there’s still nothing as bad as the hideous shambolic mess that is the Javascript module and import system. And, arguably, it does make for a lot of choices, choices that I will be taking advantage of to develop exactly the sort of web application that I want.

Published at 16:27 on 27 January 2026

Minneapolis might, just might, be the start of the sort of none-of-the-above grassroots opposition movement of which I have written.

Something is definitely happening there. A longtime anarchist activist who I trust (and whom I have worked with on some actions in years past) has noticed it. Even the staid old Atlantic seems to be noticing it.

The question is: what happens now? Trump is making feeble de-escalating noises. Will people fall for it, or will they realize that when something is wobbling a bit, that means it is time to give it a bigger shove?

Published at 14:49 on 24 January 2026

Executive Summary

1. I can see it perhaps making sense in some corporate situations,
2. I am not personally in such a situation, therefore, it does not make much sense for me, and
3. The Javascript module system is (or should I say systems are) absolute garbage.

How I Got Here

Prompted by data like this, I decided Node.js and frameworks based upon it were worth a closer look, since I am starting a web-based software project for a nonprofit I am associated with.

First, I want to choose something that someone else can easily step in and maintain, and that means choosing something in common use. Second, at least some of what is in common use is likely so for a reason.

A word or two is first necessary on that chart. It’s what pops up highest when I ask Duck Duck Go about the most popular web frameworks. I did once find out the source; it was a poll taken at a major conference of web developers in 2024. So it is actually based on actual real data, which is more than one can say about most lists of top web frameworks. But Node.js is not a web framework; it is an implementation of a programming language, Javascript. Why this is so becomes clear if you scroll down the right sidebar and look at the question asked, which was about “web frameworks and web technologies [emphasis added],” and not strictly frameworks.

But I digress. There are frameworks based on that language, however, which come up repeatedly (and are the top rankers) in that chart.

I’ve dabbled in client-side Javascript over the years, simply because one cannot avoid doing so. It is just not possible to do all that needs to be done purely in declarative HTML. But the key term here is “dabbled.” I have deliberately avoided the sort of Javascript overuse that harms the user experience for so many on the Web, but it is still relatively easy to run into situations for which the easiest and simplest solution is a little bit of client-side scripting.

So I install the latest version of Node.js, and because I have personal experience with how Javascript’s lack of static typing makes it easy to write and difficult to find coding errors, I install Typescript as well.

Module and Import Hell

Right off the bat, I run into obstacles of the sort I seldom do with a new programming language. Typescript blows up, big time, spewing error after error for a small snippet of code that has absolutely nothing wrong with it so far as I can see. After some time, and some sleuthing on the Web, I pinpoint the cause as having my import resolution options incorrectly configured.

Which right off the bat shows that said subsystem is hot garbage in the Javascript world. Just for openers, there’s at least three kinds of modules. Most all programming languages get by fine with just one, but not Javascript. Modules and imports are super-simple in most programming languages. There should be no need to configure things. Imports should just work out of the box, like they have for the vast majority of the world’s programming languages at least for the past fifty years or so.

If you have to write a lengthy web page to explain how your programming language’s imports and modules work, long enough to require a special summary section, and that summary itself takes up three screenfuls, you have a problem.

I finally figured it out and got my test script to compile, but I basically blew a day doing so, and it’s still largely a crap shoot for me how to properly import a given module, because the rules are so complex and I have yet to fully internalize them.

To reiterate: this aspect of Javascript is hot garbage. No other honest assessment is possible. Javascript does modules and imports worse than any other programming language I know of.

Random “WTF Javascript” Stuff

Javascript has more than its share of strange quirks. Most of these are related to it being a weakly-typed language. Probably the worst thing is that Javascript has two sets of equality and inequality comparison operators, which differ in the details of the type coercion they apply to their operands (most languages get along just fine with one). More than one web site is dedicated to pointing this all out.

While this does make for a quirky and sometimes annoying experience, it doesn’t rise to the level of malicious complexity, bordering on total unpredictability, that the module and import system does. Moreover, a lot of it simply comes with the territory when one has a dynamically-typed language. For most of the “WTF Javascript” examples I have seen, if I feed the analogous expression to Python (which is famed for being a “clean” and logical language), I get a similar result. So I could have coped with this if it was all there was.

As such, I almost didn’t include this aspect of the programming language in this article. But I figured I’d mention it here because if I didn’t, people would keep commenting and telling me about it.

Generating HTML with JSX

Why did I persevere? In part because of JSX (and its Typescript analogue TSX). It’s really quite the clever innovation for generating HTML. Not quite so clever as it first appears, but it’s still pretty nice. It’s definitely the easiest and most logical way (and one of the most powerful) ways of letting the user generate custom markup tags that I have run across.

Eventually, however, the conclusion was inescapable: there is just too much mismatch between Javascript and what I want to do for a 100% Javascript framework to make much sense for me.

Event-Based Programming

Javascript gives the programmer a single thread and an event-based programming model with a dispatch loop. It’s evidently very efficient; benchmarks give Node.js a decided edge over alternatives such as Python.

I think, however, that in most cases this is a “so what?” moment. Benchmarks give C and C++ a decided performance edge over languages that do automatic memory management. Yet most programs are no longer written in C/C++, because the mental overhead of dealing with manual memory management is a drag on programmer productivity, and the overhead of finding and dealing with memory mismanagement bugs is an even bigger drag yet.

My contention is forcing the programmer to manually manage threading and context switching is approximately as much a drag on programmer productivity as is forcing him or her to manually manage memory allocation. And just like the latter has the automated solution of garbage collection to relieve the programmer of cognitive load, the former has the solution of preemptive multithreading.

Yes, it’s not as fast. Again, so what? Processors are faster than they have ever been. Raw speed is not nearly so important as it once was.

And how much faster is it? The figure thrown around on the Net is that Javascript comes out 40–70% faster than Python for back-end web software. Frankly, that is a very modest improvement, considering that Python is one of the slowest languages out there. What happens when you compare Node.js platforms to those coded in compiled languages? Let’s just stay it starts looking a lot less impressive for Node.js.

It also must be mentioned that while Python’s ability to multithread has historically sucked, it is about to get a whole lot better.

Culture, or Tradition Being Mightier than Innovation

One of the most overlooked aspects of any framework is the culture and traditions that have evolved around it.

Java really isn’t that bad a language, when you consider its core features. Sure, it seems dated now, but that design represented state-of-the-art consensus in the 1990s. That Java is still around after all those years shows its design got at least some things right. The problem with Java is all the dysfunctional culture and traditions that are present in that language’s community.

Well, part of the traditions of Javascript is where it started: in the browser, as a relatively simple scripting language that was thrown together in a hurry. That use case grew, eventually growing to encompass server-side code, and the language acquired more features as a result. There was never a great deal of careful planning in the process; features were just added in a mostly ad hoc manner, as needed. Sometimes this resulted in features that didn’t grow well (this is the source of much of the module and imports mess).

Because of this history, there is this hidden implicit assumption in the Javascript world that web pages will have a lot of Javascript in them. Javascript frameworks, even server-side ones, tend to make this the path of least resistance for doing anything. There is, to put it mildly, insufficient appreciation of the pitfalls of doing this in the Javascript community, both client-side and server-side.

Javascript frameworks make it easy to write web pages with lots of Javascript in them, pages that perform poorly on mobile devices and when networks are slow. They make it difficult to write anything else.

The Real Argument for Javascript

It’s that there is currently, and has historically been, no alternative for client-side scripting. Web Assembly is in the process of ending that, but it has not yet done so. Plus sheer momentum means that Javascript on the client side won’t be going away any time soon.

So there are a lot of workplaces that have teams coding in Javascript for the front end. Probably too many of them, given the current overuse of client-side scripting, but I digress. Javascript is already in use, and wouldn’t it be nice to be able to move people between the front-end and back-end teams as demand for labour requires? Or maybe get rid of the front-end and back-end distinction and just hire for full-stack positions? If all the code was in the same programming language, that would be a whole lot easier.

And, fortunately enough, it just so happens that there are server-side implementations of Javascript, and while they can’t match the performance of compiled languages, they actually perform very respectably for an interpreter. Major win!

And that explains the current popularity of server-side Javascript.

But That Is Not My Situation

I am developing a service that I want to work as well as possible on mobile devices with subpar Internet connections. That means, wherever possible, using plain HTML, eschewing the Ajax pattern (which I consider mostly an antipattern). I don’t need deep Javascript knowledge to do that.

I am not trying to bully people into installing a custom app (which then proceeds to make me money for me by spying on the user) by having my web site be slow and unusable on mobile devices, because I am not a slimy capitalist. I don’t personally have the time to write both and app and a website, so just writing a mobile-friendly website serves my best interest as much it does the user’s. Win/win!

I already know Python well, and Python is squarely within a virtuous cycle of programmers with healthy design patterns attracting other programmers with similarly healthy patterns. The Python standard library is more comprehensive than the one for Node.js. The overall quality of open-source, third-party Python libraries in my experience exceeds that in the Node.js world. Python’s modules and import logic are sane, not a shambolic mess. Python allows event-based programming but doesn’t force it on me.

While Python isn’t the No. 1 back-end web language, it is No. 2 or 3, and over all, for all uses (not just the web), ranks No. 1. As such, there are plenty of Python web frameworks out there. While they are not as performant as Node.js frameworks, they aren’t that far behind, and should do a fair bit of catching up soon.

And so far as recoding if I want better performance, I have written web sites using C# and ASP.NET (currently sitting at the very top of the benchmarks, and no, you don’t need Windows to run it), and I found it an easier technology to adapt to than Javascript (just for openers, there is but a single module and import system, and it behaves predictably). Even old-school Java Server Pages, when built with a simple and predictable build tool like Ant, was less painful. Why should I choose an option that has more pain and less performance?

Node.js just doesn’t seem to make much sense for me.

Published at 08:22 on 20 January 2026

You promise an unflinching and united response should Trump decide to seize Greenland by force. Soon you will have to deliver one.

Because of course you will. Trump’s entire life, starting as a small child born into extreme wealth and privilege, has taught him that in a bourgeois society all men are not created equal, and that the children of privilege like himself can personally profit by being a liar, a bully, a cheat, and an overall scoundrel. And he has profited like few men in history have.

His entire life has taught him that he can seize Greenland and not only get away with it, but personally profit from it. So of course he will at least make a serious attempt at it. No other course of action is even remotely plausible. Sorry.

At that point, it becomes up to Europe to put up or shut up. If they choose the former, there is a chance — actually a fairly good chance — of engaging TACO mode, much like China did in response to Trump’s tariffs.

If they choose the latter, kiss Greenland goodbye. And then Canada comes next.

And you can spare me any thought of pushback from Republicans stopping this internally before the Europeans have to stop it externally. Rule No. 1 violation. Not gonna happen.

The world let Trump get away with Venezuela, and the lesson Trump took from this is that he can get away with subjugating Denmark and Greenland, too.

The proper reaction to what Trump did to Maduro would have been something along the lines of what Churchill alluded to when he once said, “If Hitler invaded hell I would make at least a favourable reference to the devil in the House of Commons.” But for the most part that didn’t happen so here we are.

Maybe it will matter more this time. Greenland is full of brown people but Denmark as a whole is a first-world country full of white people, so if it matters more this time, that, and not any lofty principles about national sovereignty, will be the real reason behind it all. But we have to take our resistance to fascism however we find it; it is an imperfect world.

Published at 06:34 on 16 January 2026

And this is fundamentally the reason why.

It was the correct decision in the overall context, as difficult as China’s dismal human rights record makes it. At least China can reasonably be expected to follow through on the deals it cuts, which is more than one can say for Trump’s USA. And it is not China that has been threatening to annex Canada.

Now the question is how the fascist regime south of the border takes the news of the obvious consequences of their behaviour.

Published at 10:30 on 15 January 2026

If you look at most lists of the most popular web frameworks,
React ranks at the top. (Node.js is not a framework; it is an implementation of the JavaScript programming language. It turns out that the question which prompted that survey response was about “web frameworks and web technologies,” not strictly frameworks, which explains some of the answers listed.)

It explains why so many web sites suck, particularly when used on smartphones and in other situations with slow network connections. The entire premise of React seems to be that everyone has a speedy connection to the Internet.

React is sold as a framework that does server-side rendering. This is highly misleading. Yes, it does do some rendering on the server, but then it repeats the entire exercise on the client. It is part of how its process of “hydration” works, by creating a second entire document object model called the VDOM (virtual DOM), then reconciling the differences between the VDOM and the DOM. It does server-side rendering merely to help conceal what a slow, booger-eating fat pig it is under the hood.

And it can download a lot of code to do this. I created, as a test, a simple “hello, world” page using React and Next.js. When I say “hello, world” I mean it literally; that two word sentence was its entire content. It was about half a megabyte in size. I am not making this up: half a megabyte. For two words.

Now, Next.js has something of a reputation for page bloat, but still. It is also sold as doing server-side rendering, which misled me into thinking maybe it could deliver reasonably-sized content.

The root of the problem is a React design goal, that of so-called isomorphic code, wherein the exact same code runs on both client and server. This inevitably leads to an unnecessarily excessive amount of JavaScript being sent to the client. Forcing the programmer to be aware of the distinction between client and server is actually a good thing, as it leads to more performant code.

There are far better ways to use JavaScript. I just wrote a small web application using Express JS and the rendering engine from an open-source static site generator (because the latter allowed me to use JSX).

It is not a minimalist “hello, world” page; it has interactive content. It does hydration, too, by hand. Since I hydrate the page by hand, I have complete control over how much client-side rendering I do, and how much of a JavaScript payload burden the page has.

Total size of all assets sent to the browser: under 10 kbytes. Yes, it’s that simple. No, it is not isomorphic. So what? Again, the entire size of the page, both procedural JavaScript and declarative HTML and CSS, is under 10 k. Hardly a great burden of additional complexity. So much of the bloat you see on modern web sites is the result of pure laziness and dubious design decisions. It doesn’t have to be this way.

React, I think, is rotten down to its very roots. It was developed by Meta, the Facebook people. They don’t care how much their site sucks on mobile devices. In fact, they actively want it to suck, because they would prefer people install their app, which spies on their users. React is a framework that reflects the moral bankruptcy of the organization who sponsored its creation.

Published at 07:10 on 14 January 2026

As months tend to be when the world’s sole remaining (for now) superpower is in the process of an ongoing Gleichschaltung. But not much of it has really been any sort of surprise to anyone paying attention.

It’s been obvious for some time that some sort of military action was coming with respect to Venezuela. It has also been obvious that a Kent State moment or two was inevitable.

The targeting of Jerome Powell is also no surprise. Fascist leaders desire absolute power, and quasi-independent agencies like the Federal Reserve are incompatible with that desire.

I have been busy with computer projects other than this blog, that is all.

Published at 11:15 on 17 December 2025

Last night was the worst windstorm since moving to my current location four years ago. Normally the ridge to my south protects my locale from high winds. Not last night.

Didn’t get much sleep between the heavy rain slamming into my window like rain in a moving car hitting a windshield while going down the freeway, the house creaking and shuddering, and various bits of debris blowing around outside. At one point, some structure on my block with a metal roof started losing a piece of that roof, which really made a racket.

Somewhat impressively, the electric power stayed on through it all.

Published at 15:40 on 15 December 2025

Back in 2019, I wrote:

The pity is that once one does things other than Android software development in Kotlin, the rough edges in its ecosystem quickly become all too apparent. Just out of curiosity I’ve been playing with the Ktor server-side framework. The documentation ranges from flat-out obsolete (and thus incorrect) to simply nonexistent. The result is that even simple things take hours of tedious experimentation to determine how to do.

I’m hoping that Android development goes better, but unless those rough edges get smoothed out, and soon, Kotlin may well end up being stereotyped as an Android-only thing.

Only last month, I wrote:

The big problem with Java is not the language, it is the culture around the language. I have a friend with a number of pet sayings, one of which is “tradition is mightier than innovation,” and that certainly applies in spades to Java. There’s just so much bad tradition enshrined as respected convention in the Java world. I call the result Java Community Antipatterns or JCA’s for short.

      ⋮

If it weren’t for the JCA’s, Kotlin would be a near-ideal programming language. If it weren’t for the heat and dryness, Phoenix would have a near-ideal climate. (And aside from that, Mrs. Lincoln, how did you enjoy the play?)

But, I ended up concluding:

The Java community’s faults may be legion, but Java set out to be a “write once, run anywhere” language, and its virtual machine has to this date succeeded at that goal better than any other such environment of which I am aware.

So I’m back to coding in Kotlin, and once again Kotlin’s nemesis becomes clear. It is its proximity to the Java universe, and by implication the universe of JCA’s.

The Java virtual machine’s advantages make the concept of a language like Kotlin tempting. It is why JetBrains decided to create Kotlin. It is why I have been coding in Kotlin.

Unfortunately, realizing that concept is a very tall order. Quite simply, it is not exactly easy to take a complicated, badly-designed, antiquated ecosystem and attempt to layer a more rational, more modern, more well-designed one on top of it. This problem becomes all the more acute if said ecosystem is associated with a culture that has enshrined harmful antipatterns as part of its respected traditions. The Kotlin development team is obviously trying as hard as they can, but it doesn’t matter: their effort still falls short.

I am picking up a project I put aside about five months ago, due to a need then to focus on other more pressing goals. Then, I had foundered for some time on serialization. Kotlin has what is in theory a great serialization subsystem. Of course, given the Java world it was layered on, it took no small effort to implement it. And the latest version of Kotlin at the time hadn’t quite got its implementation right; I was getting bitten by those bugs, which were causing my code to throw exceptions and die. JetBrains was aware of those issues, and planning to fix them in the future, but that didn’t help me in the here and now. Eventually, after blowing several days on the issue, I found the magic combination of an older Kotlin compiler and serialization library that did not make these bugs manifest.

That resolved my issue, but enough time had transpired that when I recently resumed my efforts, one of the things at the top of my agenda was to upgrade to the current versions of things and see if JetBrains had fixed the bugs. I did, and they had. So far, so good.

The problem is, the build system (based on the Java universe’s Gradle, which coming from the Java world is the standard shambolic mess you find in that world) has now for some reason started producing a corrupt Jar file. The jar command-line utility can list and process the Jar file. It can locate the class I am trying to invoke. Yet when I attempt to invoke it, the JVM claims it cannot find the class.

So now I have to troubleshoot that build system and figure out why it is (once again) failing me. And this is the sort of shit that keeps coming up in the Kotlin world, simply due to its proximity to the Java one.

Where this goes, I am not sure. Maybe I will find a resolution or a workaround, like I did the last time the build system started spitting out Jar files that were corrupted in a slightly different way. Maybe not. Maybe I will just give up on Kotlin, despite its advantages, because the disadvantages simply outweigh them.

Published at 08:56 on 14 December 2025

Yes, I know that Trump is not exactly doing too hot in the polls right now. Political strategist Rick Wilson is positively giddy about it.

I have argued recently that a blue wave or two is likely to be significantly less consequential, in the long run, than many people think. Now I wish to argue that the hypothetical blue wave might not happen at all.

The reason is simple: war. Americans are, on the whole, an astonishingly ignorant people when it comes to foreign policy. This ignorance is no accident; Establishment politics has carefully tended and nurtured it for many decades. All the better to help prevent democratic accountability from interfering with military adventurism. It is one of the natural consequences of being a superpower, and a key reason why superpower status is a threat to free society.

Any administration that starts a war historically gets an incredible amount of deferential treatment from the mainstream media, the purported opposition party (both parties are united in their support for empire), and the populace as a whole. Do not think for a minute that this cannot apply to a war against Venezuela.

Maybe it won’t. We’re not that far past getting burned by the consequences of past deferential treatment for wars in Iraq and Afghanistan. Maybe this one will come too soon on the heels of the earlier ones.

But don’t be too sure about that. It is at least as plausible that Trump will succeed in selling his Venezuela war. The authoritarian regime that runs Venezuela is not precisely the sort of government to inspire sympathy. Advocates of war will be able to paint opponents of war as Maduro allies or sympathizers, a characterization made all the easier by the shameful reality that it is not very hard to find American leftists that are allies or sympathizers of the Maduro regime. The Establishment media, already in many cases cravenly capitulating to Trump, could very easily once more assume its historic role as propagandists for the ruling class’ latest war of choice.

If this happens, Trump could easily prevail in the next few electoral cycles. I am quite sure, in fact, that this is a huge part of why Trump seems eager for a war with Venezuela. I will give the man credit for one thing: he knows advanced state of moral decline of the nation he leads better than virtually anyone else in the halls of power, and he has used this knowledge to become what is already one of the most successful, effective, and consequential presidents in U.S. history.

Yes, successful and effective. He has made more change, more quickly, than any president since FDR and quite possibly any since Lincoln. It is now part of established political precedent that U.S. presidents may incite coups to attempt to stay in power, can lie about just about anything, can make law and policy by fiat with little or no input from Congress, engage in crass nepotism, receive bribes, and cannot and should not be held accountable under the law.

To assume that a war in Venezuela will fail to keep Trump in power is to assume a moral and informed American public that, by and large, simply does not exist. See Rule No. 3.