yawaramin

> the devs and other users keep telling me I shouldn't want that as a feature and that it "doesn't make sense"

I mean if the devs and the users are all telling you it doesn't make sense, maybe it really doesn't make sense. Not everything is supposed to be able to do everything. Some things are targeted and focused on specific use cases.

But surely even in a SPA you have to eventually send a request and get a response? Like you're not going to suggest that eg in an online store webapp the user would click 'add to cart' and you wouldn't send a request to add the item to the cart and wait for and render the response?

Hypermedia libraries like htmx etc. are just doing these interactions, the ones that need a server request-response cycle. The difference is they get the response as already-rendered HTML, so they don't need to do anything further, just swap it in to the existing page. It's super simple and very efficient. And usually results in fewer AJAX calls which also are much more minimal and don't include any redundant data.

> not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis

I don't understand...Rails does not replace a HA PostgreSQL cluster or Redis, they are orthogonal. Why would you not have to think about them?

Yeah but the problem is that people don't just use a single webapp all the time. We all browse and go to many different websites, which all have payloads that they want us to download and run. So in practice it ends up that we're re-downloading bundles constantly, many of them which have the exact same libraries, but because they're bundled and minified, they're not cacheable so we have to fetch them over and over again.

Don't believe me? Check this out: https://tonsky.me/blog/js-bloat/

Actually... https://github.com/microsoft/TypeScript/issues/52924

He makes it sound like he did something special, but this is just something that htmx offers out of the box. In fact if he had used something like:

    <a href="/?page=2" hx-target="#dashboard-content" hx-boost="true">
      Next Page
    </a>

Then he would have gotten the functionality out of the box without even using hx-push-url explicitly. And he would have gotten graceful degradation with a link that worked without JS and Ctrl/Cmd-click to open in a background tab.

Also the article seems to be full of errors. Eg

> In HTMX, if the server returns a 500 error, the browser might swap the entire stack trace or the generic error page into the middle of a table by default. This is a poor user experience.

This is simply incorrect. By default htmx does not swap 4xx/5xx responses. Instead it triggers an error event in the DOM. Developers can choose to handle that event or they can choose to override the default behaviour and do a swap.

Someone reporting an RFC violation doesn't automatically mean there is actually an RFC violation. That's why they are asking for a minimal repro, not a dump of the reporter's stream of consciousness. If your teammate at work. came to you and dumped something like this on your desk, how would you react?

All of this is introducing complexity that simply goes away if we just avoid Shadow DOM.

Yeah but most people don't need or want 'interoperable composition', they want sites with a consistent look-and-feel. Shadow DOM makes this much more difficult.

> This is honestly all you need.

No, you need less than that! :-)

    ┍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┑
    │                     how-to-make-a-damn-website.html                      │
    ├──────────────────────────────────────────────────────────────────────────┤
    │ <title>How to Make a Damn Website</title>                                │
    │ <h1>How to Make a Damn Website</h1>                                      │
    │                                                                          │
    │                                                                          │
    │ <p>A lot of people want to make a website but don’t know where to start  │
    │ or they get stuck.</p>                                                   │
    ┕━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┙

HTML is very forgiving! You can start really simple and work your way up to more complexity when you need it.

No, the original base is in the commit history. It's just not relevant any more after rebase. It's like your individual keystrokes before a commit are not relevant any more after a commit. They're not lost provenance.

> when we ask a person for a favourite tool

I think you're focusing too much on the word 'favourite' and not enough on the fact that they didn't actually ask for a favourite tool. They asked for a favourite how-to for using the suggested options, a Dev Container or a VM. I think before asking this question, if a person is (demonstrably in this case) into LLMs, it should be reasonable for them to ask an LLM first. The options are already given. It's not difficult to form a prompt that can make a reasonable LLM give a reasonable answer.

There aren't that many ways to run a Dev Container or VM. Everyone is not special and different, just follow the recommended and common security best practices.

> reviewers will love you, peers will hate 8 small PRs that are chained together

My peers are my reviewers...

Merging a PR with rebase doesn't lose provenance. You can just keep all the commits in the PR branch. But even if you squash the branch into a single commit and merge (which these tools automate and many people do), it still doesn't lose provenance. The provenance is the PR itself. The PR is connected to a work item in the ticketing system. The git history preserves all the relevant info.

From what I can tell the vast majority of developers don't use git bisect and never will.

I checked with Gemini 3 Fast and it provided instructions on how to set up a Dev Container or VM. It recommended a Dev Container and gave step-by-step instructions. It also mentioned VMs like VirtualBox and VMWare and recommended best practices.

This is exactly what I would have expected from an expert. Is this not what you are getting?

My broader question is: if someone is asking for instructions for setting up a local agent system, wouldn't it be fair to assume that they should try using an LLM to get instructions? Can't we assume that they are already bought in to the viewpoint that LLMs are useful?

See also https://x.com/astuyve/status/2010772489605951912

Hi. You are clearly an LLM user. Have you considered asking an LLM to explain how to do this? If not, why not?

> Multiple sources [1][2].

Where does [1] say USD 1 trillion?

[2] says:

> The combination has had a toll on Japanese automotive (and other) exports. Barring Fukushima’s impacts, one would assume a return to pre-2008 fiscal meltdown exports by now. But basically they’re static. That’s in the range of $200 billion in lost exports just for the automotive industry. > > It’s likely fair to attribute $20 to $50 billion of that to irrational fear of radiation.

