1. 43

hey lobsters, i wanted to show you all fixi.js, a minimal take on generalized hypermedia controls. I am the creator of htmx[0] and the author of “Hypermedia Controls: Feral to Formal”[1], and, inspired by Niklaus Wirth’s paper “A Plea for Lean Software”[2] I wanted to create an implementation of generalized hypermedia controls that was as lean as possible while still being useful.

Here are some more details on the project’s minimalism.

https://github.com/bigskysoftware/fixi#minimalism

One example of this minimalism is that the project consists of a total of three files: a README that serves as the docs, the js file and then an html file that serves as the tests.

Anyway, hope people find it interesting.

[0] - https://htmx.org

[1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127

[2] - https://github.com/lproven/plea_for_lean_software/blob/master/Niklaus%20Wirth%20-%20A%20Plea%20for%20Lean%20Software.pdf

  1.  

    1. 2

      I love how lean this is(the code is even quite readable!). As a far away admirer of htmx/hyperscript, I haven’t had the chance to use them for something yet, this has some neat stuff, particularly using fetch() and MutationObserver. Great design tradeoffs!

      I’m not entirely sure why/when somebody should use htmx over fixi.js. Or what are the options if somebody wants something with a mixture of the features of htmx and fixi.js. Is the idea that if you need anything more than that fixi.jsoffers, one should turn tohtmx`?

      I also wonder if this’ll start a trend of “build-less HTMX alternative frameworks”, which doesn’t need to be a bad thing, but it would be a bit ironic.

      1. 4

        Fixi uses dom transition that is not well supported yet (FF doesn’t support it so smooth element transitions will appear as sudden switches, which you might or might not care about), and drops some legacy browsers support. Other than this is just stripped down version of HTMX, AFAICT.

        1. 2

          Graceful degradation is a great feature of HTML

        2. 2

          htmx is much more fully featured, with things like history support, boosting, etc.

          fixi almost certainly requires a user to write some JavaScript to make it work the way you want in a real world situation, so if you are comfortable with that then it’ll be great, but a lot of folks just want that code to be written for them, in which case htmx is a better choice

          1. 1

            I also wonder if this’ll start a trend of “build-less HTMX alternative frameworks”, which doesn’t need to be a bad thing, but it would be a bit ironic.

            I think this would be fantastic. I love htmx, but sometimes I wish there were more “competitors” in the space exploring different designs (and of course as seen here, taking advantage of potentially new browser APIs). For me personally, htmx is like 80% great, 20% a bit awkward, so I’d love to see more exploration in case maybe an alternative might suit me more. Nice to see alpine-ajax, data-star etc. And of course more people using these types of “juiced-up html libraries” will bring bug fixes, smooth edges, etc.

            Of course maybe Fixi is what I’m looking for!

          2. 2

            Just because this is was too funny to not share: https://www.youtube.com/watch?v=3Y0emgKbCwc - the interview with Jason Cross, the real creator of Fixi

            1. 1

              A hard constraint on the project is that the unminified, uncompressed size must be less than that of the minified & compressed version of the (excellent) preact library (currently 4.6Kb).

              Is there a reason for this?

              1. 4

                I think it’s a good benchmark. When I see a library that’s a competitor to React and claims to be minimal, I compare them to Preact, in terms of bundle size, and they usually fail. To me, what’s the point of losing the declarative model and still not being as small as Preact?

                1. 1

                  I think its a good benchmark for minified/compressed code. Not so good of a benchmark for assessing unminified code however.

                  By size, Fixi is trying to fit into the equivalent of a single fully documented function of Preact’s, in terms of line count.

                  1. 5

                    fixi is in part designed to be plausibly run without either minification or compression, both of which require a fair amount of technical sophistication. Therefore I decided to use the minified & compressed version of Preact as an admittedly arbitrary benchmark for what “small enough” is.

                    at this point I’m very confident that the unminified & uncompressed version of fixi will be ~25% smaller than the minified & compressed version of preact, which I’m happy with. (This is not to denigrate the achievement preact, which is a great project and has a much more complicated task.)