That is the answer!

nope, that's good to start with, firing up IE now

OK, interesting

so, the demos never worked in IE11, because the demo infrastructure uses string templates which is not IE11 compatible

😑

however, the library itself should work against IE11 still

@User ☝️

Hello! I try to check is htmx is good choice for my projects. Task: Send DELETE request to /collection/123 on delete button click. On success (returned server status code == 200 or 204): redirect to (some well-known url, stored on client-side in js const). On error: reload "messages" div (send get request to /messages and replace block html content). Is it possible to do with htmx without hyperscript (with js/ts) and without customising server headers or status codes (for example, I do not own server-side API and can't change it, but it's OpenAPI/Swagger compatible, so I would like to send request and do redirect on success or reload messages div on error)?..

Also, another question, do you have pattern implementation for client-side router for SPA? (something like vue-router)

this sounds like heavy client side logic, so htmx might not be the best option

I can use Vue.js from start but I feel it's too big for me for MVP. And I do not want to create RESTful (OpenAPI/Swagger) or GraphQL APIs for all of data. I would like to have part of them as OpenAPI and part of them as html chunks, generated by Django. May be I should setup simple Vue.js project with vue-router and use htmx inside Vue.js components to load html chunks from Django (I like how htmx extends html tags)... Is htmx compatible with Vue.js?

You say the server uses OpenAPI, then maybe vanilla js is enough.

Why do you need client side routing? HTMX can usually achieve the same thing.

vue probably won't like having the dom taken out from under its feet

and making htmx and vue play together might lead to ref soup

Back to the IE11 topic. Is there a reason to use this outdated browser? Even if you are poor and run old hardware... I guess you are able to install a modern browser. For me empathy with poor people would be a reason to support , but laziness not. So why do these 1.5% use IE11?

yep, seems like trying to fit a square peg into a round hole to me: you probably won't be happy with the results. If you really want to stay client side with everything, there is a light-weight version of view that people are excited about: https://twitter.com/youyuxi/status/1410763549228609537 I can't offer any endorsement since I haven't used it, but it might be the easiest way to achieve what you want

i would guess historical momentum: people working on old hardware that's good enough and not updating

I would like to support IE through the end of the year and then mark a particular version of htmx the last IE-compatible version

I have encountered a fair few sites that only function on IE11 because they were never updated. For example: Anything that uses ActiveX. Still a lot of legacy code out there running on really outdated technology. In our case I suspect the 1.5% users still using IE11 are probably browsing on a work computer that should have been replaced 10+ years ago.

At my current job, I do only backend stuff. But the frontend team was super happy when the management allowed to drop IE11 support. ... I just want people to be happy 🙂

Believe me I wish I never had to open IE11 ever again. It's a massive hindrance 😞

I do fear Safari will take its place though.

I think I figured out the issue and it's a really obnoxious one 😑 Using Algolia instantsearch.js and they recommend a polyfill for IE11 support. That breaks swaps in htmx it seems.

😑

It definitely did not take me 2 hours to figure this out 🙂

Welp after removing the polyfill Algolia said to use, instantsearch still works for my use case and htmx swaps are back to normal in IE11. Problem solved I guess. Thanks for looking into it @mysterious-toddler-20573 and sorry for wasting your time.

welcome to programming enjoy your stay

question for the group: I am considering implementing a timeout for htmx requests. I could add this to the existing

hx-trigger

syntax:

html
  <button hx-trigger="click timeout:3s" ...>

this would be the easiest place to add it, but feels a bit wrong since it doesn't have much to do with the trigger i could also add it as a modifier to the

hx-get

etc:

html
  <button hx-get="/foo timeout:3s" ...>

this would be new syntax and some work, not sure I like how it reads. Another option is to add it as an attribute:

html
  <button hx-timeout="3s" ...>

or, possibly, as a general request config attribute: Another option is to add it as an attribute:

html
  <button hx-request="timeout:3s, otherStuff..." ...>

Any opinions?

I am leaning

hx-request

and surfacing a few more options that way:

html
  <button hx-request="timeout:3s, expect:text/html, credentials:true" ...>