Like, are you serious? This is the most bizarro accounting I've ever seen.

> ...that’s about $100 billion in extra fuel costs.

And now it's counting as part of the cost of Fukushima the fossil fuels needed to replace it. Even more wacky accounting.

> another $22 billion for unexpected health costs due to burning extra fossil fuels.

It continues to get even more wacky, if that was possible, by attributing this cost to the Fukushima disaster. These are costs that would be avoided with a strong nuclear electricity generation program! These are arguments in favour of nuclear! It's not cost-effective for Japan to cover their land mass and offshore areas with solar and wind arrays! They have regular earthquakes and typhoons which would knock these vast arrays offline and take massive amounts of time and money to get back online!

You said: 'Fukushima will likely take a century to clean up and cost upwards of $1 trillion if not more.' The sources you provide don't provide the numbers or, if they do, they include bogus numbers that actually make the case for nuclear.

> for 1 nuclear plant

Yes, because others were mostly not affected by the Fukushima disaster despite being in the impact area. Why? Because they took safety precautions. Onagawa was closer to the epicentre, but they built on a high embankment and did not flood and lose power.

Anti-nuclear people conveniently ignore, because it suits their argument, that Japan is restarting their nuclear energy program. They finally understood that there's no other viable option for energy security, price, and achieving decarbonization goals.

- Spent fuel is a solved problem, we just store it securely

- Who can be relied upon: who do you rely upon to run your drinking water?

- Failure modes of accidents: have been extensively studied and essentially designed out

- Multiple catastrophic failures: sounds bad until you realize that you can name only two:

1. Chernobyl: old flawed reactor design, basically impossible today, a few unfortunate deaths among first responders in the cleanup, that's it

2. Fukushima: no radiation deaths. You would get a higher dose of radiation flying to Japan to visit Fukushima than from drinking the irradiated leaked water there.

> upwards of $1 trillion if not more.

Where are you getting this number? According to https://cnic.jp/english/?p=6193 it was estimated at JPY 21.5 trillion (roughly USD 150 to 190 billion).

Why does it ask for the student's gender?

> many people who've talked to me about Htmx are confused about what Htmx is and believe that it works without javascript

The htmx landing page's first paragraph says 'htmx gives you access to AJAX...'

AJAX stands for 'Asynchronous JavaScript And XML'.

Close below that, it has a 'quick start' section that shows how to install it, using a `<script>` tag.

For people who think it works without JavaScript, I am afraid they are facing deeper issues than htmx's tagline.

That's why my JS doesn't create the GUI, it just attaches event handlers to the GUI rendered on the server. Check the link I posted above...

> How does "htmx sends a request header HX-Request: true with every request." happen without javascript?

It doesn't. If JavaScript is disabled, this header is not sent.

> you need a backend server that understands whatever this header is for the graceful fallback

Yes, as I mentioned in my blog post linked earlier: 'the backend server can use a fairly simple heuristic to figure out that it should respond with a fragment:...The request has a header HX-Request...The request does not have a header HX-History-Restore-Request...If these two conditions are fulfilled, it can respond with a fragment. Otherwise, it can respond with a full page ie <!DOCTYPE html>... and so on.'

> it wouldn't work with just nginx...

It would in a limited sense if you design the pages in a certain way and use the `hx-select` attribute: https://htmx.org/attributes/hx-select/

But...htmx is not really meant to work with just Nginx or other static web servers, it is meant to work with a BFF (backend-for-frontend) that specifically knows how to serve and handle the app in question.

From the criteria you have mentioned so far:

- Works without JavaScript

- Works with a static web server like Nginx

I can only conclude that you are talking about serving static sites with no dynamic interactivity. That's not really what htmx is about. Htmx is more like a simplified way to do SPA-like things.

That's incorrect. Htmx actually works really well with progressive enhancement, thanks to hx-boost. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...

If you stick to GET and POST requests, you can ensure your app works almost exactly the same with or without JavaScript.

> an entire ecosystem

Ecosystems have their downsides too. Just a small example, no htmx users were impacted by the React Flight Protocol vulnerabilities. Many htmx users have no-build setups: no npm, no package.json, nothing. We don't have to worry about the security vulnerability treadmill and packages and tools arbitrarily breaking and no longer building after some time passes. We just drive the entire webapp from the backend, and it just works.

Htmx offers more flexibility than Alpine Ajax. Here's an example: htmx allows using relative selectors, which allow you to target elements relative to the triggering element in the DOM tree. This gives us a lot of power for swapping in pieces of UI without having to make up ids for lots of elements.

I have a blog post in the works for this feature, here's a small code sample I made to show the idea:

    <div class="card"> ╾──────────────╮
      <header class="card-header">    |
        <a                            |
          class="button is-link"      |
          title="Load links for #167" |
          role="button"               |
          aria-expanded="false"       |
          href="/app/notes/167/links" |
          hx-trigger="click once"     |
          hx-boost="true"             |
          hx-push-url="false"         │
          hx-target="closest .card" ╾─╯
    ╭───╼ hx-swap="beforeend show:none"
    |   ><b>±</b></a>
    |   <a
    |     class="card-header-title"
    |     href="/app/notes/167"
    |     hx-boost="true"
    |     hx-target="#note"
    |     hx-swap="outerHTML transition:true show:window:top"
    |   >#167 Velificatio</a>
    | </header>
    ╰╼
    </div>

I have a better idea: `ocaml script.ml` ;-)

Get started here: https://dev.to/yawaramin/practical-ocaml-314j