Server and client rendering
The server returns ready HTML that search engines can read, while client code brings the markup to life and updates pages without a reload.
Product
Our own web framework: server rendering, live interfaces and a single file on output
The challenge
The task the client came with and why it could not be solved before.
Off-the-shelf frontend frameworks impose their own architecture: server rendering has to be bolted on, multi-tenancy assembled from workarounds, and styling spreads across markup. We wanted a foundation that handles this by default.
Mechanics
The mechanics the product is built from.
The server returns ready HTML that search engines can read, while client code brings the markup to life and updates pages without a reload.
One codebase, different brands: an overlay mechanism lets several clients live in a single repository.
Styles are objects driven by theme tokens, so colours and typography live in one file instead of spreading through markup.
The server side runs on a high-performance HTTP server, and WebSocket is built into the framework rather than bolted on.
A build produces one executable: deployment is a file copy, with no environment to prepare on the server.
Pipeline
From an address in the browser to a finished page and its revival on the client. There is no intermediate build step in between.
The route tree lives in the manifest as regular expressions. The first match wins: it decides the page and its parameters.
The page function receives the context, the route parameters and the query string, reads the content and returns the data for the template.
The layout server function runs before the page: header, footer, theme and language. The page starts from a ready environment.
Markup lives in .fr files. A page is assembled from blocks, and every block keeps its template, logic and styles in one folder.
Styles are objects driven by theme tokens. The compiler gives every class its own hash, joins everything into a single file and drops rules the markup never uses.
The server returns fully rendered HTML: search engines read it, and it opens even where JavaScript does not run.
The client runtime finds blocks in the markup and attaches handlers. From there navigation happens without a reload, and data arrives over HTTP or WebSocket.
Where it sits
pastish2 is the web layer between the server platform and the products.
Services, events, storages, request routing. Responsible for data and computation.
Routes, pages, blocks, templates, styles and the client runtime. Responsible for what a person sees.
This website, the Udeu online learning platform, Ambitions and the RC Club call-centre back office.
Outcome
Not features for their own sake, but consequences for the product and the team.
The server returns finished HTML: search engines read it, it opens on a weak device and it does not disappear when a script fails to load.
The foundation is ours: a needed capability is added to the framework instead of waiting for a library update or working around its limits.
A block is a folder of three files; a page is a server function and a template. A route is one line in the manifest.
Colours and typography are described by theme tokens. Changing the look means a different token set, not edits across markup.
The overlay mechanism assembles different websites from a shared foundation: that is how Udeu and Ambitions share one codebase.
A build produces a single executable. There is no environment to prepare on the server.
Technology
The platform, the stack and the devices the product runs on.
Technologies
Platforms
Links
The product website and the materials about it.
Live demo
Demo access is provided on request.
We will deploy it white-label, tune the processes and onboard your team.