Show HN: We built swup+fragment-plugin to visually enhance classic websites(swup-fragment-plugin.netlify.app)
swup-fragment-plugin.netlify.app
Show HN: We built swup+fragment-plugin to visually enhance classic websites
https://swup-fragment-plugin.netlify.app/
15 comments
Took me a while to understand, maybe some images are required..
e.g. "Instead of [screenshot of Characters page in a browser window] -> text: click a character -> [screenshot of the blank browser window with caption "navigation, full page fetch and rendering"]-> [screenshot of a character modal in a browser window]
You get: [screenshot of Characters page in a browser window] -> text: click a character -> [screenshot of a character modal in browser window with caption: Swup/Fragment Plugin handles the loading and rendering of the modal, making your website an SPA]"
e.g. "Instead of [screenshot of Characters page in a browser window] -> text: click a character -> [screenshot of the blank browser window with caption "navigation, full page fetch and rendering"]-> [screenshot of a character modal in a browser window]
You get: [screenshot of Characters page in a browser window] -> text: click a character -> [screenshot of a character modal in browser window with caption: Swup/Fragment Plugin handles the loading and rendering of the modal, making your website an SPA]"
Do you mean screenshots on the front page of the demo site, to explain the behavior more clearly?
Yes.. tbh I just skimmed through the text without parsing it, maybe my brain saw "versatile and extensible" and said "This is just marketing blah blah...".
Oh, interesting to hear that feedback. We actually changed the slogan just recently with the new major version of swup, because it became much more versatile and extensible than in previous versions ;)
Interesting! I’ve been using Swup for the past three years in my core Wordpress theme, and am quite happy with it. It takes some getting used to (like with how third party scripts will take some special care, since a JS page replace doesn’t always trigger script load events), but once you know the basics, it’s a powerful and neat tool to speed up a website that has a CMS.
The one thing I’m looking forward to in v4 is more advanced hooks, so I can do “fade into eachother” animations. Right now content is replaced in the same container, but it would be real cool if we could have the from and to page exist together during the transition.
The one thing I’m looking forward to in v4 is more advanced hooks, so I can do “fade into eachother” animations. Right now content is replaced in the same container, but it would be real cool if we could have the from and to page exist together during the transition.
Swup maintainer here. There is official support for parallel animations in swup v4: https://github.com/swup/parallel-plugin — we've been holding off on this for a while because of accessibility issues and some technical complexity around animating those. But we're very happy to have a first-party solution for this now: some UI interactions just make much more sense when still having the previous content around.
Is this a modern day pjax/turbolinks? It feels that way from the reading of swup.
Looks more like Turbo than Turbolinks
When I was researching it, hotwire/turbo looked more like in between of page transition libraries and tools like htmx or Unpoly. There were some issues with the history IIRC, that‘s one reason I didn‘t start using it.
Yes it is. But the fragment support and focus on accessibility is something that was never cleanly solvable with these tools as far as I know.
Started web dev five years prior but went through the same trajectory in the 00s. This is rather clever and reminds me of ajax. The a11y focus is great, definitely modernizes this. I don't think the script kiddies these days are going to appreciate this as much though.
Great to hear that you like it! Regarding the "script kiddies": We all started out like that and made our mistakes along the way, didn't we? For now it's enough for me if people with appreciation for web standards and accessibility find this and start using it in real-world projects. That will make the tool more robust and future-proof. And who knows, maybe it holds out long enough in it's little niche until the kids are grown?!
I'd be happy if anyone who likes it gives it a star on GitHub. That's how things get traction nowadays, I heard ;)
https://github.com/swup/fragment-plugin
I'd be happy if anyone who likes it gives it a star on GitHub. That's how things get traction nowadays, I heard ;)
https://github.com/swup/fragment-plugin
This is the opposite of what I want the web to be.
Hello aendruk! I guess you are referring to the animations? That's a matter of taste of course, and I took it to the extreme for the demo, to show what's possible. It's of course very questionable if this would be a good idea for every last website, but there are use cases where it can make sense (portfolio sites, for example)
You write this as if this is a Google-authored spec being shoehorned into W3C.
Most websites aren't going to use something like this. HN readers however may appreciate having the option and may put some thought into how this could be used well.
Most websites aren't going to use something like this. HN readers however may appreciate having the option and may put some thought into how this could be used well.
- 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 thing I was still missing to be a happy developer was the ability to create really complex navigation paths where selected fragments are updated as you navigate a site, much like nested routes allow in React or Vue.
The last two months I teamed up with @daun [2] to finally solve this hard problem. The result is two things:
1. A new major release of swup (v4) that allows customizing the complete page transition process by providing a powerful hook system and a mutable visit object 2. The newly released fragment-plugin [3] that provides a declarative API for dynamically replacing containers based on rules
Use cases for the fragment-plugin are:
- a filter UI that live-updates its list of results on every interaction
- a detail overlay that shows on top of the currently open content
- a tab group that updates only itself when selecting one of the tabs
- a form that updates only itself upon submission
I can now finally build websites that tick all three boxes:
1. Visually impressive, fun, and snappy by using swup's first-class support for animations[4], cache[5], and preload capacities[6], enhanced with fragment visits as seen on the demo site.
2. Accessible by being able to serve server-rendered semantic markup that will fully work even with JavaScript disabled (try it out on the demo site!). On top of that, swup's a11y plugin[7] will automatically announce page visits to assistive technologies and will focus the new `<main>` element after each visit.
3. Because now all I need for my fancy frontend is a bit of progressive JavaScript, I can choose whatever tool I like on the server, keeping complexity low and maintainability high. I can use SSGs like eleventy or Astro (the demo site is built using Astro!), I can use any CMS like WordPress or ProcessWire, or a framework like Laravel. And I don't have to maintain an additional node server for SSG!
The plugin is still in it's early stages, but I have a good feeling that this finally is the right path for me as a web developer. All it took was 20 years! ;)
[0] https://github.com/swup/swup
[1] https://swup.js.org/plugins
[2] https://github.com/daun
[3] https://github.com/swup/fragment-plugin
[4] https://swup.js.org/getting-started/how-it-works/
[5] https://swup.js.org/api/cache/
[6] https://swup.js.org/plugins/preload-plugin/
[7] https://swup.js.org/plugins/a11y-plugin/