Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transform Almanac to a PWA #75

Open
AymenLoukil opened this issue Jul 5, 2019 · 10 comments
Open

Transform Almanac to a PWA #75

AymenLoukil opened this issue Jul 5, 2019 · 10 comments
Assignees
Labels
development Building the Almanac tech stack enhancement New feature or request performance Issues related to site performance question Further information is requested
Milestone

Comments

@AymenLoukil
Copy link
Contributor

It would be nice that Almanac website shupports PWA capabilities for performance and offline support..Etc. I'll make a try on it.

@AymenLoukil AymenLoukil added the development Building the Almanac tech stack label Jul 5, 2019
@AymenLoukil AymenLoukil self-assigned this Jul 5, 2019
@AymenLoukil
Copy link
Contributor Author

PL #76

@rviscomi rviscomi added this to the Infrastructure complete milestone Jul 8, 2019
@rviscomi
Copy link
Member

rviscomi commented Jul 8, 2019

Nice idea! I see you've already drafted a PR but I'd like to discuss the features you have in mind before committing anything to the codebase.

Being a mostly static website, I can definitely imagine offline support being an important feature. How do we ensure that all of the contents are preloaded and not just pages/resources users have already loaded? And how do we ensure that preload is done performantly?

Add to homescreen would be useful as well. I'm not sure that we need to prompt users to do this, though, as mobile browsers have native UI for that, right?

@rviscomi rviscomi added enhancement New feature or request question Further information is requested labels Jul 8, 2019
@rviscomi rviscomi mentioned this issue Jul 8, 2019
@AymenLoukil
Copy link
Contributor Author

Nice idea! I see you've already drafted a PR but I'd like to discuss the features you have in mind before committing anything to the codebase.

Ok :)

Being a mostly static website, I can definitely imagine offline support being an important feature. How do we ensure that all of the contents are preloaded and not just pages/resources users have already loaded? And how do we ensure that preload is done performantly?

The Service Worker will cache files and paths we precise. So no need to load the resources by the user for preloading/caching them. Another benefit of that, may be we will use a library for generating graphs (3d.js for example), we could also cache the JS files to improve to performance.

Add to homescreen would be useful as well. I'm not sure that we need to prompt users to do this, though, as mobile browsers have native UI for that, right?>

A2HS depends on the browser and is not always native. An UI element should be created / updated to show/hide the prompt.
Some infos : https://developers.google.com/web/fundamentals/app-install-banners/

@rviscomi
Copy link
Member

rviscomi commented Jul 9, 2019

Sounds good. Have you looked into using Workbox to generate the SW code? I'm not sure how that might work when we don't have static HTML files but @jeffposnick would be able to answer that.

Can we defer on A2HS for now?

@AymenLoukil
Copy link
Contributor Author

AymenLoukil commented Jul 10, 2019

Yeah i tried Workbox but it was a struggle to make it works on localhost. I added CSP then tried self host but didn't work...exceptions, errors, violations 😢

I'm not sure how that might work when we don't have static HTML files but @jeffposnick would be able to answer that.

SW will fetch the given routes and resources and cache them so we should be able to render them when "offline". Would also love to hear from @jeffposnick :)

Ok for A2HS.

@jeffposnick
Copy link
Contributor

In general, the ideal approach for adding in a service worker to a "content" site is to have the service worker mimic the templating/routing rules used during either the static generation or SSR (depending on whether the site is pre-generated or rendered on the fly).

There's more background in this "Beyond SPAs: alternative architectures for your PWA", and in particular, the "Worst Case Scenarios" section lists some gotchas/things to avoid.

While it's possible to just add in Workbox and get some level of offline support, like a custom offline page, that might not be worth the overhead.

I'm afraid that I'm not familiar with the architecture/CMS for the Almanac site. What is being used under the hood? The amount of work that it would take to have a clean Workbox integration varies a lot based on that 😄

@rviscomi
Copy link
Member

We use SSR. Here's the routing logic and templates, for example.

The main contents of the Almanac are the chapter pages, which we don't have yet (for obvious reasons) but they would be routed/rendered something like this:

  • user requests almanac.httparchive.org/2019/pwa
  • Flask figures it's a chapter page based on URL structure, looks up in a JSON config whether the 2019 Almanac has a chapter with the ID pwa
  • Flask renders the chapter template with the authored markdown and contributor info

@jeffposnick
Copy link
Contributor

Given that the routing logic is implemented in Python, it would be somewhat of a manual process to translate that into something that a JavaScript-based service worker could make use of. It doesn't seem like that would be too bad for the current set of rules, which are pretty straightforward, but I do worry about maintainability and things gtting out of sync when changes are made to the Python backend.

The templating end of things might be easier, though, as it looks similar enough to what Nunjucks supports. I've had decent luck doing that sort of templating inside of a service work for my personal blog (which uses 11ty as the static generation process, so there's no backend server to coordinate with).

@rviscomi rviscomi removed this from the Infrastructure complete milestone Oct 31, 2019
@rviscomi rviscomi added this to the Après Ski milestone Nov 8, 2019
@AymenLoukil AymenLoukil mentioned this issue Nov 19, 2019
27 tasks
@tunetheweb tunetheweb added the performance Issues related to site performance label Apr 12, 2020
@rviscomi rviscomi modified the milestones: 2019 Backlog, 2020 Backlog Nov 11, 2020
@rviscomi
Copy link
Member

rviscomi commented Apr 28, 2021

Going through old open issues. @tunetheweb I wonder if the challenges mentioned in #75 (comment) are less of an issue now that we're generating the sitemap, so we'd be able to enumerate all of the chapters at build-time. Is there still interest in adding PWA support? If not we can close this issue. cc @AymenLoukil

@tunetheweb
Copy link
Member

My vote is to close this. There's a few use cases for Service Workers:

Offline support. To me that's best served by the ebook PDF. That's 22MB per year so prefetching that level of content is a bit rude, and only having the chapters without the content is a bit meaningless. Of course we could just cache previously browsed content for the offline version (I really wish browsers would do this by default!) but question the value of that compared to ebook, and also need to handle images and sheets embeds.

Having an installable home screen icon. However with Chrome insisting on offline support to surface this and above complexities with offline not sure it's worth it. And IMHO it's a bit wishful thinking to think there's much demand for having our content as an app, compared to the complexity.

Potential Performance gains by having better control over the cache. However we've a very performant site as it is so not sure there's much to gain her for the complexity.

Just as a demo of some of the stuff in PWA chapter.. While I like using the site as a show case of some of the things we talk about in the Web Almanac, I don't think that's enough reason to do this.

I also personally think Service Workers are overly complex, difficult to support and you should have a good reason to use them. And not sure we do to be honest - especially as, unlike most sites, we have ebook versions of our content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Building the Almanac tech stack enhancement New feature or request performance Issues related to site performance question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants