These four primary cases are what I use for any content serving progressive web app I build today. Doesn’t matter the scale, if I’m building a PWA for someone, I consider these four cases the key to serving as many users and bots that I can (though in the case of #4 above, that might serve a different ES5 bundle based on what features I can patch).
Note: I said “content serving” because some PWA’s are offering more native app-like feature sets using things like WebUSB or WebBluetooth and the expectation that these should fallback the same way is not the same in my opinion.
In the case of blog-pwa, this takes place at both the server level (blog-pwa’s Google App Engine backend) and the client level (blog-pwa’s index.html shell). In most PWA buildouts in the last year or so, I always use server and client approaches.
In the case of server side, I check two cases:
- Are you a bot or tool in the known list?
- Are you a request with the url queryparam
staticset to true?
The second option works in conjunction with the blog-pwa’s index.html shell, which itself defines two cases to cause clients to redirect with static set to true based on enabled browser feature set:
- In the no ES Module support case, we use
location.hrefto handle the redirect.
This isn’t fancy or heavy engineering; this is just testing against features. No fancy user agent checking required.
With these cases and the static side setup, I’m able to safely say that the site renders in things like browsers like Lynx quite beautifully.
Even more crazy is that you still get a reasonably readable render in something like Internet Explorer 8.
Are there a lot of users viewing my site in these browsers? No. Does that mean I (or you) shouldn’t plan for this scenario? I’m of the opinion people should be able to read my content even on the most terrible of connections or browsers.
Should it all looks the same in every browser ever designed? No. A lot of folks might disagree, but the engineering effort to make that happen is significantly high and you better be doing some cost-benefit analysis before you jump into those waters. I’ve seen projects crash and burn and take down jobs. Don’t be that team.