I'm so big on the no build step thing, but I really think the first part is the killer here. the fact that the paradigm is language agnostic (other than HTML) is a really big part of its success

Using the Javascript API to swap out a subset of a response from a Shopify section, it's targeting the right element but it's not grabbing the right subset source from the response. Here's what I got

javascript
      htmx.ajax('GET', `/products/${productHandle}?variant=${variantId}§ion_id=${sectionId}`, {
        source: '[x-prodify-swap-target]',
        target: '[x-prodify-swap-target]',
        swap: 'outerHTML',
      })

This is the fetch call I was making that i'm trying to replace

javascript
     fetch(`${url}?variant=${this.selectedVariant}§ion_id=${sectionId}`)
          .then((response) => response.text())
          .then((responseText) => {
            const html = new DOMParser().parseFromString(responseText, 'text/html')
            const destination = document.querySelector('.pdp-main')
            const source = html.querySelector('.pdp-main')

            destination.innerHTML = source.innerHTML

            const params = new Proxy(new URLSearchParams(window.location.search), {
              get: (searchParams, prop) => searchParams.get(prop),
            })

            let optionId = params.lastSelectedOption

            document.getElementById(optionId).focus()
          })

hi thanks a lot

helped me a lot

mainly to realized that the way i did my api wasnt really convenient

py
model = {
    "data": [...],
    "pagination": {
        "next": "link to next page",
        "prev": "link to previous page"
    },
    "current_page": "current items on page",
    "total": "total items on page"
}

just added a few more elements to the api to make the job easier on htmx side. doing all that through htmx would be a pain

oh okay so maybe this isn't possible with the ajax api https://github.com/bigskysoftware/htmx/issues/701 . Wondering what

source

is for then...

I'm really into the idea behind wasp (DSL for web services) though I'm a little skeptical of their marketing

It screams YC dev tool that's going to embrace-extend-extinguish itself in 5 years if enough people start using it cough docker

YC?

oh ok i am reading the link. Well in a twisted way

it kinda makes sende

sense

you do end up with an anemic webpage if you start from scratch using react and taking over the whole page

and a lot of libs, code and confusion come from trying to patch the issues

of course if you just use the platform and send proper HTML you avoid these issues but, in a world that has strayed away from HTML and embraced JS their twisted answer is: YOU NEED A FRAMEWORK

the wasp thing seems interesting

a good project could be a wasp like DSL but for htmx

Those frameworks evolve so rapidly. This is the most terrifying to me. They automatically create work for you on a regular basis: 1. You must learn what's new. Try it, integrate into the project. Get some issues - that requires you to integrate more frameworks to solve those 2. It is changing every 6 months. So you must re-learn and change the project All of that just to be able to build basic web apps. Buttons and stuff. Buttons are not changing. The outside regular people probably don't understand why there is so much going on in the web tech. And rightfully so.

Small businesses front-end be like: - old jquery mess + new framework related mess - css displaced everywhere - dependency mess: finger cross whenever you have to update a deps - on new feature: talk with the backend guy hoping to reach an agreement about the API. Usually the backend guy does not want to work to serve the front-end needs and so business logic gets spammed across the codebase without a meaningful way

The big business front-end is the same, except backend guy doesn’t have time to talk to front end guys because he/she is busy with Microservices bs. Also: front end guys look at you confused whenever you mention to them that it is possibly to return HTML from server.

I think the heart of the problem lays somewhere else.

It’s not about big/small, I may even suspect that big teams have more problems in trying to adopt classical mvc architecture with ssr because of over-thinking big brain heads of engineering.

Everyone who is employed in big org, if you want to adopt htmx, try with internal tools. From my experience big brain devs aren’t interested with internal tooling so much as they are with the main products, so this is a good field for your experiments.

Also if you prove to them that all that hypermedia mambo jambo actually makes sense, you may have an argument when choosing tech for your new project in the org.

In my country we use to say that “pressure makes sense”.

excellent advice

We are trying to adopt htmx at work. In my opinion this decision should be accomodated with a discussion concerning organizational aspects about "who does what". On the one hand they "like" htmx, on the other hand it seems to me that they are not willing to put any effort in understanding the problem hypermedia could solve. Because of that there still is a front end guy who has to talk with a backend guy for no meaningufl reason. I would like to write my RPC to the database by myself rather than having to deal with a "middleman" returning me some data api I can consume which nevertheless I do not control. What is crazy is that this decision is not about seniority or else, it's just because work is organized in this way which was ok with old architecture