Show HN: We built swup+fragment-plugin to visually enhance classic websites (swup-fragment-plugin.netlify.app)

- Progressively enhance your classic website / MPA to a single page app.

- Support for fragment visits, comparable to nested routes in React or Vue.

- Keep your site crawlable and indexable without any of the overhead of SSR.

- No tight coupling of back- and frontend. Use the CMS / Framework / SSG of your choice.

- Strong focus on interoperability with DOM-altering JS tools (think Alpine.js, jQuery, ...).

- Strong focus on accessibility, even for fragment visits.

## Long Version: Best of three worlds

Hi, I'm Rasso Hilber. I have been a web designer and developer since around 2004. From the beginning of my career, I always had to make tradeoffs between 3 goals when building websites:

1. The websites I build should be visually impressive, original, and snappy.

2. The websites I build should be crawlable, accessible and standards compliant.

3. The websites I build should have low technical complexity and be easy to maintain in the long run.

In the beginning, I was able to achieve goals 1 (impressive!) and 3 (easy to maintain!) by using Macromedia/Adobe Flash, but due to the nature of the technology horribly failed to deliver crawlable and accessible websites. Later, I found a way to run two sites in parallel for each website I built, one using CMS-generated XHTML for crawlability, one in Flash for the visitors, fetching the data from its XHTML twin. Now I had solved goals 1 and 2, but my setup was awfully complex and brittle.

Around 2010, I was relieved to see Flash finally coming to its end. I switched to building websites using PHP, HTML, and jQuery. I could now tick goals 2 (accessibility) and 3 (low complexity), but the websites I was able to build using these technologies weren't as impressive anymore. Hard page loads between every link click being one of the biggest regressions in UX from the days of Flash IMO.

Around 2014/15, I first heard about the new frameworks: Angular, React, Vue. These frameworks were not intended to be used for classic websites. They were made for single-page-apps! But it felt to me like no one cared. Even when building classic websites, many developers sacrificed SEO and accessibility for a snappy experience, serving an empty `<div id="app"></div>` to the browser. I couldn't blame them; I had done the same in my early days as a Flash developer. They ticked goal 1 (impressive) and goal 3 (low complexity). But the lack of accessibility kept me from joining the movement. I was still building classic websites, after all.

After some time, many started realizing that serving an empty div had downsides – SSR, hydration, and whatnot were born, now ticking goal 1 (impressive) and goal 2 (accessibility), with the trade-off of awful complexity. It reminded me a lot of my little Frankenstein's monster "Flash+XHTML," and I still didn't want to join the hype.

Still, because the noise was so loud, I felt like I might be becoming obsolete, an "old man yelling at the clouds".

New very interesting tools like HTMX or Unpoly popped up that looked promising at first, but at closer inspection weren't optimized for my use case either. These were primarily built for real interfaces/single-page-apps (html snippets instead of full pages, UI state independent of URLs, altered DOM saved in history snapshots, ...). I wanted to find a tiny tool, optimized for building presentational, content-driven websites with a strong focus on accessibility.

Instead, after a few years of rolling my own home-grown solutions, I started using swup[0], a "Versatile and extensible page transition library for server-rendered websites". Swup consists of a tiny core and a rich ecosystem of official plugins[1] for additional functionality. It was hitting the sweet spot between simplicity and complexity, and felt like it was perfect for my use cases. Shortly after I had started using it, I became a core contributor and maintainer of swup.

The only thin...