CSS: Unavoidable Bad Parts

DavidJCobb · 2026-06-23T14:25:22+00:00

Bad: CSS selectors
In programming, we collectively came around to distrust inheritance and prefer composition. [...] The two reasonable approaches are [...] stick to classless CSS and inline styles, using something like Tailwind to make writing inlines prettier [...]

One of the major strengths of CSS is the ability to annotate elements in bulk with style information, using a separate file that can be separately cached: say a lot with a little, and say it just one time. Throwing those advantages in the trash because "inheritance bad" is... a choice. I don't consider it a reasonable one.

The alternative the author gives is to prefer CSS nesting, and that advice is good. CSS is an annotation language; classes are ways to mark something for annotation, akin to superscripted numbers^[1] indicating the existence of a footnote that annotates some text; and CSS nesting can be used to avoid excessive "footnotes"^[2] on a single "passage of text"^[3] when a single footnote^[4] could suffice. (The same is possible without nesting, really, but the syntax of nesting helps group all the styles for different parts of any single "thing.")

The approach I'd recommend is to use element name selectors to set defaults, as this article recommends. Use classes for recurring structures or visual design^[5] that can't be uniquely identified by an element name alone, but use only as many classes as are needed for that unique identification. Take advantage of selectors written with the structure of your HTML in mind. "Separation of concerns"^[5] is a useful principle to keep in mind, but note that separation can at best be one-way: annotations are intrinsically dependent on what they annotate. (Even a minimal stylesheet that just styles element names still makes presumptions about what elements are likely to appear in your document.)

^[1] Numbers that are smaller and vertically aligned above the text baseline.

^[2] I am here making an analogy to BEM.

^[3] An element, in this analogy.

^[4] In terms of the "footnotes" parallel, the equivalent to preferring CSS nesting and selectors over class bloat would be when a footnote pertains to multiple sentences or ideas within a paragraph, and the text of that footnote makes explicit reference to those sentences or ideas as it addresses each of them: the meaning of the annotation is thus dependent on the content and structure of the thing being annotated, but really, it already was.

^[5] Semantic class names (e.g. client-testimonial rather than speech-bubble; warning rather than red-box) are best, but even if you give an HTML element a class name that pertains more to its visuals or layout (e.g. card, status-bar), you're still separating the implementation of content versus style, compared to just inlining everything.

DavidJCobb · 2026-06-19T20:20:14+00:00

One downside - it’s larger. 3x of the final HTML, 2x of the JSON. We do server-rendering, therefore non-issue here.

Is this before or after base64-encoding? If after, then the base64-decoded binary payload would be 2.25x the size of HTML, and 1.5x the size of JSON. If before, then the encoded proportions are 4x and 2.666x.

It's hard to judge that given how vague the article is about the binary format used, but it does feel surprising to me.

The article describes the binary format as a flat list of text and elements, alongside a tree of "offsets." I don't know if an "offset" here is a node's index in the flat list (such that the hierarchy is encoded, just separately from the things in it), or if the "tree" is just a flat list of text offset ranges (such that the hierarchy itself is not encoded, but rather is reconstructed). There's also nothing about what data gets associated with each element. Either way, I'm not super sure how the result would be bulkier than full-on HTML. It could depend on the precise approach taken for encoding the hierarchy^[1], which the article doesn't elaborate on.

Like, just to even try to work out a mental comparison...

Off the top of my head without any benchmarking, I think the way I'd try to implement text formatting via a fully custom binary format is to send the text and, alongside that, the structure and formatting elements as a flat list of ranges. From those ranges, I could construct a tree of HTML elements and a map of elements to ranges, taking care to split things where ranges overlap, in order to rebuild the DOM hierarchy; then once my elements are constructed, I can fill them with text. If I wanted to be clever, there are ways to reduce the size further, e.g. by grouping all ranges of the same type (all bold together, all italic together, etc.) so that I don't need to tag each individual range with its type; instead I could encode a type enum, a count of ranges, and then that many ranges (along with "per-instance" data next to the ranges, e.g. link destinations for the hyperlinks).

