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

31 points | by lambdaba 215 days ago

17 comments

  • bob1029 215 days 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.

  • SahAssar 214 days 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.
    • recursivedoubts 213 days 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.

    • josefdlange 214 days 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.

      • SahAssar 214 days 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.
        • simantel 214 days ago
          HTMX doesn't include the whole DSL - the example above is using Hyperscript, which is a separate project by the creators of HTMX.
    • ale_jacques 214 days 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.

  • ale_jacques 215 days 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.

    • midrus 213 days ago
      Unpoly rocks. Far better and more conplete than Htmx. Sadly not as good at marketing.
      • recursivedoubts 212 days 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.

        • midrus 212 days ago
          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
          • recursivedoubts 212 days ago
            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.
  • josefdlange 214 days 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.

  • vincent_s 215 days 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

    • midrus 213 days ago
      I'm curious about this. Can you share any specific problem you had and couldn't find a solution for?
      • vincent_s 212 days 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.

        • midrus 212 days ago
          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".

    • lambdaba 215 days 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_s 215 days 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.
  • banoo 215 days ago
    Am I missing something? All of the OP’s listed software depend on JavaScript. How is that “JS-free”?
    • lambdaba 215 days 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
    • midrus 213 days ago
      I think the idea is to avoid to write the JavaScript yourself, not that you don't use it under the hood.
    • ale_jacques 215 days ago
      The author mentioned "as little (or no)".
  • db579 215 days ago
    Experience with Rails and Hotwire has been very positive so far.
  • pjerem 214 days 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.

  • steveryan6989 215 days 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.
  • oh_boy 214 days 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 213 days 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.

  • bjacobso 214 days 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.
  • janglezz 215 days 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.
  • 0x445442 215 days 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.
    • midrus 213 days ago
      SPAs faster to develop? We might live in different universes.
      • hackerfromthefu 201 days ago
        This mostly applies in cases where the developer doesn't have good experience with SSR.
  • connorlay 214 days 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.
    • lambdaba 214 days 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?
  • codingclaws 214 days 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.
    • simantel 214 days 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.
  • jsyolo 214 days ago
    Don't fear the JS
    • lambdaba 214 days ago
      Out of curiosity, what do you use?
      • jsyolo 214 days ago
        React but doing MPA, with routing on the server. Keeping it simple.