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 proceeding with how Storipress implements the JAMstack, we must first understand what it is.
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 built with a static site generator. The backend is then connected to the front end through APIs used during the build process. Server-side processes are decoupled, 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 by using a static site generator. This tool generates an entirely static HTML website based on raw data and a set of javascript templates. This automates the task of coding individual HTML pages and getting those pages ready to serve users ahead of time.
Illustration of the JAMstack process
By building sites in this way, you get blazingly fast load speeds, increased security, far less expensive to host and scale, and better DX due to using 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 around 1 Mb, whereas a comparable page on the New York Times would weigh in at 3 Mb, or over 300% larger. This means that in delivering our customer's content, we are not required to manage, and scale databases and servers based on site load, and file transfer costs are also 3x less, allowing us to deliver elite performance for 50% of the price.
There is also the human aspect. As a no-code platform, customers save significant money on implementation and ongoing maintenance costs, meaning that when taken holistically, Storipress can deliver experiences reserved for enterprises in the past for less than 10% of the price.
Not convinced? Click 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 slow: Unlike dynamic sites, which build content on the fly, with the JAMstack, every time a change is made, your site is rebuilt from scratch. This problem is exasperated if your site has many large media files, as on every rebuild, your static site generator re-optimises these files. As your site gets bigger, each build can take over 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 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.
No user-friendly interface: Following the above theme, non-developer users find it harder 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 not suitable for publishers who are often not technical and 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 usability by possibly being 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 more straightforward than WordPress (which scores a measly 50). This gap is made worse when considering that the SUS is a logarithmic scale, meaning Storipress 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 traditionally done on a VM and use significant CPU power. If 10,000 customers were to trigger a build simultaneously, 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.
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.
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.
