Show HN: Swap.js – a JavaScript micro-framework (HTML fragments over the wire) (github.com)

How would you compare yourself to HTMX and Unpoly? I'm keenly interesting in this space for sure and love that you're working on another!

Impressive, especially considering the implementation size. Just by looking at swap.js file, I could not actually believe it really works but it clearly gets the job done.

I’m bought in to this approach after using Hotwire, but I’m concerned that all the competing implementations are going to undermine adoption. Maybe we should all just use htmx and call it a day.

Link handling needs to check keyboard modifier state, so that you don’t intercept things like Ctrl+click.

You can also work with just one event handler rather than many, which is generally easier, and more reliable if other scripts ever touch the DOM.

Here’s something you could replace the first register_links() call with (and drop the other register_links call and definition):

  addEventListener("click", event => {
      var link;
      if (
          !event.button &&
          !event.altKey &&
          !event.ctrlKey &&
          !event.metaKey &&
          !event.shiftKey &&
          (link = event.target.closest("[swap-target]"))
      ) {
          update(link.href, link.getAttribute('swap-target'), link.getAttribute('swap-history'));
          event.preventDefault();
      }
  });

Some other minuscule patches for size and/or performance (of things a minifier won’t do):

  -document.querySelector("html")
  +document.documentElement

  -window.addEventListener
  +addEventListener

  -'*[swap-target]'
  +'[swap-target]'

  -fallback = null
  +fallback

You can also simplify the code a tad by inlining function dom_changes and dom_load—though any minifier will do this for you, but I find it nicer having those functions inline to begin with. On style, I also wish for consistent single or double quotes rather than mixed.

The document.createElement('html') dance feels wrong. I feel like it should be using new DOMParser().parseFromString(). I’m not sure off the top of my head if it will matter, but it feels like you’re inviting mXSS attacks.

On update, you’re only applying body stuff, but you normally want to merge head changes in as well, especially document title.

You’re going to run into problems with replacing document.body.outerHTML. Browser extensions and other page JavaScript regularly rely on being able to inject their own stuff onto that element, and on a stable identity for the element, too much—so you’re going to break or be broken by various user extensions and other scripts that you load beside swap.js. Major UI libraries have sometimes started with working directly on document.body, but they’ve all ended up recommending that you mount them in a subelement instead, because otherwise too many things mysteriously break. I recommend getting away from this somehow, but I’m not sure quite how—it’d definitely add required complexity.

I’m not fond of how loading works: you rely upon this script being loaded blockingly, with customisation also blocking and after it. Some major uses of this script could otherwise be async and completely optional (progressive enhancement territory). Unfortunately, because of how you handle loaders, you can’t just switch to `document.readyState == "loading" ? addEventListener("DOMContentLoaded", dom_load) : dom_load()` to make it support <script async> usage, without losing functionality. You’d need to expose some other way of adding to Swap.loaders.

I'm getting a bit of deja vu from this recebt rediscovery of ajax but i really like it. Back when js was obscure and jQuery became ubiquitous, that practice was a go to and sites started to feel, albeit sluggish, like more and more like todays spa centric ecosystem.

Seeing projects spawn that the default that ssr was and making those early, simple optimisation tools much more streamlined, understandable, accessible and purely functional is great!

A new world: Part Three.

Oh nice, I am working on something similar, but didn't think of using MutationObserver for anything.

But be careful with hooking to links, there situations you want to test for that might need to work like a normal link (target blank or external url for example)

[dead]

This is much better than htmx. I like the focus on just swapping content

> vanilla JS (no external tool needed: no bundler, no webpack, no TypeScript compiler, no minification needed...)

Nice, I like that. I dread the modern way of having to jump through random hoops to get a garbled output that is supposed to contain my code as well. This is way more as I feel it is supposed to work: include a script tag.

Ah the good old element.innerHTML = xss_vector_here

Demo showing the library in action: https://afewthingz.com/swap-library/email/

PS: some music I made if you want a musical background:) https://afewthingz.com/since

I read through the swap.js file and there's a lot of things happening. I also like the fact that it has no dependencies and it's cool that it achieves so much with so little code.

I like it, but it feels funny to have this discussion without acknowledging this is really similar to pjax/turbolinks. Ok, now I'm feeling better; carry on!

Someone who used jQuery.load a lot back in the day, it's nice to see this trend coming back. Only thing that stands out to me is using custom properties without data prefix, e.g.

<a href="newpage.html" swap-target="#container" swap-history="true">Click me</a>

Shouldn't that be data-swap-target="#container" data-swap-history="true"? Is custom properties okay these days without data?

Wow. That is beautiful. So concise and yet easy to understand.

Feature request: documentation describing the accessibility impact this will have.

Any time I'm considering a library like this my number one question is always the impact it will have on accessibility tech, most specifically screenreaders.

I would love it if libraries could get into the habit of describing this impact in their documentation - and ideally if they could compete on providing the best possible accessibility as one of their promoted features.

Have you thought about adding polling functionality, so that a given element can check with the server for updates at a set interval?

    Swap.loaders[".my_view_with_polling"] = () => {
        update_task = setTimeout(do_polling, 1000);
        ...
        return () => {
            // unloader function when we quit this view
            clearTimeout(update_task);
        };
    };

I wrote something similar by myself for a PHP CMS project with server side templating.

My use case was progressive enhancement for pagination and filtering for lists, preserving all functionality with JS turned off, and using shareable "isomorphic" URLs.

It worked out pretty well, my headaches mostly stemmed from the backend and the "isomorphic" part: slight tendencies towarda overengineering and hard-to-fix bugs all stemmed from the backend ("ajax vs non-ajax", simply put).

Cool URIs don't change.

My two cents:

1. If there is a solution tailored to your backend, use it (unless it involves complex DSLs or many dependencies)

2. If not, write the code by yourself. It's not actually hard, most work is in the backend. Use "pushState" instead of "replaceState" only after everything is proved to work. Only push URLs, no data.

This is simple, low-hanging 2006ish JS. Don't use backend-agnostic cruft for this. It'll waste time.

It you need complex client-side interactivity as well as SSR and/or SSG, use a full-stack TS solution or an SPA with SSR.

I built something very similar ages ago with a short php script and a line in the .htaccess It’s cool to see these ideas coming back around.