#008 — CSP + React+Vite vs Next.js
Date: July 3, 2026 | 19:00 London / 21:00 Kyiv
Format: Two talks · ~80–95 min
Guest: Oleksandr Blazheiko
YouTube: https://youtube.com/live/txdVcK2Sxno
Participants
Oleh Levchenko — Senior Full Stack JavaScript Developer (React / Node.js / AWS)
The AA · Cardiff, UK
YouTube @zloyleva · itfriday.community
Oleksandr Blazheiko — Software Development Engineer · Fullstack, 7+ years of experience
Ukraine
LinkedIn · itvibe.party
Key Takeaways
Talk 1 — Content Security Policy (CSP) · Oleksandr Blazheiko
- CSP — a security standard: the developer defines which sources a browser may load resources from (scripts, styles, images, frames) — an allowlist: only what's explicitly listed is permitted
- Why it matters — neutralizes the impact of XSS: even if an attacker injects a script, the browser won't execute it because the source is disallowed; also protects against clickjacking via
frame-ancestors - XSS attacks — reflected (a URL parameter lands in the HTML unescaped) and stored (malicious content saved in the DB and shown to every user)
- XSS during SSR hydration — state gets serialized to JSON and inserted into an inline script; unescaped data in that state is an XSS vector via premature
</script>closure - Directives —
default-src(fallback rule),script-src(the most important one against XSS),style-src,img-src,connect-src,frame-ancestors,base-uri - nonce vs hash instead of
unsafe-inline— nonce is a random token per request; hash is a SHA hash of the inline script's content - Report-Only —
Content-Security-Policy-Report-Onlylogs violations without blocking — a safe way to roll out CSP without risking a broken prod - Common mistakes — leaving
'unsafe-inline'"to make it work," using*, enabling blocking mode straight in prod without a Report-Only phase, relying on CSP alone instead of input sanitization - CSP vs CORS — CSP restricts what a page can load and execute (set by the page's server), CORS allows reading a response from another origin (set by the resource's server)
Talk 2 — React+Vite vs Next.js · Oleh Levchenko
- Vite — a build tool + dev server, fast HMR (esbuild in dev, Rollup for build); has no opinion on routing, rendering, or project structure — "just React" with fast tooling around it
- Next.js — a full framework: routing, rendering strategies, API routes, optimizations (images, fonts) — out of the box
- Rendering — Vite defaults to CSR (classic SPA); Next.js offers SSR/SSG/ISR out of the box; this affects SEO, first contentful paint (FCP), and performance on weaker devices
- Routing — with Vite you wire up
react-routeryourself and build the structure; Next.js uses file-based routing (app/), where a route is a folder/file - Dev experience — Vite's dev server gives instant HMR with minimal overhead; Turbopack in Next.js has caught up on speed, but the model itself is more complex (server/client components, caching)
- Deployment — Vite produces a static build deployable to any host (GitHub Pages, Netlify, S3+CloudFront); Next.js works best on Vercel out of the box, self-hosting requires a Node server for SSR/ISR
- When to choose Vite — SPAs, internal tools, dashboards, prototypes, when SEO isn't critical and you want full control over the stack
- When to choose Next.js — a public product where SEO/first render matters, SSR/ISR is needed out of the box, and the team is ready to accept a more complex rendering model
Timecodes
To be added after the stream.