silver-arrow

I loved Plato on my TI-99/4A computer when I was a kid. I credit it with helping me become a much better student. When my oldest son was struggling in grammar school, 15 years ago, I got it running on the Mame emulator for him, and it turned him and then his sibling into excellent students!

I don't understand why there isn't an even better version of this in the modern age. A complete curriculum K-12 that is self-driven in a similar manner. Mostly the same methodology of mostly reading and images with quizzes after sections. Then a total category exam. Maybe scatter in short effective videos, but it should not be video centered!

We moved away from ClojureScript entirely. We just run a plain ole java uberjar with the Clojure/ring/hiccup/Compojure spitting out the HTML with whatever htmx attributes and response headers we need. There are instances where we may need to sprinkle in some javascript for some extra dynamic things - which turns out to be very infrequent. Instead of sprinkling in the javascript, we have been using _hyperscript instead - love _hyperscript.

Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.

Exactly! I love the sweet spot that htmx hits; please don't change that!

That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.

Great news.

I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR.

Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htmx is doing through javascript becomes baked right into HTML and the browser clients.

If you are mistakenly believing it is just some derivative of Angular or you are not grasping the significance of its advancement of the architecture of hypermedia, please do yourself a favor and read the excellent essays on their site; you will then truly understand what REST is and what the importance of real HATEOAS means: https://htmx.org/essays/

They also have a free book here: https://hypermedia.systems/

We made a costly wrong turn 10 -15 years ago by attempting to rebuild thick clients on the web with a JSON API architecture instead of expanding and enriching the new and powerful idea of the early web: hypermedia.

htmx is so wonderful. We have had amazing success utilizing it and returning to a hypermedia approach to web dev. The essays go into detail of why this is.

I have immensely enjoyed and benefited from using htmx for the past 18 months on projects with Clojure as the backend language. I had done years of full-stack Angular then React on the front-end and Java Rest endpoints on the back-end with teams of all sizes.

htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web.

Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.

Exactly! Well said

htmx has provided the greatest satisfaction and production of my 30-year programming career. After a year of constant development experience with it, I am confident that this is the proper method of building web applications. It truly is how HTML should have evolved.

That was such an educational experience! Great talk and speaker.

Vim9script is pretty darn good; and fun to use.

Excellent and very productive language. Personally, I did 15 years of straight Java (before that C and C++), then 5 years of Clojure. For me, the most telling dynamic is when I recently returned to a Java project and realized how much better Clojure is - even for large projects ;)

The lack of static typing, which is so often used as an argument against Clojure, is actually what makes Clojure better. The Java projects become a morass of types scattered into a myriad of packages; no matter how experienced you are with Java. Clojure's dynamic underpinnings and its paradigm of hundreds of functions for a few data structures allows for very lean designs that are easier to wrap your head around and keep in your mental models.

The other features are just gravy: immutability built in, REPL interactivity, Transducers, Protocols etc.

I felt the pain going back to a Java project.

True BizarreByte. I love how htmx let's you easily add animation indicators on actions, because many times it's too fast due to the small chunks coming back and getting placed so quickly in the DOM

You for sure wouldn't want to build a spreadsheet type app with htmx because of that aspect. Many other types of web apps can benefit from the simplification of the architecture, however. And like my paging example, many times you need to go to the server anyway. But sure, like anything, I wouldn't use htmx for every situation.

Yes it can. Right, your server-side routing would have those routes set-up. Naming them can get interesting :)

Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns.

As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button that will call for the TR HTML chunk from the server. You can imagine replacing all the rows for a paging click etc.

Again check out the example for cool stuff.

It really is so terrific. After using it for over a year, I agree with the creator's of htmx when they say that this is how web development would have been if HTML as hypermedia was continually improved all these years.

When you start using htmx, you raise your eyebrows and think - hmmm this could be something interesting. When you use it for many months, you then open your eyes very wide and think - this is something special! In hindsight is so damn obvious, why didn't it happen much earlier?!?!

Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case.

https://htmx.org/

Excellent article that clearly describes the benefits and simplicity of hypermedia applications. We have experienced the benefits of designing our web applications in this manner using htmx. This library, htmx, has been a real lifesaver for our projects.

Just to be clear, the author is NOT arguing for some forced quasi HATEOAS in the typical current architecture of JavaScript rich client passing JSON data in RPC fashion over HTTP. Instead, he is stressing the beneficial original hypermedia architecture of the web; that being, server rendered HTML to the hypermedia browser client. Htmx adds much dynamic behavior to such an approach.

I initially had the same thoughts as you when I got on my first Clojure project. Previously, I used strongly typed languages with "approved" frameworks. Developed in Java for over 20 years before getting put on a Clojure project.

