I've built a small project management system (as I was in need of a custom one) with Unpoly as a proof of concept. And, oh boy, it was easy and fast.

I have a previous experience with VueJS and Django REST Framework. It is nice but it's a whole other kind of work. Too many build tools, CIs, State Management hell...

I'll, if I can, keep developing with the new-new stuff (Unpoly and htmx). Probably won't be 100% of the time since it's far for mainstream technologies.

Unpoly rocks. Far better and more conplete than Htmx. Sadly not as good at marketing.

Rather than "complete" I would say "high level".

htmx is a relatively low level extension to HTML, by design. Unpoly offers a lot more structure, such as layers, which you would need to implement on your own or using another library (e.g. tailwinds or bootstrap) if you are using htmx.

This is reflected in their overall sizes: 11k for htmx, 41k for unpoly.

I don't view either as better in general: they are two different approaches to building hypermedia-oriented applications, one more structured and one less. Which one is better for your particular application depends on your own engineering needs and tastes.

Yes, I agree with your explanation. I should have said "far better for my own preferences". I agree that probably you can implement a lot of what Unpoly provides starting from HTMX

No problem at all: unpoly is a great piece of software and I very much understand being a passionate fan of it. The approach Henning took is quite ingenious.

We've been using Blazor for about 2 years now and it's been a really good ride so far. Server-side mode isn't for every application, but all of our stuff is internal-only so it works perfectly at our scale.

Definitely not "zero" JS, but our JS interop source file is only ~200 lines of code at the moment.

We have some incredibly complicated UI interactions (essentially canvas drawing) which would be a nightmare to synchronize state for. Being able to keep all that state server-side makes it way easier to cope with. Our clients are basically just a dumb terminal on the other side of a websocket.

Just talked on a slack about this. I strongly dislike htmx since it creates a DSL where there wasn't one needed. I think in general if you don't need to build custom behavior (which a SPA enables) then going pure SSR (without any of these) is a good way. If you need custom behavior then these solutions probably won't be enough. To me it feels like a very small slice that needs these solutions but still don't need a "more full JS frontend".

An example of the DSL in htmx I mentioned (from https://htmx.org/docs/#validation):

    <form hx-post="/test">
      <input _="on htmx:validation:validate
                  if my.value != 'foo'
                      call me.setCustomValidity('Please enter the value foo')
                  else
                      call me.setCustomValidity('')"
            name="example">
    </form>

To me this reinvents a subset of js (and compiles it down to js), event handlers, etc. If you just need some inline behavior just use the on* attributes that are in html and if you need more then write a js file and if you need even more use a framework.

This is hyperscript you are unhappy with, not htmx. You can (and probably should) use javascript for this sort of thing.

htmx is a straight forward extension to HTML as a hypermedia, facilitating more functionality within the original hypermedia model of the web. A good pure htmx example would be active search:

https://htmx.org/examples/active-search/

This is purely declarative htmx that enables a UI pattern that most developers would assume requires that they write javascript.

Of course there are going to be situations when a purely hypermedia-based solution isn't going to work and you will need client-side scripting. VanillaJS works fine for many of these (htmx has an extensive event model for you to hook into.) A lot of people like AlpineJS, which is a great library. And, if you are adventurous, you can give hyperscript a try for these needs.

But that shouldn't be confused with htmx, which provides a lot of functionality out of the box as purely hypermedia-oriented extension to HTML.

As an aside, with VanillaJS you can't simply use an "on" attribute for non-DOM events, which is why people like solutions like Alpine or hyperscript, which offer general event handling inline on elements.

I think you correctly identify that the typical use case for HTMX is something very narrow. There's a small no-man's-land between a full SPA and an SSR app where you might want to see content moving around without full page flashes, but don't need a lot of complexity/finely-tuned interactivity.

I've used HTMX _alongside_ some more fully-baked JS on our site. There are some particular use cases that are a lot more rapidly accomplished by adding a little `hx-post` and `hx-swap` attribute than writing out the JS itself. It hasn't replaced our usage of vanilla JavaScript or anything, but is a nice lighter-weight dependency that plays nicely with Django templating IMO.

The hx-post/swap and similar are pretty small and simple to write for yourself though, so you don't need to include the full suite of htmx. If it was me and I only used those bits I'd probably write them myself or use a library that only focused on those things without the whole DSL.

HTMX doesn't include the whole DSL - the example above is using Hyperscript, which is a separate project by the creators of HTMX.

Just to clear some things out: the "_" on the <input> is something hyperscript specific (not part of htmx). You could (and should, I guess) go with native JS for the validation.

Hyperscript is another project from the same author of htmx and is a side project not related to htmx. Though, it can be complementary.

HTMX is a nice utility for a fairly basic set of common JS tasks ("load this content and put it there", "submit this form and show its response there") and I think it's a useful tool to have on a project. Its footprint is small so there's little concern for adding bulk to your bundle.

I don't think it solves every problem efficiently, but as SahAssar mentions (with some thoughtful criticism) below, as your needs become more complex, the framework provides at least some kind of escape hatch into more traditional programming, admittedly strange though it looks embedded as a DSL that gets put into an HTML attribute.

On the other hand there are some cool behaviors that I've leveraged to great success -- in the responses you return from your backend that HTMX is interpreting, you can encode data into headers that HTMX will turn around and trigger as DOM events. Pretty neat way to interact between your front and back-end both on a DOM and a JS runtime level.

Maybe you mixed up Inertia.js [0] with Livewire [1]?

I've worked with Livewire quite a bit and think it's a brilliant concept. It's very easy to get started and you get great results without much training.

However, as soon as you encounter problems or want to implement things that deviate from the standard case, you quickly realize that this is a new technology. There isn't a solution for every problem on Stackoverflow and apart from the official documentation there is very little good information.

So for complex apps, it's often better to go with VueJS which has a better and more comprehensive ecosystem. The great thing is that Inertia.js exists as a link to Laravel, so you don't have to build an API and you don't have to worry about things like routing or authentication.

[0] https://inertiajs.com/

[1] https://laravel-livewire.com/

Edit: Add more background

I'm curious about this. Can you share any specific problem you had and couldn't find a solution for?

I don't remember exactly. I was missing a very specific feature and didn't find any information about it in the documentation or elsewhere, although it's probably a frequently requested issue. Only after a long search did I find a hint in the Github discussions that led me to the solution. For similar problems with more established technologies, you can usually find a blog post or a Stackoverflow post about such things within a very short time, often even with a code example that you can copy and paste. With Livewire, this is often not the case.

Edit: To be clear, there was a solution, a very good one indeed. It was just hard to find.

The problem with these generic explanations is that we can't know if it was a real issue with the tool, if it was a misunderstanding of how to use it from your side, a problem with documentation, a third party plugin, etc.

This is like saying "React is bad because once I had a problem I don't remember".

I'm aware Inertia.js is the odd one out of the bunch, it still allows the server to do most of the work.

Yes, as I was writing my comment, I realized that Inertia.js does kind of fit in. Only then you really can't call the whole thing JS-free anymore.

Am I missing something? All of the OP’s listed software depend on JavaScript. How is that “JS-free”?

these are ways to move most of the client-side logic to the server, it's not exactly no JavaScript but there is much less of it

I think the idea is to avoid to write the JavaScript yourself, not that you don't use it under the hood.

The author mentioned "as little (or no)".

Experience with Rails and Hotwire has been very positive so far.

Well, pretty much all the JavaScript stuff is one decade old. All the technologies before that were SSR (the term SSR didn’t even exists).

So you can totally make an application only with server side technologies because it was how we did before and… it just worked. What is interesting is that all the frameworks, due to their age are very mature.

If you are ok with Python, I suggest you to go through the official Django tutorial, it’s pretty long (some hours iirc) but it covers a lot of topics by guiding you through the development of a complete application.

But other frameworks like Rails, Symfony, are also very mature. ASP.NET Core with Blazor is also nice but IMO, harder for a newcomer because it needs a lot of boilerplate.

All those technologies are pretty boring, but in the good way: they allow you to get shit done without thinking a lot about technical issues.

You didn't mention it specifically, but I LOVE developing with Phoenix LiveView. I find that I'm as productive as rails (with rails views), but can get frontend interactivity, easy web socket and Pub Sub setup, and its all built on a much more performant language/framework.

My job is to build frontends on top of various client management systems and figured out, that I get more maintainable code and am more productive using the templating of the CMS itself instead if decoupling the frontend from the CMS entirely.

So since two years, I use the Hotwired stack on top of PHP (and now with Vite as bundler) and that is so far the best solution I found. I can like use the CMS integrated solution for handling forms, as an example, but can plug in Hotwired Turbo and some Stimulus controllers when I want things to happen async on the client. I now have my own set of generic stimulus controllers I reuse in every project. But at the end of the day, those websites work without JavaScript.

I used the intercooler, which is the predecessor to htmlx and really liked it. I plan to use htmlx on my next web development project.

I recently took a look at Hotwire and Unpoly just to make sure I wasn’t missing out on something better. I found htmlx simple and intuitive.

I just started playing with inertia and am pretty impressed. Was able to get it integrated with a rails project (which was already setup with vitejs) pretty easily. Then I can have templates like this: `app/views/welcome/index.ts` and its json is generated by `app/views/welcome/index.json.jbuilder`. Basically vanilla rails but the rendering is done as a react component.

Using rails 7 at work and we’re building new features with Hotwire and sprinkles of stimulusjs. So far so good. Happy and productive as promised.

As is so often the case, there's a lack of actual engineering in software "engineering". SPAs may be faster to develop and more performant or they may not. But simply declaring it to be so is not engineering. Extensive time is needed to make that determination and it must be based on an objective analysis of collected data.

SPAs faster to develop? We might live in different universes.

This mostly applies in cases where the developer doesn't have good experience with SSR.

Coming from React + Phoenix, adopting Phoenix Live View has been a big productivity win for my team as we are all full-stack developers.

Interesting. I gather you migrated a React App? Did you somehow find that there was nothing a full-JS client SPA could do that Live View couldn't? Did you have to make any compromises or any downgrades in the UX?

If you do everything with SSR and only use form submissions on the front-end, then you can get 0% front-end JS with most stacks.

Yeah, but these new libraries are nice for the use case where you want to add something like an upvote button or inline comments, where otherwise you'd have to spin up an API endpoint and write some JS.

Don't fear the JS

Out of curiosity, what do you use?

React but doing MPA, with routing on the server. Keeping it simple.