This group’s mission is to enable Frontend developers to build, deploy and manage externally facing, static websites using Jamstack architecture in a simple, configurable and scalable way.
Frontend engineers should be able to use GitLab as the primary place to manage Jamstack Frontends.
Technology supporting Jamstack is a fast-growing, highly innovating field with many startups competing for market shares.
GitLab’s solution is built on GitLab Pages and its solid CI/CD pipelines. This allows any client to grow seamlessly from a simple static site to complex, multi-faceted deployments without having to change the provider at any point. Competing in the Jamstack market potentially allows new Developers to have a shallow entry to GitLab’s CI/CD world. That is, if we get the User Experience right.
GitLab is not an infrastructure provider. This is an advantage for established clients that may already pay for their own infrastructure. GitLab can easily support a wide range of infrastructure using CI/CD pipelines, so our goal is to make this as simple as possible. It’s important that this scalability is conveyed from the very first onboarding steps to build trust with our users, even if most projects will stay small.
User survey
In January 2023 we conducted a User survey to provide data on the general direction around the Javascript runtime feature.
Jobs to be done
When I’m building a simple static site, I want to publish it without leaving the GitLab UI, so I can update faster and with fewer points of failure
When I’m building a server-side-rendered static site (SSR), I want to use GitLab to deploy, so that I don’t have to configure and pay other services to do so
When I’m deploying a Pages site, I want to have it distributed via a CDN so that the page is delivered faster
Maturity: 0% Status: planned
When I manage my own GitLab instance or group, I want to connect my own CDN account for Pages, so that developers can deploy static sites through a CDN without additional configuration
Maturity: 0% Status: planned
When I’m developing a Jamstack site, I want to create a simple CRUD API, so that I can save time on repetitive, boilerplate tasks
Maturity: 0% Status: planned
When I create a simple CRUD API through the GitLab UI, I want to export the API code into a repository so that I can continue development manually
These are the guiding principles that the Jamstack SEG optimizes its
implementations for.
Simplicity - It should be intuitive to use GitLab to deploy a static site. GitLab should be a great place to just get started with the confidence that deployments can be fine-tuned and scaled later.
Configurability - With the .gitlab-ci.yaml powering the solution, it should be straightforward to support a wide range of deployment strategies.
Scalability - GitLab should be able to support the entire page’s lifecycle. From a quick-and-dirty one-man project to powering the websites of high-traffic global organizations with complex infrastructure needs.
Backstory
The key to modern Jamstack Frontends are Websites built as Single Page Applications (SPA). Classic Javascript Frameworks like React or Vue.js build the entire HTML DOM on the client side, so to improve performance, they are supplemented by Rendering Engines (eg. Next.js, Nuxt.js) that use node.js to pre-render HTML before they are sent to the client’s browser. Frameworks like Eleventy, Gatsby.js or Hugo are both Framework and Rendering Engine.
All frameworks have in common that there are three main approaches as to when the rendering happens:
During Build time, also known as Static Site Generation (SSG), this is how GitLab Pages works now.
When a page is Requested, but instead of rendering in the client’s browser, the page is pre-rendered by the server, known as Server Side Rendering (SSR)
A mix of both, where pages are dynamically rendered once when requested for the first time, then cached, also known as Incremental Static Regeneration (ISR). This is usually supplemented with a step that pre-renders the most popular pages during build.
in January 2023 the Jamstack SEG conducted a user survey to identify the communities’ priorities around creating a Javascript runtime capability for GitLab.
This came at a time where I was making similar progress with both of the following work tracks:
a Cloudflare Workers Integration using the Cloudflare API
a V8 Javascript runtime integration into GitLab Pages directly
Both of these tracks will eventually result in users being able to run server-side Javascript functions without actually needing to deploy a server.
Both implementations come with large opportunities and risks, so I needed to factor in our user’s priorities. This is why many results are interpreted with that goal in mind.
Survey respondents
The survey was filled by 38 respondents, primarily Frontend- and Fullstack developers.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Cookie Policy
User ID: d2cc9cd1-83e6-4afc-8334-24c2e8a3a7fa
This User ID will be used as a unique identifier while storing and accessing your preferences for future.
Timestamp: --
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, enabling you to securely log into the site, filling in forms, or using the customer checkout. GitLab processes any personal data collected through these cookies on the basis of our legitimate interest.
Functionality Cookies
These cookies enable helpful but non-essential website functions that improve your website experience. By recognizing you when you return to our website, they may, for example, allow us to personalize our content for you or remember your preferences. If you do not allow these cookies then some or all of these services may not function properly. GitLab processes any personal data collected through these cookies on the basis of your consent
Performance and Analytics Cookies
These cookies allow us and our third-party service providers to recognize and count the number of visitors on our websites and to see how visitors move around our websites when they are using it. This helps us improve our products and ensures that users can easily find what they need on our websites. These cookies usually generate aggregate statistics that are not associated with an individual. To the extent any personal data is collected through these cookies, GitLab processes that data on the basis of your consent.
Targeting and Advertising Cookies
These cookies enable different advertising related functions. They may allow us to record information about your visit to our websites, such as pages visited, links followed, and videos viewed so we can make our websites and the advertising displayed on it more relevant to your interests. They may be set through our website by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertisements on other websites. GitLab processes any personal data collected through these cookies on the basis of your consent.