Credit Risk Console

Aurelia Bank’s credit risk team needs to answer one question repeatedly: where is the risk concentrated, and what is moving? This application is how they answer it — and it is built entirely from AWC UI components.

Open the applicationSwitch framework, theme, density, direction and language from inside the app.

The ten builds

All ten are live, and the control bar switches between them without losing your place. They are not ten copies of the same code: every number, date, string, derived series and table layout comes from @awc-ui/showcase-kit, so the only thing that differs between them is the view layer — which is exactly what makes two screenshots comparable evidence.

They come in pairs. Each framework appears twice: once as a single-page application, where the server sends an empty shell and the browser renders everything, and once server-rendered per request, where the HTML arrives complete and the components are already inside declarative shadow DOM. Same screens, same components, same kit. The only variable is where the first render happened, which is what makes the pair worth looking at.

Build	Open	How it renders	Where the language lives
React	/react/	Single-page app — empty shell, the browser renders everything	Client state — switches in place
Next.js	/next/	Server-rendered per request, into declarative shadow DOM	Client state — switches in place
Vue	/vue/	Single-page app — Vite, no meta-framework	Client state — switches in place
Nuxt	/nuxt/	Server-rendered per request, into declarative shadow DOM	Client state — switches in place
Angular	/angular/	Single-page app — client-rendered only	Client state — switches in place
Angular (SSR)	/angular-ssr/	Server-rendered per request, into declarative shadow DOM	Client state — switches in place
Svelte	/svelte/	Single-page app — Vite, no meta-framework	Client state — switches in place
SvelteKit	/sveltekit/	Server-rendered per request, into declarative shadow DOM	Client state — switches in place
Astro	/astro/	Server-rendered into declarative shadow DOM, once, at build time	In the URL (`/astro/ro/`)
HTML	/html/	Static files, no framework at all	In the URL (`/html/ro/`)

The pairs are the experiment. React and Next.js, Vue and Nuxt, Angular and Angular (SSR), Svelte and SvelteKit: within each, both builds import the same six screens, the same components and the same kit. What differs is a handful of routing call sites — and where the first render happens.

Open /react/ with JavaScript disabled and you get an empty shell, because that is what a single-page application is. Open /next/ the same way and the document already contains every row, every heading and every component, each one inside a <template shadowrootmode="open"> the browser attaches before it runs a line of script. The same is true of /vue/ against /nuxt/, /angular/ against /angular-ssr/, /svelte/ against /sveltekit/.

That is the part worth seeing: web components server-render, shadow DOM and all, through four different frameworks’ own SSR pipelines rather than around them. Each one renders its markup its own way and then hands the HTML to the same renderToString from @awc-ui/core/hydrate — the components do not know or care which framework produced the page.

“Server-rendered” is easy to claim and easy to fake — a page prerendered at build time looks identical to one rendered live, because by then it is just a file. So pnpm verify:ssr asks the running deployment two separate questions: whether the markup arrives without a browser, and whether two requests a second apart come back with different render timestamps. Only a live server passes both.

Astro renders every component into declarative shadow DOM at build time, so the page arrives styled with no unstyled-tag flash — and stays readable with JavaScript switched off, apart from the charts, which draw into a <canvas> and cannot be painted without one.

HTML has no framework and no bundler in the page’s critical path: 285 static files, plus one small script carrying the control bar and four progressive enhancements (sorting and paging, the watchlist filters, the scenario switch, the sector-bar drill). Every figure on every screen is already in the markup.

Both still render the same document as the other four — the same ten rows, the same single stress scenario, the same components. Whatever is off screen rides in a <template>, which the parser keeps out of the document tree, so those two builds have the elements React has and the data React would have fetched.

Because neither has client-side rendering to re-run, both put the language in the URL rather than in client state, and switching it is a navigation. That is the honest thing for a document to do, and it is why those two are worth having as separate entries rather than as one “static” build.

What you can drill into

The portfolio is not a single screen with a chart on it. Every number is a way in:

Level	What it shows	Where it leads
Portfolio	Exposure at default, expected loss, RWA and weighted-average PD, with sector concentration and rating distribution	A sector, or straight to a large counterparty
Sector	Concentration against its limit, exposure trend, and every counterparty in it	A counterparty
Counterparty	Internal rating and watchlist status, facilities, rating history, and the corporate group it belongs to	A facility, or a group member
Facility	Terms, covenant headroom, collateral and haircuts, drawdown schedule	A breached covenant
Watchlist	Early-warning signals by severity, across the book	The counterparty that triggered it
Stress testing	Baseline, adverse and severe scenarios compared by expected loss and RWA	The sector that moves most

What it is really demonstrating

Credit risk was chosen because it is hostile to component libraries. It needs dense tables that sort and page without losing their place, breadcrumbs that survive four levels of drilling, charts that read the same data as the tables beside them, hierarchy views for corporate group structures, and numbers that stay legible at compact density.

Three things the control bar lets you verify directly:

Framework — the same screens in React, Vue, Angular, Svelte, Astro and plain HTML. The URL carries the framework, so /showcase/credit-risk/react/ and /showcase/credit-risk/svelte/ are the same application, and the control bar swaps that one segment.
Direction and language — English, Romanian and Arabic. Switching to Arabic flips the whole application right-to-left with real translated content, not mirrored Latin text.
Theme and density — a seed colour retints every component including the charts, and density rungs compress the tables the way a real trading-floor build would.

Fictional data

Aurelia Bank, its counterparties, ratings and exposures are invented. The figures are internally consistent — sector exposures sum to the portfolio total, facility drawdowns sum to counterparty exposure, and covenant headroom is computed from the stated thresholds — so the drill-downs reconcile the way a real book would, but no real institution or company is represented.