KEEP VS htmx

Btw. unsigned types are partially stable now in Kotlin 1.5: https://github.com/Kotlin/KEEP/blob/master/proposals/unsigned-types.md

It will be easier with Context receivers, those are not available yet

If you like the idea of CoroutineScope, CoroutineContext, suspend, you will like the Kotlin Coroutines Design proposal https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md

I base my opinions on things that I've read from Mr. Elizarov and from the value classes KEEP: https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md

Be sure to read the full documentation and how value classes in Kotlin relate to Java’s upcoming Project Valhalla.

https://github.com/Kotlin/KEEP/issues/259 I'm guessing in 1.7 (or by the pace features are currently getting released, 1.17...) it will get an experimental release.

The value classes KEEP itself even raises the point that even once Valhalla is released, its adoption won't be universal at first, and that limiting a major feature like value classes to a specific version of the JVM, or a specific target, doesn't make sense.

A lot of people have been finding success with htmx. Essentially, you're using POST requests to swap out parts of html based on view logic, so it keeps it close to simply using html/css/python if you don't want to learn a lot of javascript. Here's an article explaining how to use it with django, but it works similarly with flask.

https://htmx.org/ - easy AJAX for simple SPAs.

HTMX could also be something to consider. Thomas Güttler's talk from DjangoCon has a good introduction.

htmx is a library that brings interactivity to HTML through the use of attributes and HTTP headers. Whereas projects like Vue, Angular, and React prescribe completely different programming paradigms than traditional web development, htmx provides partial-page-swapping and progressive enhancement within straight HTML. This brings a lot of the benefits of the SPA architecture to vanilla HTML, without requiring a completely different paradigm than the one we have used on the web for 30 years. In practice, this greatly reduces the complexity required to produce an interactive web application.

Your u_form and p_form could be retrieved using htmx, avoiding the use of JavaScript altogether.

I agree entirely with you and I don't regard it as unfortunate at all that this article shows that HATEOAS is unsuitable for JSON HTTP APIs.

It is extremely suitable, and, in fact, is simply descriptive, of an HTML-based API, however.

A lot of my thinking around this comes from my work on htmx, a tool that turns HTML into a richer hypermedia:

https://htmx.org

And I am actively encouraging people to try to split their thinking about JSON Data APIs (RPC) and REST-ful HTML-based systems.

The success of the web argues that the hypermedia approach is a good choice for a large set of systems.

The problem today is that hypermedia development has been stuck in the late-90's/early-00's which, when contrasted with JSON/RPC-based development, is really showing its age, particularly in terms of UX.

https://htmx.org is an attempt to rectify that situation and get hypermedia-style development back in the game as a viable, modern network architecture for more than just content-oriented web sites.

Yes, I agree entirely. The crux of the issue is that HTML has stalled as a hypermedia for a few decades now, but I am trying to fix that with htmx:

https://htmx.org

htmx is the result of my research :)

> What are its cons?

Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all.

---

More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups.

I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)