
This passage here from John Gruber’s review of some new macs struck me in particular:
Web browser rendering is surprisingly resource-intensive — partially because modern HTML, CSS, and Javascript are remarkably complex, and partially because most web developers are remarkably untalented and careless programmers
I disagree with Gruber’s take on a lot in tech, but I think this is an accurate representation of what people in tech who aren’t web devs think of web dev.
Our problem is this is the only rational conclusion to draw from experiencing our work.
Of course, my line is that web dev isn’t unique in kind (most of software dev is pretty bad, I even wrote a book about it), but my specific corner of it – web dev – is unique in degree: the web experience is so much worse, on average, and so much more dysfunctional than even the most mundane shitty native app that most people have access to.
The field as a whole either keeps denying there’s an issue or blames somebody else. Usually they blame ads and analytics, but if they were the only problem, then ad blockers would be a genuine cure-all.
I always try to point out that the entire software industry is dysfunctional. It isn’t just web software that’s bad. The software industry management class is woefully undereducated about the issues inherent in software development, which is why they don’t push back against the bad advice they get on web dev.
But the people they’re getting that advice from? By and large influential web devs. Some of them senior. Some of them just senior on Twitter. But, React and its ilk are popular. Most web dev use these frameworks voluntarily, even when working on their personal projects.
And you can’t really just pin the blame on individual technologies.
Sure, Single-Page-Apps and React are objectively not fit for purpose for most websites and web apps. Sure, most frameworks bake in affordances that – over time – pretty much guarantee code bloat and buggy navigation.
But, y’know, our UX design is also awful.
Like, genuinely bad.
Most web apps – even when wrapped in Electron – have the usability and aesthetics of a 1990s enterprise Windows app trying to fit in at pride. Same old, same old, just this time with more colours and grossly misplaced attempts at casual banter.
(Seriously! What’s up with the grossly inappropriate UwU, creepy intimate, backstabber tone of modern software copywriting? Fuck off! You’re a tool, not my friend!)
Or, look at any time web software intersects with social behaviour. Both our collaborative and social software misunderstand basic human psychology to such an extent that it literally costs people their jobs, endangers their lives, and even leads entire societies to destruction (see Meta for a few examples).
Don’t get me started on accessibility.
Next to nothing we do as standard in this industry is right. Many of us – still a minority – have been pointing this out for years, always ignored, and now this is how the world sees us:
Remarkably untalented and careless.
So, just this once, I’d like to suggest that everybody in web dev point their dysfunctional novelty seeking (of which I suffer as well) in the direction of HTML and CSS. See how much can be done without JavaScript. It’s a lot! Then look at writing more lightweight JavaScript that’s layered on top of the HTML as enhancements. Because it’s an enhancement and not required for functionality, you can cut the line higher and use newer tech without worry.
See how refreshing that feels.
Really, really start to invest in user research (actual research) and UX design.
The stuff we put out is starting to look embarrassing.
We’re pretty much the one part of the field of software that would be genuinely justified in throwing out the old ways and trying something new.
That, in and of itself, is an opportunity.
We might not be able to convince our managers, but we can try.
If we’re vocal enough as a group, we can make sure that the misplaced tactics that led us here cease to be uncontroversial standard practices.
We can plant seeds of doubt, and those seeds can grow into the thin end of the wedge.
While you’re here. I’m working on a course on testing and import maps – two things that I think go great together and solve many problems. The pitch page for the course is still a work in progress and I would really appreciate some feed back on it. So, if you have time, have a look and see what you think. Then, if you have the time, let me know what you think on Mastodon, Bluesky, or via email. All feedback is greatly appreciated.
For too long, tree lovers have claimed bragging rights over us prairie folks.
“Our plants live longer than your plants!”
Well, I bet they don’t, but I can’t prove it. However, if you’ll follow my train of logical deduction, I think you’ll come around to my side.
Perennial prairie plants start each season at ground level. That’s true for grasses, sedges, and forbs (broad-leaved plants). Their annual growth comes from buds at the base of the plant or elsewhere near or below the surface of the soil. At the end of each growing season, everything above the soil’s surface dies back and the plants will restart at ground level again the following year. This is different from trees and shrubs, which form buds above ground that help the plant pick up where last year’s growth left off, continually growing larger each year.
These belowground buds give herbaceous (non-woody) prairie plants a big advantage over woody plants when a fire occurs. It’s no big deal for grasses or forbs to restart their growth at the ground, especially if a fire comes through during the dormant season. They were going to do that anyway, so nothing has been lost. Even if a fire burns across a prairie during the middle of the growing season, prairie plants are like, “eh, whaddya gonna do?” and just start again. It might stress them a little, but they’re too cool to complain about it.
Trees, on the other hand, invest a lot of time and energy into growing tall and don’t like it when a fire destroys everything they’ve worked so hard to build. Some kinds of trees take the loss of their investment so hard they don’t bother to start again and they die. Prairie people often call these trees “eastern red cedars”.
Most trees and shrubs, though, can resprout from their own buds down by the ground and begin growing again. They don’t like it, though. You can almost hear them whining about it. If a prairie burns often enough, trees and shrubs don’t have time to grow tall enough to be bothersome (other than all the whining).
Anyway, I was talking about buds…
Because perennial plants make buds at their bases, all they have to do to survive for another year is to have at least one bud ready to deploy when spring comes around. If the leaves initiated from that one bud collect enough sun energy for the plant to produce another bud before the growing season ends, the cycle will continue. Over and over and over again.
Usually, plants have a bunch of buds stored up and ready to use in case of emergencies, such as a growing season fire, a big (or small) grazing animal, or something else unexpected like a hay mower. If something happens that requires a mid-season bud deployment, the plant can quickly respond. During a particularly stressful year, a plant might not store enough energy to create new buds. If that happens, they can still fall back on that reserve of buds created during previous year.
You’re probably starting to see why I’m so confident about the long lives of prairie plants. Of course, you may also be thinking of all the ways a prairie plant might be killed by other factors, rendering their bud bank irrelevant. Factors such as badgers, for example, who might decide to dig a big hole right where a penstemon plant has been happily creating new versions of itself for many years.
That’s fair. Prairie plants need some luck to be immortal, I guess. But we don’t know how long that penstemon plant might have been there before it finally ran out of luck and ran into a badger instead. It could have been hundreds of years or more.
The reason we don’t know for sure how old that penstemon plant was is that herbaceous plants don’t leave a record of their growth. Trees and shrubs make ‘tree rings’ that can be counted to see how old they are, leaving, (according to tree lovers) no doubt about their temporal superiority. The old growth of grasses and forbs gets burned or composted, allowing those nutrients to be recycled.
In other words, prairie plants give back to their communities while woody plants cling to their used organic material in order to retain bragging rights.
Selfish.
Hang on, though. Before you walk away thinking prairie plants would have to awfully lucky to outlive trees, let me tell you about another of their tactics. Many perennial prairie grasses and forbs have underground stems called ‘rhizomes’. They can extend those rhizomes horizontally through the soil until they deploy yet another bud – this time from the rhizome itself – and create a new stem/roots package some distance from the original.
Now there are what look like two plants coming out of the ground, but they’re actually the same genetic individual and (usually) are still connected by a rhizome. Early on in the growth of the new ‘plant’, the rhizome can act like an umbilical cord, providing food to help the new ‘plant’ grow and compete. I say ‘plant’ because it really isn’t a separate plant. It’s all part of the same clone, which in this context, refers to the collective of stems, roots, and rhizomes that are all part of one genetic individual.
Clones can keep getting bigger over time – sending out more rhizomes, creating roots and stems, and then sending out yet more rhizomes. Some plants have rhizomes that are so long that their aboveground stems could be separated by several meters, making it difficult for us to know whether or not they’re connected. Other clones grow outward very slowly and maintain a compact cluster of stems that other plants can’t easily infiltrate.
Rhizomes add a whole new element to the competition between prairie plants and trees. Some perennial grass and forb clones can grow to be many acres in size. At that point, badgers are inconsequential (no offense to my badger friends). It starts getting difficult to imagine anything other than a disease killing an entire large prairie plant clone.
Diseases also kill trees, by the way, so now we’re on a level playing field. Trees grow taller than prairie plants, I’ll give them that. But I’ll put the longevity of a ten-acre big bluestem clone against any tree in the world and feel good about my chances. It might just come down to which one gets hit by a disease first.
The additional advantage a big bluestem clone has, though, is that it’s not prone to the kind of structural damage that often ends the life of a tree. A big, tall tree is supporting a lot of weight with that trunk. Little creatures living inside the tree (invertebrates and microorganisms of many kinds) can start to damage the structural integrity over time. Eventually, many trees simply break under the pressure and die – either immediately or not long after they fall or break off somewhere along their trunk.
That big ol’ bluestem clone doesn’t have to support its own weight. The structural integrity of its stems is of no consequence because it grows new ones each year. There’s really no limitation to how big it can get, other than barriers like rivers, forests, and mountains. Ten acres is probably very small for venerable big bluestem clones. Some of surely been expanding their footprint over thousands of years, making themselves less and less vulnerable to death as they grow. Even diseases might not be able to take out an entire clone if it’s big enough.
Yes, I said thousands of years. Now we’re talking! Most trees don’t live past a few hundred years, at most. Sure, there are exceptions, and I’ll admit they’re pretty impressive. Trees can sometimes live a few thousand years. And, before you tree nerds start barking at me, I also admit there are some trees that form clones, too. I think the oldest known aspen clone in the world is 80,000 years old. That’s pretty old.
I’ll just mention that there are grasslands that have existed since the Oligocene, which – last time I checked – was millions of years ago. Are there grass or wildflower clones that have been alive for millions of years? Maybe. You don’t know. I don’t know. But it’s very possible. (Some people actually argue that the 80,000-year-old aspen clone could be a million years old too, but they can’t prove it. I bet that’s frustrating…)
In my part of the world, today’s prairies have only been around for 8,000 to 10,000 years or so, depending upon the timing of the last glacier recession. It’s very possible there are prairie plants that have been alive since the very beginning of those grasslands. That’s staggering to consider, isn’t it?
Look, since there’s no way to prove whether an aspen clone has lived longer than a big bluestem clone, it seems dumb to keep arguing about it. Let’s bury the hatchet. Ok, maybe that’s the wrong metaphor. But, anyway, let’s just try to admit that both trees and prairie plants are amazing organisms, some of which can live incredibly long lives. Ok?
The incredible longevity of prairie plants is a great message to share with people who aren’t yet excited about prairies. Once you know how long some of those plants have been alive, it’s impossible not to feel a certain reverence as you walk on top of them. (We haven’t even talked about fungi, whose mycelium networks can also live for thousands of years!) It’s just one more facet of prairies that illustrates how truly amazing they are.
Some recentish changes in the WordPress codebase – in particular the “database abstraction” class – have had the unfortunate side effect of cementing MySQL as a hard requirement for that stack. If you took advantage of my post about making WordPress run with SQLite and you’ve updated since, you might be having a bad time right now.
Lucky for you, I’m here to “help”. Or at least get you back up and running, which if you squint kind of might be similar.
This has manifested itself for me in the traditional manner of PHP errors, where nothing visible works but something behind the scenes starts barfing stack traces disguised as web pages into your server logs, because who wouldn’t want that really.
The meat of that error is:
PHP Fatal error: Uncaught TypeError: mysqli_get_server_info(): Argument #1 ($mysql) must be of type mysqli, WP_SQLite_DB\\PDOEngine given in /my-wordpress-install-dir/wp-includes/class-wpdb.php:4143\n
The \n
s all over the place are of a particular flavor, very dog-at-a-keyboard. Where are we, how did we get here, what is even happening?
The comments at the top of the class-wpdb.php file are informative:
* WordPress database access abstraction class.
*
* This class is used to interact with a database without needing to use raw SQL statements.
* By default, WordPress uses this class to instantiate the global $wpdb object, providing
* access to the WordPress database.
… and I think that means they’ve decided to take one abstraction layer that frees you from being locked into a particular backing store and wrapped it in a second abstraction layer that frees you from having to touch the first abstraction layer by doing exactly the opposite, which is I guess a choice you can make.
Anyway, insofar as it affects us today, this means that when you upgrade, you’ll get this wrapper class calling a PHP builtin to check your MySQL version number, and we don’t have that, so…
public function db_server_info() {
// This is _so gross_ but it also works. - mhoye
return "8.2.0" ;
// return mysqli_get_server_info( $this->dbh );
}
… here we are at line 4134 of class-wpdb.php, last function in the file, straight up lying to the computer until it does what we want.
There’s nothing magic about “8.2.0”, it’s the current release of MySQL; it doesn’t matter. There are going to be future circumstances where it does matter, but it looks like dramatic WordPress schema updates are infrequent enough that I think I can burn that bridge when I get to it.
You don’t need to copy in the comment about this whole exercise being gross, obviously, but you definitely should, because this is definitely gross.
If you’re wondering why I’m doing this, the justifications I prefer to deploy are “I’m not particularly fond of having something I personally care about taking a dependency Oracle” and “backing up a SQLite database is just ‘copy a file'”, but the prime motivator is actually “It’s my computer and I’ll do what I want.” For the sake of future searchers – hello, future searchers! – key terms of this exercise are: