If you would like to modify the Angular JS source code, you can use the Obliq PWA as a starter kit or purchase the code for any of the apps listed above.
As part of our effort to launch Progressive Web Apps based on new technologies, we are rebuilding some of our themes with a new tech stack: ReactJS, Redux and Semantic UI.
Our Base, Mosaic and Folio apps were among the first launched and are part of the popular Freelancer bundle. The original versions are based on Sencha Touch and we felt that we could greatly improve their performance by rebuilding them in React.
We have a 85% code coverage rate with unit tests and we’re working on improving this rate.
We are also integrating the apps with the new WordPress REST API. This means the WordPress Mobile Pack PRO plugin’s backend will be upgraded to support namespaces and custom API routes. The new plugin version will be available for WordPress 4.8+ running on PHP 5.4 and above.
The Base-React, Mosaic-React and Folio-React PWAs are already in the alpha stage and will fully replace the Sencha apps by the end of the year. If you are already using one of the Sencha apps, your WordPress Mobile Pack PRO plugin will be automatically upgraded to use the React versions.
If you would like to have early access to the new apps, you can also pre-order them now at a discounted price.
However, using Content Management Systems (and in particular WordPress) as backend / APIs has proven a challenge. This is mostly due to the clash between technologies (client vs. backend rendering) and the large ecosystem of plugins / themes that surround WordPress. The value of WordPress is not only its powerful core, but all those widgets that you can install and enhance the functionality of your WordPress site. Most of these are plug & play. At the same time, I have yet to see a plug & play PWA with a 100% score on Lighthouse. Wherever you see success stories (ex. Twitter app), they also involve a lot of custom work.
So, where does that leave us? We don’t pretend to have all the answers or a magic, silver bullet that can remodel your WordPress website into a 100% PWA. However, we believe that by taking a more detailed look at the technology behind WordPress, PWAs and AMP, we can come up with ideas on how to close the gap between them. Below, you’ll find a list of 5 key points that we believe should be addressed to get us moving in the right direction.
1. Server-side rendering vs. client-side rendering
WordPress themes & plugins use server-side rendering. If you’re not familiar with the differences between server-side and client-side rendering, you can read about it here. In short, WordPress themes / plugins need a server to run the code and produce an output (HTML & CSS code).
2. Limitations of the REST API
We strongly believe that the inclusion of the REST API in the core has opened the door for building amazing apps on top of WordPress. However, as it stands today, the functionality of the REST API is limited compared to all other things that you can do from the WordPress admin area. Just think for example about customizing the menu for your WordPress site. You can go to Appearances > Menus and do just that, your responsive theme will easily adapt to the changes.
Yet, there is no endpoint that can help export those settings to a PWA. The REST API functionality is limited to retrieving posts, pages, categories, etc. and some basic settings. So, a trivial task that is available to all responsive themes is cumbersome for a PWA. One solution is to extend the functionality of the REST API and create new endpoints (there is some work being done in that direction here). This doesn’t change the fact that we’ll have to jump through some hoops to integrate our PWAs with basic WordPress features.
3. Page Builders & Widgets
Who doesn’t love an easy-to-use page builder? These plugins promise to make our lives easier and just by using drag-and-drop we can make our website look the way we want. It’s no wonder their popularity is increasing.
Not to mention that the REST API doesn’t even export some of the shortcode used by page builders – which is normal because that shortcode doesn’t make sense outside of a responsive theme’s context.
4. Service workers support
Service workers are a big part of implementing a PWA. They help provide all that fancy stuff – like caching / offline mode, add to homescreen and web push notifications.
So, what we can do? Well, we can manually copy the service worker file using FTP. But I do hope that WordPress comes up with a better solution in the future. I don’t want to be stuck forever copying my service worker whenever WordPress code is updated.
5. Lack of transparency on how SEO works for SPAs
The recommended solution is to do server-side rendering only for bots, which if you ask me, sounds like a hassle because we end up maintaining two different versions of the same content. I do hope there’s a better solution in the making, because this one doesn’t sound good at all.
The good part about all of this is that Google is definitely making steps into closing the gap between its technologies and WordPress. There was another interesting presentation at Google I/O that you should definitely watch: “Make your WordPress site progressive“. The approach is very interesting – using AMP and the Gutenberg editor to build WordPress websites. It looks like the WP AMP plugin is getting a lot of love recently and there are some very cool use cases that can be built on top of it.
Even though there is no silver bullet for solving the issues I have mentioned in this article, I do hope we’ll see many more cool PWAs being built on top of WordPress, taking advantage of the CMS’s popularity and versatility.
At WPMobilePack.com, we have been building Progressive Web Apps (previously called Mobile Web Apps) before they were standardized by Google. It’s not an easy road, especially when working with a Content Management System that: 1) was not created for handling these types of applications and 2) is used by 30% of the entire web, spanning incredibly diverse websites from all categories: bloggers, e-commerce, restaurants, hotels, brochure websites and many more.
Progressive Web Apps (PWAs) most certainly scratch some itches and bring a lot of benefits, if they are developed and deployed in an effective manner. A lot of businesses have shied away from investing in native mobile applications because they are expensive, take a long time to develop and are a pain to distribute. PWAs offer us a similar user experience, without the hassle of going through App Stores.
This article is about why and how we developed a series of Progressive Web Apps that can be used on top of WordPress.
What Exactly Are Progressive Web Apps?
Google has defined Progressive Web Apps as “A new way to deliver amazing user experiences on the web” and has thoroughly documented them. We like to call them “apps that work within the browser“.
According to the standard, PWA should be reliable, fast and engaging. In other words, they should provide a full “app-like” user experience without the hassle of installing them. A desktop web application can also have progressive features, but the PWA checklist is geared towards mobile and includes items such as “Add to Home Screen” and offline mode.
Don’t be scared by the lengthy documentation. PWA has a series of baseline characteristics that should be followed closely to achieve “progressiveness”, but does not impose that all of these should be developed at the same time, nor does it say how they should be developed.
To become progressive, an app has to:
Be secure (HTTPS)
Be responsive on tablets & mobile devices
Use “Add to Home Screen” prompts
Be cross-browser (Chrome, Edge, Firefox and Safari)
The start URL (at least) should load while offline
Use a separate URL for each page
Compared to mobile friendly or responsive websites, a Progressive Web App brings a series of advantages, such as:
Google has also developed a Chrome extension called “Lighthouse”, that enables us to check if a particular website is progressive. It’s pretty obvious that “progressiveness” is a score, not a yes or no.
In a similar manner to Google’s Page Speed Insights, Lighthouse generates a report with the main characteristics. It is telling us what exactly what we need to modify in order for the app to become progressive.
Why Use Progressive Web Apps Now?
Even if the REST API’s reputation has greatly suffered after the discovery of a severe vulnerability, there is no going back. The previous WordPress APIs (like XMLRPC) are a bad joke that have been affected by vulnerabilities of their own, so the REST API is here to stay.
The “appification of the web” movement is supported by Google, not only by its PWA standard but by other means as well. Google is already pushing the Android Instant Apps project, that will allow us to preview an application without installing it. The technology behind Android Instant Apps is not the same, but it is obvious that the lines between “native” and “web” apps are fading.
To complete the circle, Google is also preparing to launch .app domains, after purchasing the Top Level Domain rights for a record sum of $25 million in 2015.
Why Do We Call Them “Apps” Instead of “Websites”?
RWD uses server-side rendering, meaning that PHP is responsible for generating the HTML code of the page. JS apps use client-side rendering. The JS code is communicating with the server and rendering the HTML code, which can create a smooth user experience because the content loading is done “behind the scenes”.
Since the server is not needed for generating HTML code, we can cache a JS app together with its content, thus producing faster apps that can work offline.
How We Use PWAs in WP Mobile Pack – Responsive vs. Adaptive
We’ve talked about PWA features, so we should clarify what is the technology that allows us to use a PWA together with WordPress.
You’re probably familiar with the way responsive themes work. They have a series of .php files that are responsible for displaying the content and also adding the necessary resources (like the stylesheet) in the HTML page. Responsive themes load the same resources for desktop and mobile users, so they are device agnostic.
If we want to load different files for desktop and mobile users, the server needs to detect the device by using the browser’s user agent. This technique is called adaptive or dynamic serving. Although it’s much less common compared to RWD, it is one of the mobile SEO strategies recognized by Google.
How We Build Progressive Web App Themes
After several apps built, we have developed our own starter kit with AngularJS and Ionic 1, which allows us to build new app themes quickly and efficiently. This starter kit includes:
Documentation on how to set up the working environment
Guidelines for the files & folders structure
Guidelines for structuring the stylesheet
Several modules that are common for all apps, for example communicating with the API, translating texts from the app, etc.
Unit and end-to-end tests
Our roadmap includes developing new app extensions such as offline mode, push notifications and a new starter kit for building React applications.
In a web dominated by Responsive Web Design – 70% of mobile friendly websites are responsive (as we wrote in a study featured on SmashingMagazine.com) – we are often asked why we believe PWAs are necessary. After all, they are more difficult to develop. Also, the concept behind responsive – using a fluid and flexible design that is device agnostic – is particularly attractive because we have to maintain a single code base.
We see PWAs as being used first where conversions and engagement matter most – like in the publishing and e-commerce industries. If you’re a WordPress developer and want to offer your customers an app solution, you’re more than welcome to start with the free OBLIQ app theme, customize it to fit your needs and let us know about it – we’d be more than happy to include some of your contributions into the main repository for other developers in the community to use.