I recently dug up an old project in an attempt to improve on it. It's a code sandbox for playing around with HTMX in the browser, that runs a mock server within the sandbox iframe. The server "framework" is loosely based on Django, so if you're familiar with Django, you'll immediately understand what's going on.
I recommend clicking through the examples.
Github repo: https://github.com/lassebomh/htmx-playground
Probably my favorite part is the lack of HTMX specific code. It's designed to mimic the client and server, but really nothing else. In principle, this means that it is agnostic to whatever frontend framework is being used.
Known problems: Limited mobile support, Ace Editor (should just be Monaco) and lack of proper error outputs.
Feel free to give feedback, suggestions or questions.
I learned a lot when making it, and I hope you'll something about HTMX! Happy tinkering.
Is there a way to use HTMX with minimal server side changes. Specifically if I have an existing page that you fill in a form and submit and response is of course the entire page. I think it would be cool to tell htmx that the whole page is being returned BUT I only want to update #my-form and that way you don’t need any “if htmx request” kinda stuff on the server.
This is for people who care about their site working without JS. But also it allows you to have a single backend endpoint to handle multiple things (for example comments, sign up to email, like button, all in one)
- https://htmx.org/attributes/hx-select/ - https://htmx.org/attributes/hx-target/
I played with it recently and it was pretty easy to enhance a completely non-js CRUD type app and have it fall-back gracefully. Seems a similar concept to HTMX but has a more batteries included / high-level approach.
https://htmx.org/extensions/multi-swap/
That'll return whatever partial thing you want to return and replace <your element here> (with 1sec effect).
In which, you still need to include a JS file. I'd still count that as Javascript.
this makes htmx more work, in general, to accomplish things but also less opaque
htmx is laser focused on generalizing hypermedia controls in HTML (anchors & forms)
Dead Comment
I'm used to proprietary frameworks, in my case I worked with intershop which uses isml. (this is comparible to something like thymeleaf). In recent years we tried to move away from this approach and go to the angular front end Stack because it's easier to hire a dedicated frontend developer than it is to hire a specialized fullstacker. Stuff can get complex when you're using something like htmx and developers don't want to fight spaghetti monsters. You don't want you backend guys to be the bottleneck, e.g. when FE just creates HTML and the backend has to tie it all together.
My question is; has HTMX thought about the pitfalls like this, and how do you counter it?
It is very straightforward to pick up. Unless you hire code camp devs who only ever learned React, no actual CS topics, anybody should be productive within at most a week.
Keep in mind HTMX does not solve all scenarios, there are times when a SPA using a JS framework is required.
I do agree there are times that a traditional front end lib might be needed but it is much rarer than we think.
Interesting to hear that after a mention of Angular. Different ideas of complexity I guess - frameworks like it give you structure but complexity is still there, and probably orders of magnitude higher.
Ultimately you want FE devs that know the web stack well - JS, CSS, HTML, browser APIs. They will be able to pick the best tools & frameworks for the job. Something like HTMx is trivial to pick up.
https://risingstars.js.org/2023/en#section-framework
Just behind react and ahead of vue, svelte & angular. So the future looks promising in that regard (although I do expect it to drop back after the initial excitement dies down).
htmx is pretty simple, most web developers can pick it up in a day or so. It does require a mental shift for both developers as well as PM/architects in how development is done, because it pushes the organization more towards a full-stack paradigm, with developers owning whole features rather than "front end" and "back end". We have a book, free online, you can read, that will help with this:
https://hypermedia.systems
In addition to the docs (https://htmx.org/docs, which should take about an hour to read) we also have a bunch of essays on both philosophical & practical issues around htmx & hypermedia in general:
https://htmx.org/essays
htmx tries to be "scaleable" in that there are very few base ideas to the library and you can use only a few of them to implement useful behavior (e.g. lazy loading, to pull a section of a page out of the critical first-paint path, is two attributes: https://htmx.org/examples/lazy-load) but then it provides enough hooks and deeper features (e.g. events, event filters, etc.) that as you get deeper into it you can accomplish what you want.
finally, with respect to spaghetti code, this is a perennial danger in all software development. My admittedly limited experience with SPA libraries has not convinced me that they prevent spaghetti. w/htmx you want to focus your efforts on the back end and take advantage of whatever tools your server-side environment offers to properly factor your application. Because htmx allows you to pick any server side technology (SPAs put pressure on you to adopt JavaScript/TypeScript on the back-end, since you already have a large application written in them for the front-end) you have many more options & paradigms available for organizing the bulk of your application logic.
addendum: I should mention that i try to outline when htmx is a good choice for an application here:
https://htmx.org/essays/when-to-use-hypermedia/
htmx is a tool, a good tool in many cases, but just a tool, and i want to be clear that it isn't a silver bullet for web development
One neat benefit is that I am now able to unit test (well, unit integration) my views with a headless browser because my UI is served by my backend and not a separate service that has to run with all the yarn and npm bs.
TL;DR: I'm a backend person who struggled to pick up react over a weekend but picked up htmx in an hour. Your FE devs will have no problems with htmx.
They will have to become familiar with your system's templates syntax and how to work in the backend to organize their partials and components and may even have to decide how that should all be structured.
I would love to see your project as well.
Currently, as there are probably not many reviews on that site it is near impossible to see an example of a review.
Monaco doesn't work on mobile by design, so people use Ace on mobile.
At least the last time I checked GitHub[0].
[0] https://github.com/Microsoft/monaco-editor/issues/246
I think that was the problem with Monaco on mobile: the keyboard never worked correctly. That was my experience.
Edit: I don't want to complain, Monaco is superb editor and it would be super if it worked on mobile consistently. But from the github issue, it appears that Microsoft doesn't seem to want to change that.
I can see just enough editor UI stuff on my phone to strongly suspect I'm in your target userbase, but because of screen size issue I can not see enough to have any idea what tsdiagram actually does.
This is cool though. Good job!
keep your domain logic out of your controllers