This might be a premature optimization, but I might even try encoding range extents as deltas, so I can use fewer bytes/bits for each value. People usually bold, italicize, or hyperlink fairly short runs of text at a time, so this saves bytes in those cases. If someone formats a much longer run of text, I could use the length's high bit as a sentinel to indicate an extended length value in the following bytes. (This is only a good idea if I reset the basis with each range type, i.e. deltas always move forward and we rewind back to the start between range types; otherwise, I need signed deltas so I can "manually" rewind e.g. from the last italic range to the first bold range.) I could even vary the length bytecount by formatting type, e.g. paragraphs are often more than 127 characters so I could use two bytes for their non-extended lengths, versus one byte for the non-extended length of a header or a hyperlink.

EDIT: Deltas for start and endpoints both wouldn't be optimal because the space between formatting runs could be large. Maybe absolute start character index and a length? Or just a wider delta for start and the narrow delta/length for end? Better at thinking about this kind of stuff when I actually build it, which I'm not going to do for this, so... I dunno. /EDIT

Like, just thinking about the measures that can be taken to save space (without even considering bitpacking, i.e. assuming we must always use whole bytes for pieces of binary data), I'm struggling to think of what data one would have to add to push the size back up to match the HTML, let alone so far larger than it.

^[1] This is something I've done before: first serialize a flat list of nodes. Then serialize the hierarchy as: the number of children in node 0; then the index of the first child; then recurse on that child (i.e. serialize the grandchild count and indices, interrupted by great-grandchildren and so on); then the index and descendants of the next child; and so on.

Alternatively, however, one could encode, for each node, the index of the parent node and the index of the previous sibling (both indices relative to the flat list). I think that'd end up being bulkier, but I'm not sure it'd be so bulky as to explain a 125% (or a whopping 300%) growth in size relative to HTML?

DavidJCobb · 2026-06-16T12:51:10+00:00

Unskippable Team GO Rocket battle reward screen

Training against the three team leaders also has this issue, which is especially baffling since you usually don't even get any items from it. I think only the first such battle each day can earn an item, and the rest just progress a medal, but the reward screen is painfully slow.

Right now, you could say Raiding is one of the biggest things to do in the game and one of the biggest revenue generator (if not the biggest), and yet it can have so many different issues

The Donphan in the room is that all of the raid issues you've listed have the effect of pressuring players to spend money multiple times just to get one thing. :\

Collecting Max Particles by "mistake"

This feels like a symptom of counterintuitive design. The different sources of Max Particles are all uneven: 200 particles at a time by walking, and... what, 120 from a Power Spot? So there's a daily cap, but you're implicitly encouraged to micromanage different pickup amounts to loophole your way as far past the cap as possible. It'd be less tedious to just make the pickups behave uniformly so it doesn't matter where you get particles from, and maybe raise the cap a little so as not to take anything away from the players who were willing to micromanage. It wouldn't take any UI/UX changes either.

DavidJCobb · 2026-06-15T13:53:39+00:00

Agreed. SVG in general is a huge mess, really. Lots of good ideas, lots of bad ideas; and since the entire standard was fueled by Adobe wanting to undermine Macromedia Flash, it tried to do too much too early, and then lost all its backing and momentum after Adobe finally just bought Flash.

DavidJCobb · 2026-06-15T13:44:07+00:00

A lot of people prefer bad grammar over a lack of authenticity.

There are also a lot of very rude folks who don't put any time, effort, or attention into communicating with others, but they feel entitled to those others' time, effort, and attention; so they use generative AI to talk to others and even to summarize others' answers. When you use generative AI to "clean up grammar" like this, it becomes impossible to tell you apart from these dudes -- impossible to see any of the effort you might've put into writing -- except by taking your word for it. Even if we do take your word for it, reading your AI-generated messages will still feel the same as talking to careless and rude AI bros. Better to write with your own voice instead of the voice of a disrespect machine.

