karax VS htmx

The frontend uses Karax, which is my favorite frontend/SPA library. It is an absolute joy to use, even if it's a bit rough around the edges.

https://github.com/karaxnim/karax

I have used Nim for personal projects for 6 years now and it continues to surprise me on how well versed it is for many problem domains. I am fond of it's SPA framework, karax https://github.com/karaxnim/karax for which I wrote a translation utility https://github.com/nim-lang-cn/html2karax Latest Nimv2 release candidate has improved in the ergonomics and syntax that affect compilation to js, so I was able to cleanup my webapp's code to be less verbose. On GPU programming there has been a few projects that touch GPU programming, most notably https://github.com/treeform/shady

And it's present not only in Python but in other languages as well. Check for example https://github.com/karaxnim/karax - I don't know why people would want to hide all of their HTML in Python/whatever language. Then limit their ability to script and style it in one way or another.

> the real killer feature to me is the javascript target

Agree, this is amazing because you can share code and data structures between front and backend (for example: https://github.com/karaxnim/karax).

Also, it's really nice having high level stuff like metaprogramming and static typing spanning both targets. Things like reading a spec file and generating statically checked APIs for server/client is straightforward, which opens up a lot of possibilities.

E.g. Nim focuses on enabling what it calls "single page web apps": https://github.com/karaxnim/karax.

Karax [1] being Nim's SPA framework that also supports server side rendering.

[1]: https://github.com/karaxnim/karax

I recommend you to take a look at Karax. It's a front-end framework for Nim that can compile to regular JavaScript. If you want to know how to use it with a webserver, Joker is a good example. With the Joker config, all of the compiled .js files land in /public/views, where you can take a look at them. But keep in mind that the JS that Nim produces is often rather cumbersome and hundreds of lines long, even if it's just a simple program.

When I work with HTMX I need isolated component that can be reusable a form. So I create a PHP Function that generate the Input Datalist.

I was inspired by htmz (which was in turn inspired by htmx) and how the author got pretty close to a basic htmx-like experience just using an iframe. I wanted to push it a little further so whipped this demo together. My submission demonstrates progressive enhancement for the form - with js enabled the request targets an iframe that is inserted into the dom, meaning the page doesn't actually navigate (similar to event.preventDefault()). The iframe receives the html response from the request and on load triggers a function to swap out it's contents into the main page.

As described on htmx.org: "htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext"

Apart from the source code itself, the repo's README also gives a bit more details about the various packages I used.

1. htmx: https://htmx.org/

Also, there’s some response header juggling you have to do when submitting forms that have a validation step before redirecting: https://github.com/bigskysoftware/htmx/issues/369

I’ve tried to iron out any footguns or server requirements I’ve bumped into while using HTMX & Hotwire in my projects.

✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.

I've been digging into HTMX lately (using Python web frameworks) and find the concepts and approach to be interesting and promising. The idea of hypermedia driven systems over the current practice of JavaScript based frameworks (I never really got into React, played with Vue, and enjoy Svelte/SvelteKit) and the ability to chose your language/framework for the backend while primarily leveraging HTML/CSS on the frontend just seems refreshing.

Apparently it changed from 2-clause BSD: https://github.com/bigskysoftware/htmx/commit/e16f1865a494b6...

(The zero clause license drops the requirements for preserving the copyright notice when distributing)

It would be a sin not to start with something that prides itself on being the front-end library of peace. HTMX skyrocketed in popularity in 2023, gaining most of its GitHub stars during the past year. HTMX is not your average JS framework. If you work in HTMX, you will spend most of your time in the world of hypermedia, looking at web development from a completely different pair of eyes as compared to our usual JS-heavy outlook on modern web development. HTMX leverages the power of the concept of HATEOAS (Hypermedia as the Engine of Application State), enabling developers to access browser features directly from HTML, instead of using Javascript.