As I mentioned in a previous post, Progressive Web Applications (PWA) are a new way to build responsive mobile websites allowing users to use their browser instead of native apps.
When you go this route, you get limited functionality as opposed to the full native experience.
Taken from Google's Progressive Web App page, here are some of the characteristics of a Progressive Web App:
- Progressive. Works for every user regardless of their browser.
- Responsive. The app works on any form factor whether it's desktop, mobile, or tablet.
- Connectivity-independent. Allows the user to use the web app even if it's offline.
- Native look and feel. Acts and feels like a native application, but is strictly web-based.
- Fresh. Always up-to-date with a service worker update process.
- Safe. Always served up to the client through HTTPS.
- Discoverable. Even though it's an "application," it can be indexed into a search engine.
- Re-engageable. Allows re-engagement through features like push notifications.
- Zero-deploy hassle. Allows users to add the web app to their home screen without having issues with app stores.
- Link-friendly. Allows you to reshare using a URL.
After looking over this list two or three times, I didn't see speed anywhere on this list to be considered a factor.
I guess it could be covered under the responsive characteristic, but from every Progressive Web App I've seen, a framework or library wasn't used when building a PWA.
Does this seem unusual?
No Angular, Backbone, Meteor, or React. Heck, not even jQuery.
Why not? I've got a theory.
One word: Size.
If you look at the Weather PWA from Google (which is also a project I converted into a Project Template), you'll notice there isn't any framework attached to it.
One Shell to Rule Them All
Again, if you notice the weather PWA, it only has one screen. Most full-featured native applications have at least two or more screens to be considered helpful and worthy of a download and a place on your smartphone's "desktop."
One of the recommendations from Google is to use a shell-based approach where the shell controls what components are loaded when, where, and how.
The hard part is moving from screen to screen.
One question always asked is how do you maintain state in your PWA?
This is why the shell-based approach is best when writing a PWA and managing state from screen to screen.
Why and Why Not?
Based on these arguments, here are some valid points as to why you should and should not use a library or framework.
Advantages of Using a Framework
- Existing shell. Some frameworks already provide you with an application shell giving you a more structured application right out of the box.
- Modular. A majority of frameworks provide modular loading when needed.
- State. The shell mentality gives users a way to maintain state across the pages.
Disadvantages of Using a Framework
Since Google considers the load time as one of its critical factors for ranking websites, I'm having a hard time justifying using a framework or library to build a PWA, but it would make things tremendously easier.
As I scrolled through the Getting Started with Progressive Web Apps on Google's site, I did notice a number of developers already created Progressive Web Applications with and without frameworks. Does this mean I'll use a framework? Maybe.
Of course, I'll run some tests to confirm if my app is small and fast enough to load for users. If I do use a framework, I will probably use Aurelia with Visual Studio and see if I can perform bundling and shrinking using the Task Runner.
Today, I gave some valid points whether developers should use a framework or library to build Progressive Web Applications.
It could mean the difference between position 2 and position 23 on Google's search results. (Hint: You want to be on page 1 instead of page 3.)
If you do decide to use a framework or library, post a comment below to let the community know that you're building a PWA using a framework. We all want to hear about it.
On my end, I will keep everybody up-to-date as to what I experience with writing a PWA with Aurelia.