What are hard and easy things? I don't understand the bifurcation.

Some applications benefit from being in the style of a SPA, others do not. For the scenarios that do not benefit from a SPA (or other full JS framework) htmx is really nice to work with, I still use javascript along with htmx but I delineate its usefulness to projects that don't benefit from massive amounts of global state that the FE needs to know about. Over the years I have found that the majority of applications I have built in a commercial setting, global state was not all that useful.

My mental historical model kind of went like this. We got backbone.js and started to make these magical like interfaces for the web. We then started to build everything as a SPA. We optimized for state management and how to efficiently update the dom. Because SPA were uncrawlable we would manage a static site and the SPA, then we got frameworks that could handle requests to specific views within the applications. After playing around with htmx I started to think that perhaps all that management the FE app was doing was not really necessary for a lot of the applications I had built. I can couple html with discrete javascript applications where necessary. For me thats the sweet spot but again, htmx is not a one tool fits all. There are many apps out there that benefit from using vue/svelte/other frameworks.

I couldn't agree more.

People today write static blogs with TS/React/Next/whatever because that's what they know. It's not because it's the best tool for the job (or even close to that).

It has become standard to use React/Next/GraphQL for any new project, regardless if you're building a new Google Docs (which definitely benefits from JS) or yet another CRUD application that has lists, details and the occasional interactive page like a graph or something similar.

That's the crux of the issue: we seem to have lost the ability to think critically and choose what we require, in favor of copy pasting choices from everyone else and calling it a day.

Once you're heavily invested in all the JS-only technology, your incentive is to stay in that lane. To consider better alternatives is simply too costly for many.

That's why we turn everything in sight into JS. Someone I can't recall said once: everything that can will be rewritten in JS. We even have people building email templates with React now because all they know is JavaScript.

Jeff Atwood (cofounder of Stackoverflow) Law [0]

“Any application that can be written in JavaScript, will eventually be written in JavaScript.”

[0]: https://en.wikipedia.org/wiki/Jeff_Atwood#cite_note-5

I am writing a complicated website - the typical single page application and, so far, htmx is working wonders (and removing a lot of frontend work which I find duplicating data models already done on the server)

One problem I did face is trying to put together a large json to a POST request. I did experiment if I could do this all in the 'htmx way' of using input=hidden but was not working. With this, it was best to store this as a JS variable, or call a JS function to return json, which was all specified in htmx (in html)

Point is there are some exceptions that I have to do some javascript but the amount is much less when using other popular frameworks.

Overall, I am doing most work using htmx and odd exceptions with simple javascript functions to returns text or json.. or javascript to compliment my css.

What was in your json? I've taken forms pretty far with htmx. Getting to accept "the state lives in the html" takes a bit of mental wrangling, but I've found it to hold up well so far. (One nice htmx trick is the ability to include hidden inputs/forms/whatever from outside the current form if necessary.)

Hi smallerfish

update: formatted the json better

Thank you for expressing interest and, potentially, an approach to suggest ideas.

On my original attempt, I just couldn't get the POST request to work. I cannot remember the details but, due to time constraints, had to resort to something.

I will admit that this is an area I would like to revisit, but the current approach does work well... for now.

My json is larger than below, but provides examples of the inputs they represent on screen:-

  {
    "catA": {
      "capacity": 90,                            // value from slider control
      "memberType": 4,                           // value from single drop down
      "members": [1, 2, 10, 100],                // values from multi select drop down
  },
    "catB": {
      "dateRange": {                             // both individual text fields
        "from": "2024-01-03 10:00:00",
        "to": "2024-01-04 10:00:00"
      }
  }
}

I've found it most useful to have form types that are derivable from db entities, but which are designed for parsing (and rendering) forms.

What backend library do you use? Mine (javalin) gives me back forms as: `Map<String, List<String>>`, i.e. a map of form keys to list of values.

In your case, you have five keys that matter: capacity, memberType, members, from, to - so you could have a completely flat form object from which you derive your catA and catB entities easily enough.

I wrote a function which converts from the generic form structure to a more nested/typed structure, but I found that two levels of nesting becomes hard (maybe impossible) to reason about (consider lists with mismatched lengths, and how you'd handle them on nested objects); in any case, I'd be able to have:

    data class MyForm(val catA: CatA, val catB: CatB)

...where CatB is flattened:

    data class CatB(val from: OffsetDateTime, val to: OffsetDateTime)

...and then I'd be able to transform the form as:

    request.toFormObject<MyForm>()

I've found this to hold up well so far. (I plan to write a few blog posts about the whole stack I'm playing with, including this -- subscribe on http://smaller.fish if interested in seeing them when published. No spam.)

Appreciate your reply. I agree with your comment. I need to revist. Maybe I will be successful next time round.

:-)

from outside?

(I swear I've read the htmx docs but either I missed this part or I've forgotten it since)

hx-include

https://htmx.org/attributes/hx-include/