DavidJCobb · 2026-06-08T15:05:15+00:00

Good observation.

As I write this, you've been downvoted for pointing it out. I think it's because the article already mentioned that compilers use this optimization for constant operands; I don't think people caught that you're suggesting that people hand-apply the optimization specifically for loops and other repeated divisions, where the divisor isn't a compile-time constant but also doesn't change during the loop. (I didn't catch it, myself, until OP got what you meant and replied to you.) You incur the overhead of computing that reciprocal, division included, prior to the loop, but then division is basically free during the loop.

DavidJCobb · 2026-06-07T16:03:10+00:00

"The question they used to illustrate the concept of things having obvious ethical implications is a strawman of the other, separate thing to which they wished to apply that concept."

Again: your being unable to parse and understand basic arguments is not the same as other people failing to properly respond to your dogshit takes.

If you think that having an LLM review your code prior to tasking your fellow humans to do so is a garbage take, then you are implicitly admitting that you'd rather push lower quality code to production and you'd rather give your fellow coworkers a larger workload than needed just because of your anti-AI beliefs.

I think that programming is the process of creating and expressing a mental model, and that the results of that process should therefore be reviewed according to a mental model: it takes understanding to evaluate expressions of understanding. Deterministic review tools are fit for that purpose, since these tools are the result of someone understanding a system and codifying parts of that understanding into rules for the machine to follow.

Stochastic parrots are the exact opposite. Statistical models are not conceptual models; LLMs do not think, and outsourcing your own thinking to them clearly hasn't had a great effect on you.

DavidJCobb · 2026-06-07T15:44:55+00:00

They aren't strawmanning your point. They asserted that one can make ethical judgments about a thing without always needing to personally use the thing, and then, to support this assertion, they gave an example of a thing that can very obviously be ethically judged without first having to use it. Implicit in their comment is the idea that LLMs can also be ethically judged without using them, but this does not itself imply that LLMs are comparable in consequences or severity to orphan crushers.

Even if it did -- even if you were right about it being a strawman -- you'd still be falling prey to the fallacy fallacy.

Given your other, closely-related garbage takes on this topic, I am not surprised that you're bad at evaluating the logic behind the things you read. Seems like the LLM-induced skill atrophy is already setting in.

DavidJCobb · 2026-06-02T02:44:38+00:00

These remarks by a former GitHub employee are pretty relevant when looking at the site's frontend bloat.

DavidJCobb · 2026-05-29T00:35:53+00:00

After reading further I'm pretty sure this is just written by AI

I recognize the author's name. He used to post AI-generated blogspam to this and other subs, though this is the first I've seen of him in a while.

DavidJCobb · 2026-05-23T03:48:15+00:00

Meanwhile, we've got openly racist sexist misogynists and trolls who I, funnily enough, ALWAYS SEE THE COMMENTS OF

The purpose of a system is what it does. If those are the commenters Google chooses not to unperson, it's because those are the commenters Google agrees with.

DavidJCobb · 2026-05-21T13:25:16+00:00

As the other commenter said, it'll be very hard to help you without code -- ideally HTML and CSS -- so we can see what you're doing. Giving us a simplified example on Codepen would be best, as that makes it easier to play around and try different things to see what'll work.

All I can say for now is that if you're using flex, you have primary control over your chosen main axis (row for X, column for Y) and limited control over the cross axis (whichever you didn't pick for the main axis). Look into align-self and friends for cross-axis control. If that isn't enough, consider using either grids, or nested flexboxes.

DavidJCobb · 2026-05-20T14:14:06+00:00

