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

https://news.ycombinator.com/item?id=29934191

by lambdaba • 5 years ago

31 40 5 years ago

news.ycombinator.com

I'm intrigued by solutions to build interactive frontends using as little (or no) JS possible.

I've read from people here saying they had great productivity gains and simplicity using these options.

There are many options though with quite a bit of differences and I wanted to hear from people who have evaluated some of them and what they settled on.

ale_jacques3• 5 years ago

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.

midrus6• 5 years ago

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

recursivedoubts3• 5 years ago

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.

vincent_s3• 5 years ago

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

lambdaba4• 5 years ago

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

vincent_s3• 5 years ago

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.

midrus6• 5 years ago

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

vincent_s3• 5 years ago

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.

0x445442• 5 years ago

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.

midrus6• 5 years ago

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

hackerfromthefu• 4 years ago

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

db579• 5 years ago

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

banoo• 5 years ago

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

lambdaba4• 5 years ago

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

ale_jacques3• 5 years ago

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

midrus6• 5 years ago

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

bob1029• 5 years ago

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.

steveryan6989• 5 years ago

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.

janglezz• 5 years ago

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.

connorlay• 5 years ago

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

lambdaba4• 5 years ago

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?

bjacobso• 5 years ago

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.

SahAssar2• 5 years ago

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.

josefdlange2• 5 years ago

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.

SahAssar2• 5 years ago

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.

ale_jacques3• 5 years ago

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.

recursivedoubts3• 5 years ago

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.

josefdlange2• 5 years ago

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.

codingclaws• 5 years ago

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.

simantel2• 5 years ago

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.

pjerem• 5 years ago

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.

jsyolo2• 5 years ago

Don't fear the JS

lambdaba4• 5 years ago

Out of curiosity, what do you use?

jsyolo2• 5 years ago

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

oh_boy• 5 years ago

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.

cmclaughlin• 5 years ago

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.

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

Related Stories