whoah when I ignore those I get

Error: 'default' is not exported by node_modules/htmx.org/dist/htmx.min.js

- is there an example somewhere of importing htmx with typescript I can crib?

This (https://github.com/leevigraham/typescript-htmx-types/blob/main/src/@types/htmx.org/index.d.ts) is the most complete types definition that Iv'e come across. I haven't used it yet (I worked around the issue by loading the script file in page and doing a 'declare var htmx: any') but methinks it should work

There is a definition file, but it is very limited. We’ve only just started making typescript definitions for htmx and hyperscript. If this is something you feel comfortable doing, your help would be greatly appreciated. If not, we are making steady progress toward getting this done. In the meantime, you might just make definitions for the parts you need to use.

That’s a great find. Perhaps we can ask Leevi to contribute his changes directly to the core library?

That would be great!

Will htmx have language service for linting?

I know Leevi personally, will ask him to PR it.

That would be fantastic. On a related note, my next PR has a ton on jsdoc comments that should really help with static analysis. Typescript is coming!

declare var htmx: any worked great for me

I would be happy to push up any TS stuff I do but I'm pr new to TS so no promises

Certain things are still pain points compared to an SPA framework, but for the most part it is a lot better

Also I've seen your PR feedback, will take a look this week and update tests/docs

Serious question: care to elaborate about actual 'pain' points? And I don't consider highly interactive graphing, dnd type of UIs or other things for which HTMX (alone) probably won't be the best choice - as pain points.

Hm, generally I would say the few pain points I've experienced with HTMX are: 1. Lack of a clear way to figure out where abstractions should take place. Eg, what does a full form validation flow look like, how should a user get a redirect, how much magic should HTMX handle. For example, if I'm submitting a registration form that has some requirements (say an 8 char password) I probably want it to hx-post to /registration/validate on submit. The tricky bit is figuring out what to do after that - if the form is invalid, you return the errors with the prefilled form keeping the values, which is fine. If the form is valid, you probably want to do a redirect. There are options here as well - normal HTTP redirect, hx-push, hx-swap on the body, etc. 2. Error handling - where do the existing HTTP error codes fit in with the htmx framework? Someone else posted this as well in Discord 3. Routing - keeping track of pushed URLs, manually pushing URLs, and making sure that the page loads after a refresh (need to check the headers to return the entire page rather than just fragments). 4. When to use hyperscript - I've discussed this in the past a bit as well, but generally the consensus seems to be use htmx as much as possible until you need to use hyperscript. 5. How to handle more complex data structures. The example that comes to mind is something like Dynalist or Workflowy, true SPA apps. They have nested bullet points that can be dragged around. This is a better fit for hyperscript, but with HTMX you might need to send a lot of extra data when each drag happens, even when using something like sortable. Eg, I think the example sends the entire new list order on drag, even though a single item was changed. To be clear, these are really, really nitpicky things. I'm also trying to contribute a bit to HTMX to help make these things better. Oh god I wrote a huge wall of text, hope it is clear though.

I think this is very useful feedback for the htmx gurus. Maybe some or all of your concerns can be addressed/answered. I'm just here to see the revolution unfold, waiting for an opportunity to use this appealing piece of tech myself.

Forgot to add - while HTMX allows for progressive enhancement (eg same site working with or without JS), other than

hx-boost

I don't think there are many examples about that in the docs. I don't know the best way to structure a backend that will allow me to easily handle progressive enhancement, so I just kind of gave up on it lol. HTMX still has similar browser support to what I was using before (Vue) so it hardly hurts anyone that uses code I've written.

I 100% believe that these have already been addressed potentially in the Discord chat lol, but I didn't spend a bunch of time searching back through the history. I'm sure that 1cg would say that a good chunk of these are backend dependent

@User I'm speaking only from my own experience here - not an 'expert' on all things HTMX or hyperscript, so please take it with a grain of salt! 😉 I use HTMX to handle interactions 'beyond the local page': when you have to send/receive data to/from the backend, an external server or an API. If you want to implement local interactivity and animations that use elements and data that are already on the page, then you can just use hyperscript. In some cases, you might want to use both together - eg., as the user types into your form you can play a little animation using hyperscript, and then when they submit it you use HTMX to send the data and display the response. HTMX and hyperscript were made to play nicely with together.

As far as workflow, in my experience HTMX and hyperscript have greatly simplified implementation and maintenance, when compared to other 'traditional' SPA frameworks. See, there are a few niggling issues I've experienced with these other frameworks, which are so easily overcome with HTMX+hyperscript. For example, most of these javascript mega-frameworks assume I'm going to be doing application data-management and state-management in the frontend - or at least, using an entirely javascript-focused stack, both in the frontend as well as the backend. But most web development out there uses a great variety of backend frameworks, encompassing all kinds of technologies and languages - eg., PHP, Python, Ruby, etc. And the application data (and state) is often kept on the server - in sessions, and/or in a database.

You literally took the words out of my keyboard as I was writing it

I was going to say that with React, you actually have state three times - once for the real dom, once for the virtual dom, and once for the frontend JS/application code. With HTMX/Hyperscript/jQuery, you just have it once in the dom.

Indeed, using the 'traditional' SPA frameworks, we often see a lot of duplication, specially when it comes to handling state, and data... There's validation checks in the frontend, then again in the backend...

HTMX allows us to shortcut all that.

which is okay if you have JS on frontend and backend, and awful if you have anything else like you said

I think part of the problem/struggle is that htmx is so low level, so it doesn't provide obvious solutions for all situations, just tools to build your own solutions.

this is a strength and a weakness of the approach, and each server-side framework might have a different answer for a particular problem, dictated by what tools and APIs it offers

and we haven't been programming this way long enough yet to have settled on all the best patterns

Right - I think nearly all my pain points would go away with just a few "more complicated" examples, but then you do need to sort of pick a framework to show those examples.

e.g. the https://en.wikipedia.org/wiki/Post/Redirect/Get pattern