Option to use Turbo to avoid page refreshes
donovanglover opened this issue · comments
Feature Request
Summary
Turbo is a JavaScript library that turns static websites into interactive SPA-like ones.
Motivation
The website will be perceived to load faster for users since a page refresh isn't necessary.
Detailed Description
- Add the turbo script to
<head> - Progress bar color based on
var(--primary-color) - (Optional) Use Custom Rendering since the header/footer is the same on all pages
- (Optional) Config value to let users change setProgressBarDelay
- (Optional) Add option to let users preload the most important pages
Additional Context
The Turbo website uses Turbo.
@welpo Would love to work on this if you don't mind. One of the main challenges would be making existing scripts work on page change.
Hey Donovan,
I'm generally against adding JavaScript to tabi. Exceptions have been made for features that would be impossible without it (like the light/dark switch or comments).
I'm not totally against Turbo, but I would need more info and time to tinker with this on my own.
My first question would be about its implementation: would loading a .js on all pages be enough? Or is more setup required?
Totally understandable! I implemented turbo support in my own branch that works for my use case.
For scripts that depend on the DOM, you'd have to use turbo:load instead.
If I understand correctly, scripts that depend on the DOM would need a dual implementation to be compatible with Turbo. Essentially, one version using standard events for when turbo = off, and another that triggers on turbo:load for Turbo compatibility, right? (I'm against the idea of loading the turbo code for non-turbo users.)
My top priority is keeping the codebase and development process as simple, lightweight, and JS-free as possible. From my understanding, integrating Turbo would require maintaining 4 files for any DOM-dependent JavaScript: one version using standard events, another triggering on the turbo:load event, and their respective minified versions.
The minor improvements from Turbo may not outweigh the drawbacks, as I see it.
I might reconsider this if Zola brings in the capability to support non-HTML templates. @Jieiku, do you happen to have the link to the Zola issue where this was being discussed? I can't find it, and I remember you commented there.
In any case, for now, I'd prefer to keep things as they are.
Thank you for your understanding and your contributions.
I have found more than a few use cases for being able to template javascript files.
I don't have time to work on it right now. My initial attempt found some gotchas... like generating integrity hashes for js files that need to also be built via templates... I could tell it was going to take more time to implement and had to wait on it. Just started a big project at work, so won't have time for new features in abridge or adding this feature to Zola anytime soon.
https://github.com/Jieiku/zola/tree/file-templates
getzola/zola@995a0d3 (work in progress, never finished it, worked if subresource integrity hashes were not generated, also there's some hardcoded file paths here that I was using during testing.)
That was the issue I was thinking of, thanks!
No pressure at all, I was just looking for the discussion :)
By the way, @donovanglover, you'll need to update the .min.js files if you want to add turbo to tabi. The regular .js files are just there for reference, but are never loaded.
I did the minimal changes necessary to make turbo work on my site (including change .min.js to .js) to make it easy to rebase.
Ultimately I'm interested in trying bun to see if I can get a cool turbo setup that works for my use case. Very different than the goals in tabi, so I plan to keep it in my fork.