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!
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/
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.
> It becomes very obvious that this is how web development should have evolved.
I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”.
IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.
I fully agree with you. I'm a fan of htmx, can recommend it and have used it in some projects by now. But...
For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.
Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.
Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.
So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
> If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool.
The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications.
Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.
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.
I'm kind of guessing / reading into their comment here but. Using htmx doesn't give me the feeling of "this is the only way I ever want to do this" but more "if html worked like this I wouldn't use js most of the time." The sense that an opportunity was missed and now we're paying for it in complexity.
1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;
2. Dotnet back end with Angular front end.
In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.
The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.
Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.
Not sure you've solved the complexity when you've just slotted in another front to a general solution that is over-engineered. You could have replaced either scenarios with a single NextJS or SvelteKit solution. Go above and beyond in "complexity", write your Node backend (keeping it one language, JavaScript), and use vanilla HTML and JS to consume that.
To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).
The difference is those were already tools we were using. You _(hypothetically?)_ can't eliminate the complexity of dynamic apps without limiting flexibility. However you can move the complexity in-band, to a domain you are already using and preferring.
Plus, if it's done right, you can get a lot of functionality while remaining No-JS friendly.
> With JS you must use JS or TS and the steam factory that comes with it. With htmx you can use any language.
Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
Much of your business logic can live in the backend, and it keeps your frontend really tiny. The idea is to generate HTML on the backend, instead of using a front-end framework to generate HTML on the client from an API call.
You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.
> Much of your business logic can live in the backend, and it keeps your frontend really tiny.
Ah, so "with htmx you can use any language" is true because its users are no longer using a programming language per se for the front-end, but instead are defining logic with htmx's DSL?
Yes but vue is far more involved than htmx though. Vue has its own way of architecturing your project. htmx is closer to a progressive enhancement of html
I see it as much more, many things can be stripped out altogether. Client-side state management. Client-side input validation. Fallbacks for when data hasn't been loaded yet. Less async-based code, less coordination-required and event-driven code (this stuff happens but much easier and often code-free with HTMX).
Its not a fit for every site or use case but more than any other front-end tool or library or framework, it has enabled me to actually realize the UI concepts in my head to the actual screen, and usually a lot quicker than I'd expect.
So you only do input validation on submit? Isn’t that user hostile?
This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.
Not hostile at all, and we arent degrading the user experience -- much improving it, in my opinion. With HTMX you can do real-time validation on each input element on the server and provide instant visual cues to the user anytime one fails. https://htmx.org/examples/inline-validation/
Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).
In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.
Disagree that it’s good UX. Now the user only gets feedback when they lose focus on the field, forcing them to go back and refocus it. In conventional React they get feedback on each keystroke allowing errors to be fixed while the field is still focused.
So when the person is starting to enter an email address, the page goes red until he enters the .com at the end? He gets an error for the first 9 digits of a phone number? Do you implement debouncing?
My frontend experience predates the rise of react etc. I have used jquery.
The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag.
Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.
Most of my experience using jQuery was on sites that required progressive enhancement, and the easiest way to do that was to create an htmx-style framework anyway.
I think the biggest change from jQuery flows is that the behavior is attached to the elements themselves instead of a script over here poking at the dom from the outside.
>You can't believe that this isn't how HTML evolved to as a hypermedia.
That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%.
What are technical differences between HTMX and early versions of Angular 1? It has the same idea of sprinkling some attributes over HTML to make it dynamic for easy cases. There were many frameworks that started like this (Angular 1, Vue, etc), and after getting some traction they grew into full-blown SPA frameworks, because there is a real need for more difficult cases.
If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.
htmx uses hypermedia, rather than client-side managed state
as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
You keep using the term hypermedia and I'm not certain what is meant by that term (I was thinking it referred to linked media). Hyper means over, right? So is hypermedia more about the environment media is in than it is about links?
yes, I prefer the term hypermedia over hypertext because it stresses the systemic nature of a hypermedia system: a hypermedia (e.g. HTML, a hypertext), a hypermedia client (e.g. a web browser), a hypermedia protocol (e.g. HTTP) and hypermedia servers.
As far as what the term _hypermedia_ means: it is a media, such as a text, that includes within it _hypermedia controls_. Those hypermedia controls allow non-linear branching and interactions with the media, hence the term _hyper_, that is, above, "normal" media, which is consumed passively.
The hypermedia controls we are all most familiar with are anchors/links & and form tags. htmx attempts to generalize the concept of a hypermedia control.
The book goes into gory detail if you are interested in further exploring the idea.
Out of curiosity, I presume you were working on the frontend part using Clojurescript? Have you used some kind of wrappers around htmx or just a simple js interop was enough?
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.
I am happy with HTMX for my RSS reader. The issue with front end apps is, and always has been, the complexity of updating the UI after a user makes a change.
For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in
Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.
If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.
Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.
I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.
React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.
Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP
(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)
or a "no-code" app builder could be great.
I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
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.
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.
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 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!