Okay very understandable. Low coupling is always nice. I ask the question because I'm a web developer who uses Haskell and I wanted to start developing an HTML driven development ecosystem for the Haskell community. I believe no programming community dislikes JavaScript more than the Haskell community, so Haskellers would love to use HTMX since it would allow them to stay in "Haskell world" as much as possible. We don't have anything like Livewire, LiveView, etc. so I was wondering if would even worth it to implement if HTMX exists. I myself have been using it in some small Haskell projects, one of them being a project actually used by a trucking company, and it has been an amazing experience. I'm using a library, which I plan on releasing soon along with a blog post for using HTMX+Haskell, that allows you to use HTMX attributes in a Haskell DSL called

lucid

. https://chrisdone.com/posts/lucid2/ has examples of what

lucid

looks like if you're interested. Interestingly, HTML is a monad!!

On top of that library, I'm also working on one that defines each HTMX attribute as a plain ol' algebraic data type and essentially allows me to check at compile time that the HTMX attribute values I'm using are syntactically correct. This is cool to me since we value type safety. Anyways, I think HTMX+Haskell is an awesome combo and I plan on writing a lot soon about the combination and would love to share here and with the rest of the Haskell community because a lot of my brothers and sisters in Haskell land still aren't really familiar with it.

That's pretty cool. It would probably be more attractive to haskellers if htmx is written in something like PureScript, but it's worth giving it a try. Good luck with your project.

absolutely awesome

I often think of hypermedia as a functional transform of the DOM

if htmx makes programming for the web in Haskell more enjoyable, that'd be alright 🙂

Haskell and lisp: two programming languages I will never use but would love to help out

PureScript is a frontend language that compiles to JavaScript, so HTMX in PureScript would kind of defeat the purpose. You can use PureScript on the backend though. PureScript -> Node.js, but for the backend, Haskell is better unless you use PureScript for your frontend and want full-stack PureScript.

No, you misunderstood me. I was referring to the fact that haskellers don't like JS code (i.e. debugging or contributing to the underlying lib). PureScript kind of helps with that.

Oh yes my bad. I see exactly what you mean. Yeah if HTMX itself was written in PureScript, yeah that would be more attractive to Haskell developers. You are very correct.

we can only write htmx in one language, and javascript is the most commonly known one

if it was rewritten in another language it would probably be typescript

Yeah, no need to write it in PureScript haha At the end of the day it doesn't really matter from the user's perspective. PureScript tends to generate pretty inefficient JavaScript code, so performance and the size of HTMX would take a hit.

https://cb332eaf.this-week-in-htmx.pages.dev/issue/2/ draft of This Week in HTMX Issue 2, feedback wanted. (not too late to suggest stories, I'd love to get 1 more in)

I think you have to mention haskell-posting in htmx general

If you use htmx with Alpine and you have Alpine components

x-data

within the partials that are updated through htmx, you lose the x-data state prior to the update. If you use morphdom, the state is preserved. There are ways around this if you manage the state yourself server side and keep the x-data variables updated, or if you use the new Alpine $persist plugin. Also you can completely ignore this if you avoid having components within htmx partials.

Yeah, htmx should definitely stay in JS/TS. It was just a comment on aversion in some communities to JS code and re-implementing everything in their language (i.e. clojure is another example).

@User That's awesome! I'll have more material in the future once I finish writing the blog posts I'm working on. Looking forward to bridging the gap between the Haskell and HTMX communities 🙂

I'm not familiar with PureScript, but Typescript has a concept of "header" files, which add Typescript annotations to plain Javascript code. This lets developers import a plain Javascript file into a Typescript project as if it were written in Typescript. You can see an example in the htmx folder

/htmx/src/htmx.d.ts

. Is there something like this in PureScript? Something that would make it nicer to use in a Haskell environment without porting the whole library out of Javascript?

Yes, you can import JavaScript code in a similar fashion using the PureScript foreign function interface. I've used it before in my PureScript code to interface with JavaScript libraries. But honestly, outside of making it easier for Haskell developers and PureScript developers to contribute, I don't think it will have much benefit although it would be cool. The fact that HTMX is written in JavaScript doesn't make it harder or easier to use from the user's (programmer using HTMX) perspective. As I mentioned in a previous comment, I am in the process of porting the HTMX interface to Haskell, which gives you type-safe construction of HTMX attributes in your Haskell templates. And cool stuff like guaranteeing at compile time that calls you make to your backend using

hx-get

,

hx-post

, etc. actually exist. These are things that Haskell developers will enjoy. For example, let's say I had:

html
    <button hx-get="html/contacts">
      Click Me!
    </button>

In the Haskell HTML templating language called

lucid

this would be:

haskell
buttonSnippet :: Html () -- This type annotation is optional
buttonSnippet = button_ [hx_get_ "html/contacts"] "Click Me!"

The low-level implementation of the library I'm working on simply exports these attribute helpers like

hx_get_

,

hx_post_

,

hx_include_

so you can use HTMX in

lucid

templates. They all have the type

Text -> Attribute

. They are functions that take a string and return an

Attribute

value. These aren't safe though since I could put some string there that wouldn't make sense. For example:

haskell
buttonSnippetFail :: Html ()
buttonSnippetFail = button_ [hx_get_ "html/thisEndpointDNE%#2"] "Click Me!"

This would still "work" and I could deploy it and everything, but the end product wouldn't make sense. Clicking the button would do nothing since the endpoint doesn't exist. This a bug that can be caught by the compiler since we humans miss things all the time. In Haskell, we try to get rid of programs that don't make sense by using type specifications. The compiler doesn't build programs that don't make sense, because even if they are built, deployed, and run, they won't work properly. Might as well be upfront about it, right? The higher-level HTMX library I'm working on does just this. To do this, I'm combining

lucid

with a well-know Haskell library for specifying APIs as types called

servant

. So using

servant

we can define our HTML contacts endpoint as a type:

haskell
type Contacts = "html" :> "contacts" :> Get '[HTML] [Contact]

-- The following basically brings the Contacts type to the value level
contactsEndpoint :: Proxy Contacts
contactsEndpoint = Proxy

This generates a type-safe endpoint for me. The higher-level library I'm working on exports type-safe variants of the HTMX attribute helpers such as

hx_get_safe_

,

hx_post_safe_

, etc. We can use these like so to create a type-safe version of our button example:

haskell
type Contacts = "html" :> "contacts" :> Get '[HTML] [Contact]

contactsEndpoint :: Proxy Contacts
contactsEndpoint = Proxy

buttonSnippet :: Html ()
buttonSnippet = button_ [hx_get_safe_ contactsEndpoint] "Click Me!"

By using the type-safe variants, the compiler prevents me from deploying any code that would make a call to an endpoint that doesn't even exist in my backend. If the code compiles, it's guaranteed to work. In a small example this obviously isn't much help, but in medium-to-large apps this is great and has many benefits in my opinion. Especially long-term for maintainability and refactorablity.

Is it now – also a talk at DjangoCon

And one by @User even

Even a third one by @User 👀

I'll definitely have to write up what I've learned doing this. True, what I was missing in my original approach was

htmx.process

, but flipping my thinking got the logic back on the server, making the browser a request-and-render engine instead of setting values, making calls, etc.

This look really good! Next time I'd suggest adding a description to your PR so it is easier to scan over. Having to look through the files changed is not particularly appealing when maintaining an open source project.

you're right, fixed!

This is really nice. I use htmx in a lucid+servant haskell project, and such a library is something that would make my life easier. Let me know if you need any assistance or extra hands.

can I ask how you use a database in haskell?