Potential Supported Integrations

This is a post to talk about possible integrations with WordPress. Right now we have in mind these:

The JS injector

This is what we have used until now to inject only the mobile version while keeping the desktop version intact. It works, but it’s not ideal because it uses a document.write to override all the HTML of the WordPress version. It doesn’t make sense if the users want to use Frontity for both their desktop and mobile versions.

Pros:

  • It works just by installing the WP plugin.
  • It may be useful for previewing how Frontity works without changing your theme.
  • Users don’t need to move their WP to a new domain.

Cons:

  • It uses a document.write to override all the HTML of the WordPress version.
  • It doesn’t make sense if the users want to use Frontity for both their desktop and mobile versions.
  • A Frontity server is needed.

PHP Theme Bridge

This is a PHP theme that doesn’t generate any HTML. Instead, it does an HTTP call to the Frontity server to retrieve the HTML and outputs that.

Pros:

  • Users don’t need to change their domain.
  • The cache can be done with WP plugins, which know when to invalidate it intelligently.

Cons:

  • There is more routing involved (it goes to WP, then Frontity, then WP outputs the HTML)
  • Users must use a cache plugin or it will be very slow.
  • A Frontity server is needed.

Direct to Frontity

This means users use a different domain for WP, for example. wp.myblog.com and their main domain points to a Frontity server: www.myblog.com.

Pros:

  • Perfect fit for people with free WP.com blogs (myname.wordpress.com)
  • Fastest server side rendering (no useless WP request needed).

Cons:

  • Users need to change their WP domain.
  • The server side rendering is still slow if the WP is slow, so it may need a cache layer on top.
  • A Frontity server is needed.

React-only PHP theme:

This is a PHP theme generated by a Frontity command that renders an empty HTML that only contains the scripts to React. It’s basically a single page application.

Pros:

  • No cache is needed.
  • No Frontity server is needed.
  • Users don’t need to move their WP to a new domain.

Cons:

  • It doesn’t have server side rendering:
    • No HTML: bad for SEO.
    • Bad for First meaningful paint of Lighthouse (bad for SEO as well).
    • Readers don’t see anything until React has finished loading: bad user experience.
    • The first React load is slower because it needs to do all the API calls.

Static Rendered HTML:

This means users create an HTML file for each possible route at building time. It’s like Gatsby or Next export.

Pros:

  • No Frontity server is needed.
  • No cache is needed.
  • Server-side rendering is done at building time, so it is like “instant”.

Cons:

  • You need to generate a new build each time you publish or edit content.
  • A static HTML server is needed (but it’s cheaper than a Frontity server).
  • Users need to move their WP to a different domain.
  • Not useful for big blogs with thousands of posts.
  • Not useful for blogs that update content frequently.

Static HTML PHP Theme

This is a PHP theme generated by a Frontity command but instead of rendering an empty HTML it includes an HTML file for each possible route.

Pros:

  • Users don’t need to change their WP domain.
  • A Frontity server is not needed.
  • A static HTML server is not needed.
  • No cache is needed.

Cons:

  • You need to generate a new build each time you publish or edit content and update your theme.
  • Not useful for big blogs with thousands of posts.
  • Not useful for blogs that update content frequently.

Right now we think we should launch the v1.0 with both the Direct to Frontity and PHP theme bridge integrations.

Direct to Frontity is the best solution for serious blogs. It requires more configuration and moving your WP domain, but for advanced developers, this is not a problem.

PHP theme bridge is the easiest solution so it’s the best one for non-tech savvy WordPress users.

But, we need to make sure that both the PHP build-time creating and the HTML static export won’t be difficult to implement in the future.

2 Likes

Hey @luisherranz I want to refloat this thread as we are about to launch the beta.

I know that our first integration method will be the Direct to Frontity , and I wanted to ask you if you already know what are going to be the next supported methods. Maybe we can turn this thread into a poll, and see what users demand? :blush: