Tailwind Plus is great - I love the lifetime access, but I always wondered how sustainable that model was. Even without AI, how many of those memberships could they sell?

I thought the same, and yet on the other hand, how could they have done it differently? People don't want to pay a subscription just to write a DSL of CSS. Perhaps they could've done it per project like some companies, but I don't think it'd be as popular as their lifetime model. Ironic.

We can go back to how software was sold decades ago: you pay for version 1.0, and get bugfixes for the 1.x series. Then 2.0 is released, and if you want it, you pay again for the 2.x series. And so on.

I agree on not wanting a subscription for something like this. But I also acknowledge that if people are still doing work on something post-sale (beyond bugfixes for a pre-defined support period), I should maybe expect to have to pay for that continuing work.

MUI sells paid components paid monthly. Definitely doable for the paid product.

I'm not super familiar with tailwind plus, but I am familiar with MUI.

MUIs paid offerings are open-core, you pay for support and a couple of extra features.

Tailwind plus looks like paying for basic components (checkboxes, sidebars, buttons) and it doesn't even offer anything like DataGrid (free with mui).

> and it doesn't even offer anything like

Shows Tailwind was just too little too late.

I've been using Claude Code in their iOS app (on a Pro account). I just point it at my GitHub repo, and tell it to work on one of the issues I created. It required very little setup beyond what I did for Claude Code CLI.

i've seen that work well on existing codebases, but bootstrapping a codebase that way is like pulling teeth in my past experiences.

so it really sort of falls back to what you're doing with the llm. code maintenance isn't novel development, which isn't polishing.

> Any consolidation like this seems like a negative for consumers.

I tend to see much more discussion about how the main downside is for sellers of content. Why is this bad for consumers?

Watterson serves as one of the symbols of an era when selling out was considered a great sin. It makes me laugh how thoroughly that idea - that selling out is bad - has been defeated.

That being said, I'm sure he would've done it the same way today.

The Simpsons went more meta: https://www.youtube.com/watch?v=2qh1JlNaOxo

> back when “Carlhuda” was a super-prolific author of Ruby libraries, including most of the work to modularize Rails for version 3

Wow, hadn't thought about that in a while. For a laugh, go back and take a look at some of the architectural choices they were replacing.

I haven't used ruby in more than a decade, but I remember there was always some controversy around the corner. Up next: Zed Shaw comes out from his cave, joins forces with the mummy of _why to combat DHH's anti-woke agenda.

All The Simpsons episodes are on my YouTube TV DVR, along with a lot of the shows my kids like (although really what they care about is a couple channels on YouTube proper), so even before this I was wondering why I was paying for Disney+ at all.

A little thing that doesn't help the situation is when legitimate emails link you to domains that aren't obviously controlled by the company.

For example, yesterday at work I got an onboarding email from Lattice (lattice.com) with a link to latticehq.com, which triggered my phishing instincts before I remembered that was their old domain.

It's kind of an expression of the success of an abstraction. If an abstraction is good (hx-get="/clicked"), it feels local. If an abstraction is bad (id="d1"), it's spooky action at a distance.

I've never used htmx, can you ctrl+click "/clicked" and go to definition? If not, it's just as spooky.

HTMX can easily get spooky. One pattern to avoid that is to not use separate routes for HTMX endpoints. Instead, use a special GET param or header to tell the server that this request is for a specific HTML fragment.

/page1, /page1/click1 (bad)

/page1, /page1?htmx=click1 (good)

Then have a common server pattern for how you inspect the request to determine which fragment (or whole page) to respond with.

With this, navigating HTMX code is much nicer because you only have to identify one entry point instead of hopping through the codebase to identify the N different URLs and view functions that support the page.

For sure, for example, htmx has attribute inheritance, which moves behavior away from where it has effects, and allows you to listen for events on other elements, same problem.

The development principle still stands, however, and, like all dev principals, has trade offs associated with it.

> can you ctrl+click "/clicked" and go to definition?

Actually, you can and you should–this is a best practice for building maintainable apps. You shouldn't be hard-coding 'magic string' API paths throughout your views. You should factor them out into variables and then use those same variables for both routes and views.

Many good routing systems have this functionality.

Have you ever used HTML?

Can you ctrl-click on an href attribute and go to the definition?

can you do that on any button that makes a fetch/ajax call? if the target for /clicked is a full standalone page, why even have a button and not a link?

So a site just needs to generate enough content until its under that threshold?

> So a site just needs to generate enough content until its under that threshold?

No. That alone is highly unlikely to prevent performative lawsuits from state attorney generals. Especially (but not limited to) AGs who are intent on satisfying their culture war kink.