It because apparent over time that the lack of types and the other features provided by Clojure resulted in much smaller and simpler codebases compared to those previous languages and frameworks that I toiled in for so many years.

It has really highlighted to me the value of simplicity for better productivity and maintainability. I wouldn't even want a framework to build web apps using something like HTMX for example. Clojure handles HTMX in almost magical ways with a simple library or two such as hiccup.

Recently, I was doing some work on a Java / Spring project and was dismayed with the proliferation of classes and packages; really the complexity of it all. And remember, I am solid with Java experience, so it is a result of those types of languages and architectures IMO.

Hmmm. alpine.js does complement htmx very well and is pretty popular, so it is a great choice. I liked _hyperscript when I saw it when assessing htmx so thought they might play better together since the author is the same for both. But I don't know if that is even really true actually, and alpine.js seems to be just fine. Honestly, it may be because I used AppleScript back in the day and _hyperscript reminded me of it!

I see bnert gave a very good answer to your question in a reply. So to echo what bnert said, as far as the java template frameworks like jsp and thymeleaf, htmx is complementary to them. Here is a good scenario in this blog post by someone. https://www.wimdeblauwe.com/blog/2021/10/04/todomvc-with-thy...

Also like bnert, when using Clojure we prefer to use a library on the server-side called hiccup to generate HTML from Clojure data structures instead of a template library. Either way, template engine or hiccup HTML generation, the principle is the same. You are coding everything on the server-side and rendering HTML back to the browser - something it is VERY good at rendering. :) As part of that HTML rendering, you are putting attributes on some HTML elements that htmx understands from the browser side.

ClojureScript is a totally different concept, as it basically allows a Clojure developer to write JavaScript in Clojure - it generates JS. With the server-side rendering model above, we still code 100% in Clojure, but we get to jettison a lot of the complexity of the ClojureScript model (Reagent etc), and development set-up. It is far simpler.

Other benefits of the hypermedia approach provided by htmx: 1. It is obviously true HATEAOS, so we don't worry about end-point versioning issues. 2. The barriers of the UI team and Server team negotiating and re-negotiating end-points is gone. We have all transitioned to "full stack developers" - sanely. 3. As mentioned above, it is language and server-side agnostic, so use what you prefer and have competitive advantage with using. 4. Simpler mental model. The team thinks in hypermedia terms from a server rendering perspective only. That lets you wrap your brain more easily around the business problems. 5. You have the full power and capability of your database at your disposal instead of going through and desigining the correct endpoints to get there first.

Hope that made sense

The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags.

Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements in the browser directly, the need for JavaScript directly in our code lessens dramatically. As you mentioned, though, you do need to include the hmtx JavaScript libary with a script tag. That library is very small though when min - something like 12k.

Amazingly, you can build some pretty dynamic web apps using htmx and sprinkling in a little vanilla JavaScript or _hyperscript if you are daring! The main key for us though is thinking from a hypermedia point of view with SSR; that coupled with the elimination of the complicated development configurations, is a huge win in simplicity and productivity. No more versioning our endpoints too!

This answer is exactly correct. You must really think about how this dramatically makes developing these types of applications simpler by a magnitude. You are literally killing significant complexity that causes time, effort, and bugs. And, no, this is not merely shifting the problems back to the server-side. This is how HTML should have evolved in the first place.

That’s part of the benefit of htmx and it’s hypermedia approach, you can build the backend in anything you prefer. Some like using language and frameworks that use templates. Others, like we do, used fairy basic HTML generation libraries. We love Clojure so we use the Hiccup library to generate HTML. We use the full power of clojure and functions to build reusable HTML type components and their fragments.

It’s pretty simple to use the htmx events on the Response to handle errors dialogs or other behavior

Agreed that it is a breath of fresh air. It totally eliminates heavy complexity in the development environment and networking protocol layers. What makes me happy is that it completely reinvigorates the server side language you prefer to use.

Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / React to vanilla Clojure on the backend doing SSR of HTML with htmx HTML element attributes. All with 1 script tag that includes this wonderful library. Kudos to the creator of htmx!

This is what hypermedia architecture with true HATEOAS is all about. It feels like we took a wrong turn a decade ago, and we have been trying to reinvent rich clients with JSON RPC designs from the 90s. It has resulted in too much churn and complexity IMO.

For sure. You could also build front-ends with Clojure using htmx. It really simplifies building dynamic front-ends by allowing you to return to the hypermedia model with server-side rendering. It has been fantastic. No ClojureScript. Just a normal Java Clojure REPL.

https://htmx.org/

No problem. Check out their site for some wonderful examples of what it can do and have fun!