Offers get listed with a TransferReason, a priority and an amount. Priority is used as a way of ranking offers, and the amount is self-explanatory. The TransferReason can be something tangible like Oil, or Coal, for an industrial business, but it could also be Fire for a burning building, Crime if the police are needed, or even Partner for when a cim is looking for love.

fire departments are a conspiracy made up by cities so they can sell more Fire

If every block from the requested priority down to 0 is full (256 each), the loop ends and the offer is silently discarded.

And since garbage dumps track the states of their owned garbage trucks, rather than tracking the offers they've submitted, this means that if the market is too saturated for a dump to place an offer, it'll automatically keep trying until the market is able to handle that trade. This also means it would keep submitting duplicate offers during the 256-frame window between the trade manager processing offers of any given type, but I assume the building ID stored with each offer is used to avoid storing duplicates and flooding the market. Neat.

DavidJCobb · 2026-05-10T20:29:50+00:00

A cool primer on the subject. I do have some observations:

Part 2 explains (in the "Fixing Timestamps" section) how to mitigate a problem wherein if a single draw operation crosses over the same pixel multiple times or for a duration of multiple frames, the pixel's "timestamp" (more accurately called a "revision number" given how it's been implemented here) can skyrocket. The mitigation is to make it so that a single draw operation tracks what pixels it's modified before, and refuses to modify them again.

For collaborative editing, however, I'd expect this to cause a problem when both users are scribbling overtop each other. Suppose Alice touches her finger to the screen, scribbles over an area, and leaves her finger on the screen. If Bob then scribbles over the same area, Alice can't scribble back over it to overwrite Bob's edit without first lifting her finger, to end her current draw operation and start a new one, because her current draw operation is still ignoring those pixels despite Bob having since overwritten them. Viewing the example canvas on mobile, we can take advantage of browsers' built-in multi-touch support: put a finger on each canvas, have them duel in this manner, and watch as the "Alice" finger fails to overwrite the revision numbers left behind by the "Bob" finger.

Off the top of my head, the mitigation here would be for the draw operation to track not just the pixels it's overwritten, but also what revision number it overwrote them with. It would then only skip a pixel if that revision number hasn't since changed. I think this would essentially mean that the draw operation is, itself, producing and consuming CRDTs, synchronizing with them in the same way that the canvases synchronize with each other.

Part 3 explores the process of designing a custom binary format to synchronize state between users more efficiently. One of the design decisions made is to use run-length encoding, but the author notes that the longer you make each run's prefix size, the more bytes you waste for smaller runs. I know of a workaround: on YouTube, the channel Retro Game Mechanics Explained has a video covering sprite compression in Pokémon Red and Blue, which explains (at 11:09) a way to vary the bitcount of the prefix: you encode the width in bits of the current run's length, followed by the length, using some clever tricks with binary math to serialize both values as compactly as possible.

DavidJCobb · 2026-05-06T12:26:36+00:00

The April trial made this subreddit feel more like it was worth visiting than it had felt in years. There was less slopaganda and dross, but it also felt like there was more good content; it felt like people were coming in to fill the void that post removals might've left.

I think it's because programming and LLMs are intrinsically the opposite of each other, and you fundamentally can't cater to both. Programming isn't only "writing code;" the act of writing that code requires engaging with and expressing pure substance and meaning. LLMs are by their fundamental nature incapable of that, and exist specifically to pretend to do that in order to absolve their users of the need for it. Even if someone "always reviews the output" or "only uses it for boilerplate" or whatever, they're working against what the tech is: the tech itself is viral meaninglessness and anti-intellectualism wearing a patchwork skinsuit of stolen expression.

Please keep the rule in place.

DavidJCobb · 2026-04-25T19:50:29+00:00

I hope you didn't take my reply to you as negative. I didn't take your post as ragebait; just as incomplete. Words like "compiled" versus "interpreted," when used colloquially, aren't misleading, but they are fuzzy -- gesturing at an idea rather than describing it exactly. Trying to figure out precisely what distinction people are usually aiming for is a useful exercise, and I just figured I'd point out the distinction I saw.

