Tl;dr: using JAMstack, Storipress can deliver to Enterprise a better performing solution that would otherwise cost $10,000+/m in hosting and staffing costs for $50/m.

What is JAMstack?

Before we proceed with how Storipress implements the JAMstack, we first have to understand what it is.

Illustration of the JAMstack

JAMstack is a handy abbreviation coined by Mathias Biilmann, the CEO of Netlify, and it stands for JavaScript, APIs, and Markup. But what it refers to today (or what it means) is much more than what it stands for.

Today Jamstack refers to a web development architecture:

  • Decoupled: The front end uses different tooling from the back end, and is usually build with a static site generator. The backend is then connected to the frontend through the use of APIs used during the build process. Server side processes are decoupled and lightly sprinkled on a page and powered through serverless functions.

  • Static-first: While various practices exist for introducing dynamic elements to Jamstack sites, most are pre-rendered, which means the front end was built and compiled into HTML, CSS, and JavaScript files.

  • Progressively enhanced: JavaScript can be introduced to pre-rendered sites on an as-needed basis, thus increasing performance in the browser.

Most JAMstack sites achieve this paradigm through the use of a static site generator which is a tool that generates a full static HTML website based on raw data and a set of javascript templates. This automates the task of coding individual HTML pages and gets those pages ready to serve to users ahead of time.

Illustration of the JAMstack process

Illustration of the JAMstack process

By building sites in this way, you get sites that are blazing fast, near impossible to hack, far less expensive to host and scale, and have better DX due to being able to use your favourite JS framework.

On top of this, through extreme optimisation, Storipress' pages are approximately ⅓ the size of the web pages of other major news orgs. This page weighs in at around 1mb, whereas a comparable page on the New York Times would weigh in at 3mb, or over 300% larger. This means that in delivering our customer's content, not only are we not required to manage and scale databases and servers based on site load, file transfer costs are also 3x less, allowing us to deliver elite performance for 50% of the cost.

There is also the human aspect. As a no-code platform, customers also save significant money on implementation and ongoing maintenance costs, meaning that when taken holistically, Storipress can deliver experiences which were only reserved for enterprise in the past for less than 10% of the cost.

Not convinced? Have a click around on this blog and experience how fast the JAMstack can be.

Problems with the JAMStack

Sounds great right? However, these benefits also come at a cost.

  • Updates are really slow: Unlike dynamic sites which builds content on the fly, with the JAMstack, every time a change is made, your site is re-built from scratch. This problem is exasperated if your site has lots of large media files as on every rebuild, your static site generator re-optimises these media files. This means that as your site gets bigger, each build can take upwards of 30 minutes to complete and get your new content live.

  • Not easy to customise (for non-developers): Whilst JAMstack gives you unlimited customisation, the lack of prebuilt templates means it can take you a while to get started. Many static site generators do not come with templates, and developers will have to spend a lot of time building them from scratch at first.

  • No user-friendly interface: Following the above theme, it is harder for non-developer users to publish content using a static site generator. There is no CMS interface, and writing in markup may be intimidating for users. In addition, developer support is often necessary for making website updates.

Hence, the current state of JAMstack tooling is just not suitable for publishers who are often not technical, and who require quick site updates.

How Storipress Fixes these Problems

  • Lightning Fast Updates: Storipress offloads all your media assets to our specialised media CDN. Our CDN then resizes and converts your media assets to WebP in the background, without affecting build speeds. This solution means our builds can stay in the 1-3 minute mark consistently, but in future, we can improve this even further with incremental builds (something we're working on right now!)

  • Endless Customisability: Don't know how to code? No problem. Storipress' block editor allows you to 'stack' predesigned broadsheet designs on top of each other without code, allowing you to design your publication as you see fit.

  • A User Interface for Publishers: Storipress addresses the issue of usability by being possibly the most usable content focused CMS, even whilst being based on the JAMstack. With an average System Usability Scale score of 83, Storipress is significantly easier to use than WordPress (which scores a measly 50). This gap is made worse when taking into account the SUS is a logarithmic scale, meaning Storipress literally jumps leaps and bounds over WordPress.

However, even with these initial problems out of the way, the team at Storipress encountered another problem. JAMstack builds are traditionally done on a VM and use a significant amount of CPU power. If 10,000 customers were to simultaneously trigger a build, this would melt our servers.

This problem meant that under the current JAMstack paradigm, whilst the generated result was infinitely scalable, the build process was not.

Image of lambda

Half life 2 to the rescue

To solve this problem, Storipress uses AWS Lambda to process every build on our site. Every new build fires up a new Lambda process, meaning that with Storipress, the triggering of builds too can be infinitely scalable.

JAMStack is fast, but what about AMP?

With Storipress laying down the groundwork for a JAMstack powered future, some of you may be asking — why not just AMP? Google's open source AMP project seems to have many of the benefits of Storipress, but is powered by Google!

Aside from the fact that AMP is one of the most dreaded frameworks to work with by developers due to its poor developer experience, the biggest argument against AMP is that it gives Google more control over the open web. This might sound innocuous to some, but to publishers earning ad money from Google, it is alleged that:

  • Google deliberately throttled ad load times to promote AMP, claims new court document; and

  • Even with Google's aggressive pushing of the AMP framework, "According to Google's internal documents, [publishers made] 40 per cent less revenue on AMP pages."

In addition, Google has two main products: Search Ads and Publisher Ads (Google Ad Manager). With Google Search Ads, they get to keep 100% of the revenue they earn. With Google Ad Manager, they have to kick back 75%-99% of revenues to publishers.

I guess the question then becomes — would you trust a company which loses revenues through revshare when you win, or an independent company that wins when you win.

Aside from Storipress' clear DX advantages over AMP, the answer obviously is Storipress.

With JAMstack having revolutionised the way we think about building for the web, providing better DX, better performance, lower cost, and greater scalability, the culmination of Storipress' efforts I believe is the future of the JAMstack, and the logical next step in enabling access to a revolutionary technology which prior was locked off to only developers.