Ask HN: Experiences w “JS-free” front ends? (Hotwire, Unpoly, Inertia.js, htmlx)

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.

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

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

Don't fear the JS

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.