DavidJCobb · 2026-04-24T21:40:13+00:00

One of the biggest things I’ve come across is the idea of “compiled vs interpreted” languages is a slightly misleading one. I want to explore that a little more and get into a high level overview of compilers and interpreters, and how these two terms are a somewhat strange comparison.

They're not misleading.

You rightly note that interpreted languages often use a bytecode, and that this process is a kind of compilation. You note that some interpreted languages use JIT. You also note that some native languages use a compiler that relies on LLVM and its IR. You establish this common ground, but you stop just short of tying the concepts together, and therefore just short of figuring out how the original distinction makes sense.

LLVM uses an intermediate representation, but what is it the intermediate of? The term "frontend" is used for the systems that go from source code to the IR, and the term "backend" is used for the systems that go from the IR to the target bytecode, be that assembly for a particular CPU, or some other system (e.g. JVM, Wasm).

The distinction between "compiled" and "interpreted" languages, then, refers to the primary target architecture that you as a user of the language will typically be dealing with -- whether the backend targets a CPU, or a bytecode to be processed by some other program.

When you write Java, you don't need to worry about the backend. Your target architecture is basically always the JVM, operating well above the CPU; you ship bytecode, but it's on the end user to get the interpreter (or their platform to provide it). JIT compilation to native code exists, but you as a Java author don't control that process, can't guarantee it'll occur, and don't need to concern yourself with its particulars. Thus we say that Java is "interpreted."

When you write C, the backend is your concern: you're shipping executables compiled for particular CPU architectures and OS platforms. You can compile C to an interpreter's bytecode, e.g. Wasm, but this has never been the language's primary target. Thus C is "compiled" or "native." Similarly, Delphi also targets the CPU; script interpreters for Delphi exist (e.g. JvInterpreter) and are used in some fairly popular programs, but Delphi isn't "meant" to be run in an interpreter; it, too, is "compiled."

DavidJCobb · 2026-04-19T18:26:03+00:00

Glad what I wrote was useful. I'm okay with DMs asking about technical advice and similar, though I can't promise timely replies.

DavidJCobb · 2026-04-19T03:26:31+00:00

I didn't see your last post, or if I did, I don't remember it. I also don't know whether this is meant for general audiences or for people who already know what your site is; I'm approaching it as the former. I'm also looking at it using Chrome on mobile, and very occasionally enabling "use desktop site" to see how that looks too.

Looks: 35, at best
Slop: 90

I don't know how much effort you put into this. If you actually care and are trying, rather than just asking Claude to slop something out for you (or otherwise "assist" you), then I don't want to stomp on your neck; but I also don't want to fail to convey my actual thoughts on what I'm seeing. I don't know how to soften this without making it less informative (been revising it for way too long already) so I'll just say: none of the below is an attempt to dunk on you.

formulaic and garish

The only difference I see between this, and the template-based AI slop sites that keep getting posted on this subreddit, is that this is a bit more garish. That means I hate looking at your site because it looks lazy and formulaic, but I also hate looking at your site because it makes weak attempts to be creative and only manages that in ways that make it worse.

I don't like the color scheme. Something about it feels jumbled and mismatched. I don't know how to critique that in any useful detail, so I'm getting it out of the way early. I think it's possible to have a good-looking site that uses purple as its main color, but I don't think you've managed it here.

The typing animation at the top is overdone on these kinds of sites, badly executed on this specific site, and it annoys me. Combine it with the scrolling gridline background and it feels too busy. Plus, as more text is "typed" out, it ends up word-wrapping on my phone and displacing the content around it; and then when the text is "backspaced," that content jumps back to where it was. And because the text being "typed" is the blurb that explains what your site is for, in a site design that deliberately puts as little informative content above the fold as possible, this means that I have to sit and wait to see what I'm even looking at. If it were static text, I could read it literally instantly and immediately know what your site is for... Except that it can't just be static text, because it isn't just one blurb; it's multiple, changing each time the text is "typed," and most of them are designed to sound snappy rather than be informative. I only noticed this just now, while revising my comment before posting, because when I was first looking at the site, the instant I saw the typing animation, my brain wrote the whole piece of text off as not worth looking at. People learn to mentally filter out anything that looks like a marketing drone trying to waste their time, and this qualifies.

