Browsed by
Author: Alexandra Anghel

Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.
Freelancer Bundle with Our Most Popular PWA Themes

Freelancer Bundle with Our Most Popular PWA Themes

We have created a Freelancer Bundle with our most popular Progressive Web Apps. This bundle includes 5 app themes and 3 license keys that can be used on any domain name.

Here are the PWA themes included in the new bundle:

All these PWAs are build with AngularJS and the Ionic Framework (1.x). If you would like to take a “behind the scenes” look at a JavaScript / CSS source, you can check the Obliq v2.0 PWA on Github.

The apps connect to the WordPress Mobile Pack PRO plugin’s API to retrieve content, such as posts, categories and pages. Inside the plugin you will find the bundled applications, meaning the production ready JavaScript & CSS code (already merged and minified).

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.

Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.
New PWA Themes with React, Redux & Semantic UI

New PWA Themes with React, Redux & Semantic UI

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.

Here is the full new tech stack:

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.

Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.
Progressive Web Apps and Accelerated Mobile Pages – What is Holding WordPress Back?

Progressive Web Apps and Accelerated Mobile Pages – What is Holding WordPress Back?

Having been involved in building Progressive Web Apps from before they were even called Progressive Web Apps, we believe that everyone should use JavaScript to build amazing user experiences on the web. This has been our mantra in the last few years and we’re sticking to it :).

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).

In contrast, the PWA standard doesn’t impose a particular use of technology for implementing such an application. Most PWAs are built on JavaScript libraries / frameworks and are thus Single Page Applications (SPAs). It’s also possible to build Multiple Page Applications as PWAs, however the architecture is heavily customized. Here you can find a presentation from Google I/O 2018, describing the architecture of such a PWA implemented using a NodeJS / Express.js server and service workers. This can be even more intimidating compared to SPAs and it still requires writing JavaScript code, at least for the service worker.

So, what happens when we combine WordPress’ server-side rendering with a SPA? Well, we don’t – we have to make the choice between generating the HTML & CSS code on the server (server-side rendering) or letting the browser render that code (client-side rendering). In WordPress Mobile Pack, we use a special WordPress theme that loads only on mobile browsers. It strips down any WordPress code besides the bare minimum required to load the PWA assets (bundled JavaScript and CSS). It then becomes the responsibility of the browser to fetch the content (posts, pages, categories and so on) from WordPress’ REST API.

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.

The majority of these plugins rely on server-side rendering. They also insert additional JavaScript & CSS code and heavily depend on the page’s context to properly render a layout. Well, adding JavaScript code (like a widget) inside other JavaScript code (PWA) is a recipe for disaster. The embedded JavaScript code will not be executed because it’s not loaded directly in the browser.

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.

One caveat? They must reside on the root domain of your website – even if your WordPress install exists at, the service worker must be hosted directly on And they are JavaScript files. You might think “what’s the big deal, I’ll just copy the service worker file to my theme folder”. Well, as I already mentioned, WordPress uses server-side rendering, which makes it possible to load content from a theme folder even when in the browser you’re accessing the home page. But JavaScript files are different – their path is not changed when they are loaded by the browser. And, for very good reasons (think security!), a theme or plugin doesn’t have access to write files in the root folder of your WordPress installation.

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 lack of transparency when it comes to search engine optimization is one of the main reasons for the slow adoption of SPAs. Even though Google announced that its bots can crawl JavaScript code a few years back, this doesn’t change the fact that many people still look at their Google Webmasters Search Console and see all kinds of problems in there.

Some details surfaced last year, mainly the fact that the Googlebot uses Chrome 41 for rendering. Also, at this year’s Google I/O, we could take a sneak peak on how Google Search works and why SPAs are not as efficient as basic HTML/CSS websites when it comes to SEO. There was one very important insight that was shared:

“The rendering of JavaScript powered websites in Google Search is deferred until Googlebot has resources available to process to content.”

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.

Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.
Building Progressive Web Apps on Top of WordPress

Building Progressive Web Apps on Top of WordPress

At, 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
  • Load fast
  • 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:

  • UI/UX that mimics native apps
  • Increased engagement (sometimes 4X visits and time spent on sites)
  • Ability to use push notifications
  • Working reliably (less data, page loads due to caching and offline mode)
  • Increased conversions

How Can We Check If an App Is Progressive?

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?

Although JavaScript / Single Page Applications have been around for some time, the WordPress ecosystem has not always been ready for them. The REST API inclusion in the WordPress 4.5 core has finally opened the door for such apps which separate content from design. Simply out, the REST API allows the use of WordPress as the backend, while the frontend can become whatever we want.

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.

Also, according to the 2016 Stack Overflow developer survey, “JavaScript is the most commonly used programming language on earth”, for both frontend and backend development. In the last couple of years, the JS frameworks have exploded – both in number, but also in capabilities. Several JS frameworks and libraries – like AngularJS, React, Vue, Ionic, etc. – already provide the necessary tools for developing JavaScript apps quickly and efficiently.

I can only speculate, but I assume that the people behind WordPress have recognized this trend and decided to open the door for Javascript apps on top of WordPress.

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”?

Although the Google standard doesn’t impose a particular technology, the PWA features are best suited for Single Page Applications that are developed using JavaScript.

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.

In our WP Mobile Pack plugins (FREE and PRO) we use this approach because it allows us to load the PWA for mobile users while displaying the regular (responsive) theme for desktop users. The PWA is composed of JavaScript and CSS files and loads all the content from the API, in JSON format.

Loading PWA themes based on the browser’s user agent

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.
  • Build tasks
  • Coding standards
  • Unit and end-to-end tests

You can see this starter kit in action for our OBLIQ app theme, which is distributed with the FREE and PRO plugins. I should note that the WordPress plugins contain only the production files for each app theme, meaning a single JavaScript file and 2 CSS files (bundle and customizable stylesheet). The production files are generated using Gulp tasks, which can be found in each theme repository.

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 – 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.

However, the fact that RWD is now mainstream creates demand for innovation and diversification. At the end of the day, being mobile is not just about screen size, is it? The use of JavaScript components in RWD is not new – think about sliding menus, carousels or sliders. Yet, these are not enough to provide a full app-like experience.

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.



Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.