Not for whales so YMMV.

It's not consistent across species because different species have different mechanisms for averting tumor growth. But within species (certainly among humans, and I'm pretty sure also among others), more cells means more opportunities for something to go wrong and so more cancer.

Counterpoint: elephants.

Do larger elephants have less cancer then smaller elephants? If not, that's not a counterpoint.

Isn't that because the ocean water blocks radiation?

as one cause of cancer. there are many others.

That's the problem with standardized and sanitization of food. By rejecting irregularities, smell, dirt, we create souless food.

It's very hard to find a good camembert now. Easier with goat cheese and other products from the mountain.

But yesterday we bought one in Esteron that finally tasted how it's supposed to taste.

So it still exists, but as with anything popular, it dies from tragedy of the common.

I'm sure you're right about the declining quality of Camembert, but I can't help but be reminded of this comic:

http://smbc-comics.com/comic/craproot

what do you mean by "tragedy of the common"? is it a play on words regarding the economical "tragedy of the commons"?

We know what he means. As popularity increases quality drops as manufacturers scale up to meet demand. As demand increase the economic incentives change and there's pressure to cut costs and thus quality suffers.

The problem's been around since time immemorial.

No it's not.

There are plenty of small cheese makers with diverse biomes and we buy from them every day.

They all have their own batch, many are unique passed from generations or affected by the animals they raise.

Nobody expect supermarket cheese to be sustainable anymore than their standardized vegetable.

do you have any idea on how the biodiversity of cheese is catalogued? i'd love to read more about that!

For me it's a plus. I wish it would be done more.

HTMX is neutral to composability, since it's limited to connecting and orchestrating parts of a system that may or may not chose to provide components.

Does your backend has components? Does your scripting toolkit has components?

HTMX doesn't care either way, and will use whatever you give it.

You can pick reusable django forms, alpine js, some manually created boundaries, a jquery module... You can even drop react on a single page because there is a widget you like and it's not loaded often.

People may be tempted to talk about HTMX using irrelevant points of references.

It's not providing an SPA with a component architecture, that's the point.

The readers that are very used to modern JS stacks and never had to deal with the web before 2010 may want to read:

https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1

This will give a better idea of how to think in HTMX, which is just a new trick for an old dog.

It's better to use this tool for what it is, with its limits and strengths rather than trying to make it into something it's not.

The reason HTMX can't do many things react is good at is because it's by nature the opposite of react.

HTMX users just use existing JS components.

It's not an XOR proposition.

But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it.

Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents.

It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway.

I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.

No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool.

Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm.

It provides a more simple, basic service.

You may be tempted provide a django template + view + htmx reusable component.

Or a rail enpoint + htmx reusable component.

But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.

That's OK - but then I'd say I'm not interested in it based on its project scope.

I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.

And yet, and yet:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

I've read this and think it makes a ton of sense. I still think it's lacking an ecosystem strategy that would propel it further.

I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework.

It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition.

If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.

That's how engineering is supposed to work: you get to decide what to use based on your problems and the nature of the solutions.

Beyond the memes, this one Montana guy is very reasonable.

Schools are only partially made to teach. They are also serving the interests of the people running them, and of course, they are filters.

What's more, many teachers actually don't produce anything with what they teach, and have a curiculum forced on them by people making it up on theorical basis.

The result is that half of the professional training I give have to cover those holes. Having to teach debuggers to pro devs is weird but a reality.

In fact, shameless plug, but this is why I have a articles dedicated to pdb, venv and pip on http://bitecode.dev.

Because the demand is very high.

They were also made to train a workforce for industrial production. Some part of the school curiculum is detrimental for todays tasks.

You have a product here.

Yeah - I was looking around this week and think there is a “gap” for a good simple proxy - speed bump is nice but I am thinking just let my application do it’s thing, then let me replay certain traffic, that JSON needs to

I think a programmable proxy with simple hooks is what I want

From a UX point of view, excluding calls, it's a superb achivements.

They fixed calls like days ago, were awful. But whatsapp is still better for calls imho. With the pace of innovation, even being very late in the game, but very focused, Telegram has very chance to outpace most apps in 2-5 years.