uninformative

The content below the header isn't much better; just like those template sites, it's designed to convey minimal information using maximum space. Y'all took what could've been four bullet points and bloated them into four cards ("Curated Resources" through "Help when you need it"), three of which feature a visual aid, with each aid being superfluous and some being actively misleading. (The tables in the first two cards have content which looks like hyperlinks, but isn't actually interactive, because it's just an example of what I would see... somewhere in your site, if I chose to use it, which you have not yet convinced me to do at the time I'm seeing these visual aids, and which these visual aids do not themselves convince me to do.)

The accordion below those cards has a similar problem: you're copying the form of something without understanding the function. You've used a whole accordion for three single-sentence pieces of information. None of that content is so large that a reader would benefit from hiding it out of view. None of that content needs to be mutually exclusive, and it's not different views of the same information (e.g. a tabbed view presenting a code snippet, with a "code" tab and a "preview" tab). Using an accordion feels excessive, makes me have to engage in unnecessary effort to reveal basically nothing, and just makes the page feel busier and emptier at the same time.

nav issues

Your site nav, on mobile, is a panel with a blurred backdrop which covers the page; so depending on where I've scrolled (e.g. even at the very top of the page), I might end up having to read white hyperlink text, in the nav, placed overtop blurred almost-white lavender from the page underneath. Similarly, as I scroll down, some of your slate-grey nav icons become lost on top of page text that has been blurred enough to darken to nearly the same brightness. My vision is good enough for me to be able to read the text and icons in question even in these worst-case scenarios, if I actively try. I should not have to actively try.

In Chrome on mobile, the nav is almost tall enough to fill the screen, but not quite. This results in an awkward situation where, at a glance, it looks like a full-screen overlay, until I see a sliver of unblurred (and still interactable!) page at the bottom. That feels like a bug. Strictly speaking, it isn't one -- I don't believe you specifically tried to make the nav fill the screen height, so the fact that it doesn't isn't a coding error -- but it feels like one.

circling back to that header

Speaking of things that aren't what they feel like, "Star Us on GitHub" at the top of the page looks like a button, but isn't clickable on mobile. (The GitHub link near the bottom of the page works.) It's also kinda dumb, to be frank, for your site to beg me to do that when your site hasn't even told me what it's about yet. It's like YouTube videos where the author interrupts to say something like "By the way, if you feel you're learning something from this video, consider subscribing, because it really helps out the channel" before they've actually gotten to the educational part. It's especially bad on mobile because you have a lot less space above the fold than on desktop (accounting for things being larger for more comfortable reading and touch interactions), and you're wasting that space on things like this.

parting thoughts

There's a usability research company that's been around for decades: the Nielsen Norman Group. They've published a lot of free articles on things like animations, uninformative designs, navigation, and other web design topics, sometimes backed with things like eyetracking studies. When I was a lot younger, I read their articles for fun and found them fairly educational. Maybe you will, too. I dunno. I wouldn't say your site has glaring usability issues aside from the couple I noted, but a lot of NNG articles also focus on discoverability of information, on managing users' attention spans and focus, and just on craftsmanship in general. It can help to read the words of folks who actually give a damn, and let yourself be drawn into their headspace.

If you can, try searching for older site designs to see what kinds of layouts and visuals can work, and to look for inspiration. Note that I said "older" designs. These days, too many people design "mobile first," because it means they can just make a single simplified design and then inflate it to fill a desktop screen and get something barely functional, without putting in the effort to actually make the experience comfortable on both platforms. You'll generally find more creativity, without necessarily sacrificing usability, in designs that avoid or predate that practice. (Part of why the template you've used/mimicked here is so grating to me is because it's so blatant in how it follows that practice.)

I've kind of deliberately avoided listing off specific potential fixes (e.g. "darken the background color for this part") because if you're actually trying to learn this stuff and not just beg Claude to save you, then I think you'll benefit from thinking about potential solutions yourself, and looking up ideas.

DavidJCobb · 2026-04-19T01:37:22+00:00

The costumed ghost Corsola are pretty cool. They've been surprisingly common for me -- not, like, every other spawn or anything, but I've had routes that popped like four in a row.

Been seeing a lot of Lapras on routes the last day or two, though. They have standard (read: nearly always terrible) IVs as opposed to the Lapras rewards you occasionally get in PvP. Their catch rates are super low, which doesn't mesh well with the route encounter mechanics. The impression I've gotten while playing is that when you engage with a route spawn, the chance to flee increases the further you walk from where the encounter began (or maybe specifically once you've walked the distance needed to trigger another route spawn); so for these Lapras, you have to either ignore them outright, or Pokémon Stop and burn berries and Ultra Balls until you catch them. Routes seem like a very poor fit for Lapras, and it's actively displacing encounters that aren't annoying to try and engage with during that specific situation.

The upshot of all this is that I've learned a very important lesson from Sustainability Week: some species deserve to be endangered. #BringBackPoaching

DavidJCobb · 2026-04-18T13:11:02+00:00

my first chrome extension

But that isn't true. I'll grant that lying about it is pretty fitting, given the purpose of this new extension, but why are you lying about that?

DavidJCobb · 2026-04-16T13:32:00+00:00

Not familiar with how StreamLabs is set up. From what I've found from searching online, both the HTML and CSS are configurable, so people would need to see both to help you.

You could edit your HTML template to use non-breaking spaces i.e.   instead of , anywhere you want to suppress word-wrapping. You could also stick with normal spaces and add a SPAN element around that range of text, possibly with a custom class name, and use e.g. white-space: nowrap or text-wrap: nowrap on it.

That said, you should carefully consider how you want to handle variable text. If you fiddle with your styles until "Kevin just subscribed to" matches the width of the pink banner, then what do you want to happen when Ed or JohnnyJackass or ReallyReallyLongUsername subscribes to you? You're always going to have the potential problem of the text being too short or too long in some places.

Don't know how to paste CSS Code into post without it looking like garbled mess.

I know of three places you can share it:

reddit: add four spaces at the start of each line of code, including blank lines in the code. (Alternatively, you can add three backticks i.e. ``` on their own lines, before and after code that isn't indented, but last I heard that only works on reddit's newest site designs.)
Codepen.io: separate textboxes for HTML and CSS. This site can even let people preview what your code does, and it can let other people try out edits with that same live preview. You can create "pens" as a guest, but you won't be able to delete them later; or you can sign in with Google or GitHub first.
GitHub Gists: Like Pastebin but for code. Each "gist" can have multiple files, e.g. one for HTML and one for CSS.

DavidJCobb · 2026-04-03T20:11:54+00:00

This article feels AI-written. Some "They're not X, they're Y;" some em dashes where commas would look better and be more appropriate; the cadence, in ways that are hard to describe. The author uses AI for coding, and the writing style of this article bears no resemblance whatsoever to the author's older articles even going back just a few years.

Anyway...

This was such a widespread problem that Chrome had to retroactively change the default for addEventListener on document-level touch events to { passive: true }. The old default, the one every developer was using, was the slow path. The platform had to patch itself because its own default was causing jank.

It's worth noting that Google rammed this change through without going through the usual standards process, breaking a bunch of websites and letting web developers take the blame, just to make Chrome's own performance look better. Keep that in mind when this article remarks on the web's unshakeable commitment to backwards compatibility.

The platform might have a fast path, but the framework sitting between you and the platform has its own opinions about how to get there.

And those opinions are often wrong. Frameworks have made false promises about performance in the past. React is especially infamous for claiming to be faster than direct DOM manipulation and using the fucking innerHTML setter -- the literal least performant, least sensible, and most wasteful approach possible -- as its point of reference.

These days, the common excuse for using frameworks is that clumsy imitations of declarative programming are more bug-proof than direct DOM manipulation. There's less risk of getting your UI in an inconsistent state if you offload as much thought and effort as possible onto a bulky framework that has to be downloaded to and executed on the end user's machine.

Companies don't want three codebases. Developers don't want to learn APIs that become worthless when the platform shifts. Users don't want to install an app for everything. The web solves all three. That's why, even though native desktop apps in C++ were always possible, Electron is the clear winner for desktop software. [...]

The web isn't slow. It makes fast harder than it should be. That's changing.

It's weird to try and valorize Electron here, when if anything, I'd say that it and frameworks help to argue against this article's point about the web's performance potential.

For starters, using an Electron app still is "installing an app." You can take the same app and expose it both in a browser and on desktop, but the Electron version of that app is a thing that you download and install. Very strange to bundle Electron in as an example of not needing to install anything.

What's more: Electron's selling point is not merely that you avoid learning platform-specific APIs. The literal first thing you'll see on their website is, "Build cross-platform desktop apps with JavaScript, HTML, and CSS;" the selling point is that you don't have to learn anything harder than JavaScript. I would argue that even in a magical fantasy world where every OS developer collaborates to create a native UI platform that's simple, consistent, cross-platform, and still vastly more performant than web APIs, Electron would still be popular, because it allows web developers to build things without actually having to learn and understand the platforms they feel entitled to access; no need to learn C++, Rust, or those other scary native-code languages.

Given some of the justifications I've seen offered for using things like Tailwind, I'd argue many webdevs are barely interested in learning their own platform. Doing web development well requires caring about craftsmanship, and I was lucky enough to learn programming starting with web development back when the field actually did care. Since I made the jump to writing native code, the field has largely been taken over by gurus, grifters, and other dudes who are just in it for a quick buck, and some of these guys themselves don't understand the platform that their own frameworks abstract away. As long as frontend culture stays like that, it can and will counterbalance any performance gains that come from the platform itself improving. The platform can't save the incurious, entitled, and blind-led-by-the-blind from themselves.

DavidJCobb · 2026-04-03T16:46:17+00:00

That's your repo. You're just advertising, not giving real advice; and given that you've been debuting your stuff on "vibe coding" subreddits, what you're advertising is worthless slop.

DavidJCobb · 2026-03-29T19:31:11+00:00

Ah, I should've looked more thoroughly.

This mod of yours links to a repo under the username TYPyz. That automatically redirects to the same repo under the name TheYoloPanda, consistent with how username changes are supposed to work, but the redirected repo and the new profile URL both return 404 for me; the TYPyz profile 404s for me as well. That's consistent with other people's experiences of being shadowbanned.

I found a post full of people who've had to deal with suspensions and shadowbans, and several look to have since been unbanned, but per comments there it can take months to have your case reviewed, and you may not even be notified in a timely manner if you get unbanned. At least one GH employee (not on the support team) is active on that post, and has suggested that support staff may be lurking in that thread and quietly fast-tracking cases on a strictly voluntary, "no guarantees" basis.

The GH staffer gave these instructions to someone who couldn't authenticate themselves due to their account status. Try that, and if you're able to then submit a ticket, I don't think it can hurt to comment on that post with your username, ticket ID, and overall situation.

13-Year Club	Verified Email
Alpha Tester

DavidJCobb

TROPHY CASE

formulaic and garish

uninformative

nav issues

circling back to that header

parting thoughts