Waiting to Landing with Pocketbase

Waiting to Landing with Pocketbase

September 1, 2025

TL;DR

Combining PB: https://pocketbase.jalcocertech.com/_/ with CF Workers as seen recently give us possibilities.

With the waiting2landing concept seen on this post, that was based on an astro theme, you just decided which one to deploy statically via the compose file

There was a formbricks plugged to it as per: FORM_URL and FORM_EMAIL_FIELD_ID

Now: how about using PB to capture the email (no validation so far) and for people who provided it, they will be able to see a /app route, from where they will be able to fill a form to tell how they want to shape the product.

This is all about understanding SSG vs CSR vs SSR. And what SPA can do.

Intro

How about using and let them see a CSR page………

…….like this one:

And tested the new tech stack with a v2.0 with the waiting to landing idea:

How was that even possible?

The Theme

I thought about going with the landing-page-book I commented here.

But saw the potential with this astro theme ~ linktree related.

MIT | Personal Hub is a template designed to centralize and organize personal or professional information in one place. This tool allows users to manage and access their data, projects, important links, and more, all from a unified interface.

#git clone https://github.com/tedevs0/hub-itsteddydev
git clone https://github.com/JAlcocerT/link-hub-pb
npm install
npm run dev -- --host 0.0.0.0 --port 4321 #http://192.168.1.11:4321/ #useful to see from your phone how it looks
#sudo rm -r .git

What I liked about the theme:

  1. configurable via json and fully static (ssg)
  2. brings i18n working out of the box
⚠️
Auto-detect: Astro won’t pick browser language automatically for static sites. It renders both routes; you choose which URL to serve.

What I added:

  1. Signin/up pages
  2. Connection to the login signup to pb, similarly to what was done at this post

At some point we could get PB to do email verification

  1. The magic happens at the ./scripts
⚠️
  1. Playing with the ./scripts/app-secrets.ts, we can show to the users information available into a public json when they log in, or with more sense, see private information that only logged in people could see, powered by a PB collection, in this case called repos.

I followed this .md for the setup.

As you add new records, they will be visible for the users :)

npm install "pocketbase": "^0.21.3"

Modify the .env:

PUBLIC_PB_BASE_URL=https://pocketbase.jalcocertech.com

Just push it to GH, if you want:

#sudo apt install gh
gh auth login
gh repo create link-hub-pb --private --source=. --remote=origin --push

And then to push towards CF Pages:

npm run build
#npx http-server ./dist -p 4321

#wrangler --version
wrangler pages deploy dist --project-name=link-hub --branch=main
#wrangler pages project list

Conclusions

A Better Waiting2Landing

LinkHub with PocketBase

https://link-hub-1qd.pages.dev/


FAQ

SSG vs CSR vs SSR

CSR vs SPA

A Single-Page Application (SPA) is not always related to Client-Side Rendering (CSR).

But the two concepts are very closely linked and often used in tandem.

ℹ️
SPA can be deployed statically, as seen on this post section, for serverless-invoices

Here’s the key distinction:

  • Single-Page Application (SPA): This is a type of web application that loads a single HTML page and dynamically updates the content as the user interacts with it. This means that a user can navigate between different “views” of the application without a full-page reload. The core idea is to provide a seamless, app-like experience by handling navigation and state changes on the client.

  • Client-Side Rendering (CSR): This is a rendering technique where the browser downloads a minimal HTML file (often just a <div> and some scripts) and then uses JavaScript to build and render the rest of the page’s content. All the heavy lifting of generating the HTML, CSS, and dynamic content happens in the user’s browser.

The relationship is this: The most common way to build an SPA is by using Client-Side Rendering. The JavaScript frameworks like React, Vue.js, and Angular were built around this model. The initial HTML is a blank slate, and the framework’s JavaScript takes over to create the UI, fetch data from an API, and update the page without a full refresh.

However, the “always” part of the question is where it gets interesting.

Modern frameworks like Nuxt, Next.js, and SvelteKit have blurred the lines by offering hybrid rendering approaches. These frameworks can be used to build what still feels like an SPA, but they can use a different rendering technique for the initial load. For example:

  • Server-Side Rendering (SSR) for the initial load: A Nuxt application, for example, can be configured to use SSR. The server pre-renders the HTML for the first page the user requests. This is great for SEO and initial load performance. Once the page is loaded, the application “hydrates” and acts like a normal SPA, handling subsequent navigation and updates on the client-side without full-page reloads. This is often called a “Universal” application.

  • Static Site Generation (SSG) for all pages: A framework like Astro or Nuxt can also generate every possible page as a static HTML file at build time. When a user visits the site, they get a pre-built, fast HTML file. The pages can then have small “islands” of JavaScript that enable interactivity and SPA-like navigation, but they don’t rely on the client to render the entire page from scratch. This is a powerful way to get the performance benefits of a static site with the interactivity of an SPA.

So, while CSR is the foundational technique for building traditional SPAs, the modern web development landscape has evolved to allow for SPAs to be built with a variety of rendering strategies, including SSR and SSG, to improve performance, SEO, and user experience.

About Nuxt

Nuxt is an open-source, full-stack framework for building web applications using Vue.js.

It simplifies the development of complex applications by providing an opinionated structure, automatic routing, and multiple rendering modes out of the box.

Nuxt is inspired by Next.js, a similar framework for React.

I need to try NUXT sometime soon :)

Nuxt and JavaScript ☕️

Nuxt is deeply rooted in JavaScript, as it’s built on top of the Vue.js framework, which is a JavaScript library for building user interfaces.

⚠️
See more about TS and JS Frameworks

It uses JavaScript to handle almost every aspect of an application, from front-end interactivity to server-side logic.

  • Vue.js: Nuxt is a meta-framework for Vue.js. It leverages Vue’s component-based architecture and reactivity system. All the components and pages you create in a Nuxt application are essentially Vue components written in JavaScript (or TypeScript).
  • Node.js and Nitro: Nuxt’s server-side capabilities are powered by a server engine called Nitro, which is built on Node.js. This allows Nuxt to run JavaScript code on the server, which is essential for features like Server-Side Rendering (SSR) and API routes.
  • Tooling: Nuxt integrates popular JavaScript build tools like Vite or Webpack to bundle and optimize your application’s code for production.

Nuxt and SSG (Static Site Generators)

Nuxt is not just a static site generator, but it can act as one. It offers several rendering modes, including static site generation (SSG), which puts it in a similar category to frameworks like Astro or Hugo, but with some key differences.

Nuxt’s Rendering Modes

Nuxt provides a versatile rendering system that allows you to choose the best approach for your project:

  1. Single-Page Application (SPA): The entire application is rendered by the browser after it loads the initial HTML, CSS, and JavaScript. This is the traditional way of building a Vue app, and it’s great for highly interactive web apps.
  2. Server-Side Rendering (SSR): The server renders the initial HTML for each page, which is then sent to the browser. This improves initial load performance and SEO. Once loaded, the page becomes a fully interactive SPA. Nuxt calls this “Universal” rendering.
  3. Static Site Generation (SSG): Nuxt generates a static HTML, CSS, and JavaScript file for each page at build time. These files can be served from any static host or CDN. This provides the best performance and security and is ideal for content-heavy sites like blogs or documentation.

Nuxt vs. Astro and Hugo

While all three can be used to generate static sites, they have different philosophies and use cases:

  • Hugo: This is a pure static site generator written in Go. Its primary focus is on lightning-fast build times and serving static content. It’s not a JavaScript framework, so it doesn’t provide the same level of client-side interactivity or component-based development as Nuxt or Astro. It’s best suited for blogs, portfolios, or documentation websites where content is king and interactivity is minimal.

  • Astro: Astro is a modern SSG that champions a “zero-JS by default” approach. It uses a unique “Islands Architecture,” where pages are pre-rendered to static HTML, with small, interactive “islands” of JavaScript-enabled components added only where needed. This results in incredibly fast websites with a minimal JavaScript payload. Astro is framework-agnostic, meaning you can use components from different frameworks like Vue, React, or Svelte within the same project. It is great for content-heavy sites that need a bit of interactivity.

  • Nuxt: Nuxt is a full-stack Vue framework. While it can be used as an SSG, its main strength lies in its ability to build complex, full-stack applications with server-side rendering, API routes, and a rich ecosystem of modules. Nuxt ships with more JavaScript by default than Astro, as its core philosophy is building a complete, cohesive application, whether it’s an SPA, SSR, or SSG.

It’s the best choice for developers already in the Vue ecosystem who need a powerful tool for building complex, interactive web applications.