[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"contentNavigation":3,"topic-ssr":4,"newsletter-stats":9,"articles-feed-\u002Ftopics\u002Fssr-1-ssr-":11,"$fQa3xUpnRDPNiFFu2QS4K-DAjYmsapeR9fNhPNBdpkOc":-1,"home-tags":219},[],{"articleCount":5,"color":6,"id":7,"name":8,"slug":8},9,"#10b981","019d6bd8-ca89-735e-a52a-ee53a80a77a9","ssr",{"confirmedCount":10},409,{"items":12,"page":217,"pageSize":218,"totalCount":5},[13,44,68,87,108,128,152,176,193],{"content":14,"createdAt":15,"id":16,"image":17,"isAffiliate":18,"isPublished":19,"publishedAt":20,"slug":21,"sourceId":22,"sourceName":23,"sourceType":24,"summary":25,"title":26,"updatedAt":27,"url":28,"urlHash":29,"tags":30},"Nuxt 4.5 is our biggest release in a while. Vite 8, Rspack 2 powered by Rsbuild, experimental SSR streaming, a stable error code system, a new useLayout composable, named views, and a lot of groundwork for Nuxt 5.","2026-07-18T20:00:05.093Z","019f76d0-85d1-75ad-b055-ca88182f4c34","https:\u002F\u002Fnuxt.com\u002Fassets\u002Fblog\u002Fv4.5.png",false,true,"2026-07-18T00:00:00.000Z","nuxt-45","019d6c1a-e19c-736e-b489-240be1c0d29a","Nuxt Blog","rss","Nuxt 4.5 marks a significant release featuring Vite 8, Rspack 2, experimental SSR streaming, and a stable error code system. The update also introduces a new useLayout composable and named views, laying the groundwork for future developments in Nuxt 5.","Nuxt 4.5","2026-07-18T20:00:18.669Z","https:\u002F\u002Fnuxt.com\u002Fblog\u002Fv4-5","ad958454b80eb5d0f0b2d26d025d8a1b3d5a2d8458568e1c6a4bbee7ca10feff",[31,34,37,38,41],{"color":6,"id":32,"name":33,"slug":33},"019d6bd8-fad3-70a9-a74d-ab96e3a2f45d","nuxt",{"color":6,"id":35,"name":36,"slug":36},"019d9cf0-c9f8-7411-beed-02265d8271db","vite",{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":39,"name":40,"slug":40},"019f76d0-bb29-72d6-8d0b-05ffd1d3c8ed","composables",{"color":6,"id":42,"name":43,"slug":43},"019d9d20-dfb9-7041-9973-39c545b33a2d","release",{"content":45,"createdAt":46,"id":47,"image":48,"isAffiliate":19,"isPublished":19,"publishedAt":49,"slug":50,"sourceId":51,"sourceName":52,"sourceType":53,"summary":54,"title":55,"updatedAt":56,"url":57,"urlHash":58,"tags":59},"Practical techniques for faster Nuxt apps","2026-07-01T16:00:01.983Z","019f1e68-a398-7614-a565-37bb57fd85c8","https:\u002F\u002Fapi.certificates.dev\u002Fstorage\u002FlAB305vJFYD8SXv60gboztHN0tgrQaSTFlfCfQhq.png","2026-07-01T06:00:00.000Z","performance-optimization-in-nuxt","019d9eed-d835-729a-a029-7e6320cb67ed","Certificates.dev","certificatesdev","This article discusses practical techniques for optimizing the performance of Nuxt applications, focusing on methods to achieve faster load times and improved user experience.","Performance Optimization in Nuxt","2026-07-01T16:00:20.532Z","https:\u002F\u002Fcertificates.dev\u002Fblog\u002Fperformance-optimization-in-nuxt?friend=MOKKAPPS","353723c33e99e065af48d6f8f29950fd1122acbb8fe3b727cf84cf41282804aa",[60,61,64,65],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":62,"name":63,"slug":63},"019d6bd8-ca26-775c-b9b5-c3439dbe5789","performance",{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":66,"name":67,"slug":67},"019e8e36-bd4b-740d-b23a-81858b24025b","ssg",{"content":69,"createdAt":70,"id":71,"image":72,"isAffiliate":19,"isPublished":19,"publishedAt":73,"slug":74,"sourceId":51,"sourceName":52,"sourceType":53,"summary":75,"title":76,"updatedAt":77,"url":78,"urlHash":79,"tags":80},"How to deploy Nuxt to Vercel, Netlify, Cloudflare, and Node, with hybrid rendering via routeRules.","2026-06-03T16:00:00.395Z","019e8e36-8d78-723f-be81-94cc2f36502c","https:\u002F\u002Fapi.certificates.dev\u002Fstorage\u002Fyw1suASU3ol8gn9bqhagyHsgnn2XjoGRQovUye3h.png","2026-06-03T06:00:00.000Z","deploying-nuxt-presets-platforms-and-hybrid-rendering","This article provides a comprehensive guide on deploying Nuxt applications across various platforms including Vercel, Netlify, and Cloudflare, while also discussing hybrid rendering techniques using routeRules. It aims to equip developers with the knowledge needed to effectively deploy their Nuxt projects.","Deploying Nuxt: Presets, Platforms, and Hybrid Rendering","2026-06-03T16:00:12.562Z","https:\u002F\u002Fcertificates.dev\u002Fblog\u002Fdeploying-nuxt-presets-platforms-and-hybrid-rendering?friend=MOKKAPPS","6ac4de1ab593d1295277a17b34f0e60f4937ab7ba1b40b0bb8c8dbceae2e94b2",[81,82,85,86],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":83,"name":84,"slug":84},"019d9eda-5005-7329-a463-189572e25635","deployment",{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":66,"name":67,"slug":67},{"content":88,"createdAt":89,"id":90,"image":91,"isAffiliate":18,"isPublished":19,"publishedAt":92,"slug":93,"sourceId":94,"sourceName":95,"sourceType":24,"summary":96,"title":97,"updatedAt":98,"url":99,"urlHash":100,"tags":101},"Understand the key distinction between useFetch and event.$fetch in Nuxt. Learn why using event.$fetch for server-side API calls is the recommended approach for better performance and SSR correctness.","2026-05-16T18:48:35.150Z","019e321e-6c32-75c9-b0a0-2ba5b5c9f791","https:\u002F\u002Fmokkapps.twic.pics\u002Fmokkapps.de\u002Fvue-tips\u002Fdifference-between-use-fetch-and-event-fetch-in-nuxt\u002Fog.png","2026-05-16T00:00:00.000Z","nuxt-tip-difference-between-usefetch-and-eventfetch","019d6bd5-57e0-742c-8de2-c0a3a1f49b60","Michael Hoffmann","This article explains the difference between useFetch and event.$fetch in Nuxt, highlighting that event.$fetch is preferred for server-side API calls due to its advantages in performance and SSR correctness.","Nuxt Tip: Difference Between useFetch and event.$fetch","2026-05-16T18:48:40.681Z","https:\u002F\u002Fmokkapps.de\u002Fvue-tips\u002Fdifference-between-use-fetch-and-event-fetch","0880d118888dfef0df3d7ab0fd12fa6cc04b0dec3263b3d9d33fd049fce7ac56",[102,103,104,107],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":105,"name":106,"slug":106},"019d6bd8-fb46-77ef-a3b6-bd2d30ab8919","api",{"color":6,"id":62,"name":63,"slug":63},{"content":109,"createdAt":110,"id":111,"image":112,"isAffiliate":18,"isPublished":19,"publishedAt":113,"slug":114,"sourceId":115,"sourceName":116,"sourceType":24,"summary":117,"title":118,"updatedAt":119,"url":120,"urlHash":121,"tags":122},"When building modern web applications, security is not optional. One of the most important protections you can add is a Content Security Policy (CSP). But here’s the catch: 👉 CSP often blocks inline scripts and styles — which can break your app. So how do you keep your app secure without disabling useful features? That’s where CSP nonce comes in - it allows you to safely execute inline code without opening security holes. In this article, we’ll explore: What CSP nonce is What problem it solves How to implement it How it works automatically in Nuxt with nuxt-security Best practices and common pitfalls Let’s dive in. 🤔 What Is CSP Nonce? A nonce (short for number used once) is a unique, random value generated for each request. It is used in CSP to explicitly allow trusted inline scripts or styles. Example: <script nonce=\"abc123\"> console.log('Secure inline script') <\u002Fscript> And in your HTTP headers: Content-Security-Policy: script-src 'nonce-abc123' The browser will only execute scripts that have a matching nonce. CSP nonce is a whitelist mechanism: Only scripts with the correct nonce are allowed Everything else is blocked The nonce changes on every request This makes it extremely effective against XSS (Cross-Site Scripting) attacks. CSP nonce is commonly used for: SSR frameworks - Injecting initial state, Hydration scripts Analytics \u002F tracking snippets - Inline scripts required by providers Critical inline scripts - Small scripts needed before app bootstraps 🟢 What Problem Does CSP Nonce Solve? Without nonce, you usually face a trade-off: ❌ Allow inline scripts (unsafe) Content-Security-Policy: script-src 'unsafe-inline' Problem: Opens the door to XSS attacks Any injected script can run ❌ Block inline scripts completely Content-Security-Policy: script-src 'self' Problem: breaks inline event handlers breaks injected scripts (SSR hydration, state) breaks some frameworks 🟢 How to Implement CSP Nonce The process is relatively simple but let's break it down and explain each step individually. Step 1: Generate a nonce per request Example (Node.js): import crypto from 'crypto' function generateNonce() { return crypto.randomBytes(16).toString('base64') } Step 2: Add it to response headers const nonce = generateNonce() res.setHeader( 'Content-Security-Policy', `script-src 'nonce-${nonce}'` ) Step 3: Inject it into your HTML <script nonce=\"{{nonce}}\"> window.__INITIAL_STATE__ = {} <\u002Fscript> ⚠️ Critical rule The nonce in the header and HTML must match exactly. Otherwise, script will be blocked and app may break silently. 🟢 CSP Nonce in Nuxt (with nuxt-security) If you’re using Nuxt, things get much easier thanks to nuxt-security module that can: Automatically generate nonce per request Inject it into CSP headers Attach it to scripts\u002Fstyles It makes it much easier to work with CSP nonces in Nuxt. Let's take a look at the following configuration: export default defineNuxtConfig({ modules: ['nuxt-security'], security: { headers: { contentSecurityPolicy: { 'script-src': [ \"'self'\", \"'nonce-{{nonce}}'\" ] } } } }) What happens automatically: Nuxt generates a nonce per request Replaces {{nonce}} in headers Applies nonce to inline scripts You don’t need to manually wire everything You can read more here: https:\u002F\u002Fnuxt-security.vercel.app\u002F 🟢 Common Mistakes Let's take a look at the list of common mistakes to understand what to look for: ❌ Reusing the same nonce - Nonce must be unique per request and cryptographically random ❌ Forgetting to apply nonce in HTML - if you only set CSP header the scripts will still be blocked ❌ Mixing nonce with unsafe-inline - script-src 'unsafe-inline' 'nonce-abc' ❌ Caching issues - if HTML is cached nonce may not match header 🧪 Best Practices Generate nonce per request Use secure randomness (crypto) Never reuse nonce Avoid unsafe-inline Use frameworks\u002Ftools (like nuxt-security) Test CSP in report-only mode first Monitor browser console for CSP violations 📖 Learn more If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below: It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉 🧪 Advance skills A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success. Check out Certificates.dev by clicking this link or by clicking the image below: Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more! ✅ Summary CSP nonce is a powerful mechanism that allows you to safely use inline scripts while maintaining strong security. In this article, you learned: What CSP nonce is and how it works What problem it solves (security vs flexibility) How to implement it step by step How Nuxt + nuxt-security handle it automatically Common mistakes and best practices Take care! And happy coding as always 🖥️","2026-04-27T08:00:05.007Z","019dcdf3-df7e-70dd-ba04-801be7e72c7d","https:\u002F\u002Fmedia2.dev.to\u002Fdynamic\u002Fimage\u002Fwidth=1200,height=627,fit=cover,gravity=auto,format=auto\u002Fhttps%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fp5bl1ap8ran4lh39r6v8.png","2026-04-27T06:46:57.000Z","how-to-safely-allow-inline-scripts-without-breaking-security-with-csp-nonce","019d6bd6-7fe0-7244-80dc-9a4e8751886a","Jakub Andrzejewski","This article discusses how to implement Content Security Policy (CSP) nonce to safely allow inline scripts in web applications without compromising security. It explains the challenges posed by CSP, particularly in SSR frameworks like Nuxt, and provides a step-by-step guide on generating and using nonces effectively, including how the nuxt-security module simplifies this process.","How to Safely Allow Inline Scripts Without Breaking Security with CSP Nonce","2026-06-10T14:35:13.934Z","https:\u002F\u002Fdev.to\u002Fjacobandrewsky\u002Fhow-to-safely-allow-inline-scripts-without-breaking-security-with-csp-nonce-3a2j","c7251f3ab53426399ca4e47e0e37b3c6cc6a18cf582be5d9d1521032441cb964",[123,124,127],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":125,"name":126,"slug":126},"019dcdf3-fc84-73aa-a0be-6b7196c5a2e9","security",{"color":6,"id":7,"name":8,"slug":8},{"content":129,"createdAt":130,"id":131,"image":132,"isAffiliate":18,"isPublished":19,"publishedAt":133,"slug":134,"sourceId":135,"sourceName":136,"sourceType":24,"summary":137,"title":138,"updatedAt":139,"url":140,"urlHash":141,"tags":142},"An agent writes most of my frontend code now. I review what it produces and tighten the architecture where it overreaches. That changes what a quality pipeline is for. You used to write tests and types so the next person on the file stayed sane. Now you write them so the agent can check its own work. Give it more ways to verify a change (types, lint, unit, component, real browser, a11y, bundle budget) and it finishes more of the ticket on its own. A red check tells it what to try next. Frontend has also grown more complicated since 2024. SSR, streaming, partial prerendering, server components, edge runtimes. Each adds a place where a change can break silently. “TypeScript plus a couple of unit tests” no longer covers it. A quality pipeline is the set of checks that run on every change (locally, on commit, in CI) to give layered confidence the change is correct, accessible, performant, and safe to ship. A testing strategy is the part of that pipeline that asserts behaviour: what the app should do, at which level, at what cost. Plan them as one system. The pipeline decides when checks run; the strategy decides which checks are worth running. Design them together so that: Each check has a clear job and runs at the cheapest stage where it can catch the problem. The feedback loop is short enough that no developer or agent skips ahead. The same checks run on a contributor’s laptop, in an agent’s sandbox, and on the CI runner. The same pipeline shape applies whether you build with Next, Nuxt, Astro, SvelteKit, Remix, or a plain Vite app. The framework choice changes which adapter you import, nothing else. Background Frontend tooling consolidated between 2023 and 2026. Vite became the default dev\u002Fbuild engine across the major frameworks. Vitest replaced Jest. Playwright became the default for E2E. ESLint adopted flat config; Biome and Oxlint emerged as much faster alternatives in Rust. TypeScript strict mode became table stakes. Renovate replaced Dependabot. In March 2026, VoidZero shipped Vite+ as the open-source culmination of that trend: one CLI that wraps Vite, Rolldown, Vitest, Oxlint, Oxfmt, and Tsdown. A modern quality pipeline’s pieces look the same regardless of framework, so I’ll describe the concept first and my stack second. My default stack For new frontend projects in 2026 I reach for Vite+ instead of wiring the toolchain by hand. Vite+ (viteplus.dev) is the unified toolchain from VoidZero, Evan You’s company. It bundles Vite, Rolldown, Vitest, Oxlint, Oxfmt, and Tsdown behind a single CLI (vp dev, vp check, vp test, vp build) and one config file. The alpha shipped open source under MIT. If you adopt the pieces one at a time, the swaps I would make are: Old default What I use Why ESLint Oxlint ~50× faster, fast enough to run on every keystroke Prettier Oxfmt ~30× faster, Prettier-compatible defaults Jest Vitest ESM-native, browser mode, same matchers webpack Vite + Rolldown ~40× faster production builds four separate configs vp check \u002F vp test \u002F vp build one CLI, one config Each piece holds up on its own. I have shipped Vitest and Oxlint in production for some time; swapping Prettier for Oxfmt and webpack for Rolldown took a day in the projects I tried. Vite+ removes the integration cost that kept teams on the older stack. The layers Think of the pipeline as concentric layers, each cheaper and faster than the one outside it. Run cheap checks first. Save the expensive ones for the things only they can catch. 1. Type safety Type safety is your first line of defence. Run your framework’s type checker in CI on every PR. Treat any new type error as a build failure. If you use TypeScript, that means tsc --noEmit (or your framework’s wrapper around it; most frameworks ship one to handle their template syntax and project references). If you don’t use TypeScript yet, adopting it is the highest-leverage change you can make. Validate untyped boundaries with a schema library (Zod, Valibot, ArkType). Parse anywhere data crosses a boundary: route params, API responses, env vars, form input. TypeScript trusts the types you write; schemas check that the data matches them at runtime. With runtime parsing in place you stop reaching for as. See why as is a shortcut to avoid. 2. Lint and format Catches style and a wide class of bugs (unused vars, unsafe any, missing deps in effects) without running the code. The conventional choice is ESLint flat config plus typescript-eslint and your framework’s plugin. The 2026 alternative is Oxlint (Rust-based, ~50× faster) paired with Oxfmt for formatting, or Biome for a single-binary lint+format combo. The trade-off: Oxlint and Biome have smaller rule sets than ESLint’s mature ecosystem, but they cover most of the high-value cases and are fast enough to run on every keystroke. For a working setup that uses Oxlint as a fast first pass and keeps ESLint for the rules Oxlint doesn’t yet cover, see my opinionated ESLint setup for Vue projects. Add these two rule families regardless of which linter you pick. They catch bugs the type system misses: eslint-plugin-regexp – ~60 correctness rules for regular expressions. Cheap to add, catches real bugs. @e18e\u002Feslint-plugin – small performance lints (e.g., prefer Set.has over Array.includes) that compound across a codebase. 3. Unit tests For pure functions, hooks, stores, and utilities. Cheap, fast, and where most logic should live. Tool: Vitest. Run on every save in watch mode; run all of them in CI. Aim for high coverage of pure modules; don’t chase coverage on UI glue. For Vue, see my guide to testing Vue composables with Vitest. 4. Component tests For components in isolation, with a real DOM and real user interactions. The biggest win in 2026 is Vitest browser mode: your component tests run in a real Chromium via Playwright instead of jsdom. Hover states, focus, layout, intersection observers, and scroll behaviour all work as they do in production. Pair this with @testing-library\u002F* for whichever framework you use; accessibility assertions on each mounted component live in layer 8 below. For a deeper walkthrough of how this fits into a full testing pyramid, see my Vue 3 testing pyramid guide. 5. API mocking Hard-coded fixtures go stale. Tests that hit a real backend are flaky. Mock at the network layer once and reuse the same handlers everywhere. Tool: MSW (Mock Service Worker). It intercepts fetch, XHR, and GraphQL with a service worker in the browser and a request interceptor in Node, so the same handler definitions work in Vitest, Vitest browser mode, Playwright, and the dev server. Define handlers once in src\u002Fmocks\u002Fhandlers.ts; load them in your test setup and (optionally) in the dev server for offline-first development. Combined with Zod (or Valibot\u002FArkType) schemas at the same boundary, you get mocks that are typed, schema-validated, and shared across every layer that hits the network. One source of truth instead of three drifting fixture folders. 6. Contract testing The mocks in layer 5 are only as good as the assumptions you bake into them. If the backend renames a field or changes a status code without telling you, every green unit and component test still passes while production breaks. Contract testing closes that gap by tying the mock to a verifiable artefact that the provider checks against. There are three styles, and they fit different team setups. Consumer-driven contracts (Pact). The frontend writes a test that records the requests it makes and the responses it expects. Pact generates a JSON contract and publishes it to a broker (the open-source Pact Broker, or hosted PactFlow). The provider runs its real test suite against that contract; if it satisfies every recorded interaction, both sides can deploy. Pact has libraries for JS\u002FTS, JVM, .NET, Go, Rust, Python, Ruby, PHP, and Swift, so the same broker spans a polyglot estate. Best when you control both ends of the wire and want the consumer to drive the schema. Provider-driven \u002F OpenAPI-based. The provider publishes an OpenAPI spec and the contract is the spec. Consumers validate their requests and assertions against it with Schemathesis (property-based fuzzing of every operation), Dredd (replays example requests from the spec against the running provider), or Spectral (lints the spec itself). Best when the provider already maintains an OAS and you don’t want to add Pact on their side. Bi-directional contracts (PactFlow). The consumer publishes a Pact contract; the provider publishes its OpenAPI spec; PactFlow proves the two are compatible without the provider having to run consumer-supplied tests. Best when consumers want consumer-driven semantics but the provider team won’t (or can’t) run Pact verification themselves. What you get for the work: Independent deploys. A contract gate replaces “is the matching E2E green?” with “does the provider satisfy every consumer’s contract?”. Consumer and provider can ship on different cadences without coordinating a release train. Faster than E2E. Verifying a contract is a unit test for the boundary; E2E spins up the real services. You catch the same class of bug an order of magnitude sooner. Catches drift the linter can’t. A field renamed on the backend fails the contract before MSW handlers or Playwright flows would notice. Skip this layer if you own both services and ship them as one unit. E2E covers the same boundary in that case, and the contract overhead doesn’t pay off. Add it the moment consumer and provider deploy on different cadences, you don’t own the provider, or a single backend serves multiple frontends that all need to keep working. For a deep dive, Contract Testing in Action (Marie Cruz & Lewis Prescott, Manning) walks through Pact, bi-directional contracts, and how to introduce the practice without stalling delivery. 7. End-to-end tests For critical user journeys across real pages: signup, checkout, the one or two flows that must never break. Keep the suite small. E2E is expensive. Tool: Playwright. Run against a built preview, not the dev server. Two assertions worth wiring into a custom fixture, regardless of framework, because they catch silent regressions: Hydration mismatches. Listen for hydration warnings on console and fail the test if any appear. SSR\u002FCSR drift is one of the most common silent regressions in modern frameworks. I wrote a dedicated post on catching hydration errors in Playwright tests with a reusable fixture. CSP violations. Listen for securitypolicyviolation events. If your CSP is real, this turns every E2E run into a CSP regression test. 8. Accessibility Accessibility cuts across lint, component, E2E, and preview. Treat it as a single discipline and check the same WCAG rule set at every cheap-enough stage. Lint. eslint-plugin-jsx-a11y (React\u002FJSX), eslint-plugin-vuejs-accessibility (Vue), eslint-plugin-astro — catch missing alt, role mismatches, and other static violations before tests run. Component. axe-core via jest-axe for jsdom, or @axe-core\u002Fplaywright in Vitest browser mode. Assert no violations on every mounted component, and add a meta-test that fails if any component test lacks an a11y assertion so the practice doesn’t slide. E2E. @axe-core\u002Fplaywright on each critical journey — same engine as the component layer, but on the real composed page where many violations only appear once everything is wired together. Preview. Lighthouse’s accessibility category (run as part of layer 10) or Pa11y CI on a list of routes for a dedicated, auditable report. Manual. Storybook’s a11y addon, keyboard-only walkthroughs of new flows, and screen-reader spot-checks. Automated tools catch roughly 30% of WCAG issues; the rest needs a human. This is no longer optional in the EU: the European Accessibility Act took effect in mid-2025, so most B2C and many B2B products operating in EU markets are now legally required to meet WCAG 2.1 AA equivalence. For a framework-specific checklist, see my Vue accessibility blueprint. 9. Visual regression Catches unintended UI drift that unit and E2E tests miss. Chromatic (hosted, Storybook-native) or Playwright screenshots + a diff tool like Lost Pixel for self-hosted. For a Vitest-native approach, see how to do visual regression testing in Vue with Vitest. onlyChanged: true keeps it cheap: only re-snapshot stories whose dependencies changed. Gate on PR; review diffs as part of code review. 10. Performance and bundle size Performance regressions are silent unless you measure them. Lighthouse CI on a preview deployment. Run it against both a light and dark color scheme; contrast regressions show up only in one. size-limit or your framework’s bundle analyzer on PR for bundle deltas. Set explicit budgets and fail the build when they’re exceeded. Lab measurements catch regressions before merge. To see what real users experience, and to find bottlenecks while you’re writing the code, see layer 15 below. 11. Dead code and dependency hygiene Unused code is a tax on every other check. Knip to find unused files, exports, and dependencies. Configure per-workspace if you have a monorepo. Renovate for automated dependency updates with grouping and a sane schedule. OSV-Scanner for vulnerabilities and Gitleaks for secrets, gated to high-severity only to avoid alert fatigue. Generate an SBOM (Software Bill of Materials) on every build with Syft, Trivy, or cdxgen, in CycloneDX or SPDX format. This is shifting from “nice to have” to “regulated requirement” in 2026 (EU CRA, US executive orders), and it’s the same artefact your security team uses to answer customer vulnerability questionnaires. 12. Internationalisation drift If you ship in more than one language, untranslated strings slip through. A mature i18n library plus a drift checker in CI catches them. i18n libraries – i18next, vue-i18n, FormatJS \u002F react-intl, and Lingui all expose a missing-key handler you can fail the build on, plus extractor CLIs that refuse to ship if a string has no translation entry. Lint your source for hardcoded strings. ESLint has eslint-plugin-i18next and @intlify\u002Feslint-plugin-vue-i18n to flag bare strings in JSX\u002Ftemplates and unused or missing keys. Oxlint doesn’t yet ship i18n-specific rules, so run it as the fast first pass and keep these ESLint plugins for the i18n layer. Lunaria compares each locale against a source locale and reports missing or stale keys. It works with any project that has translation files; you can publish a public status dashboard from the same data. 13. Preview deployments The cheapest way to enable manual review and to give E2E, Lighthouse, and visual-regression checks something realistic to run against. Vercel, Netlify, or Cloudflare Pages will give you a unique URL per PR for free. Wire your downstream checks to that URL. 14. Automated code review In 2026, AI code review is a standard pipeline stage. It runs before any human reviewer touches the PR and catches issues the layers above miss: logic mistakes, missing edge cases, security smells, and the small inconsistencies that lint rules can’t express. CodeRabbit, Greptile, and Vercel Agent are the main options. Recent benchmarks put Greptile’s bug-catch rate around 82% versus CodeRabbit’s ~44%, but Greptile produces more false positives and runs slower; CodeRabbit covers more git platforms. Have it run alongside specialist scanners (secrets, vulnerabilities, workflow lint, shell\u002Fyaml lint) so a single bot comment summarises every machine-checkable concern on the PR. Pause the bot on Renovate \u002F Dependabot PRs to avoid noise on mechanical updates. Treat the AI reviewer as a high-recall first pass that reduces human review without replacing it. If you want to add an AI agent that goes one step further and exercises the app in a real browser, see how I run automated QA with Claude Code, Agent Browser, and GitHub Actions. 15. Runtime observability Layers 1–13 give you confidence at merge time. Once a change is in production, and while you’re writing it, you also want a live view of what the app is doing. The same instrumentation answers both questions. Use OpenTelemetry as the SDK. It’s the only vendor-neutral option, and the JS ecosystem caught up in 2025–2026: stable web SDK, official auto-instrumentations for document-load, fetch, xhr, and user-interaction, and OTLP support in every backend that matters. Browser SDK. @opentelemetry\u002Fsdk-trace-web plus the auto-instrumentations emits OTLP\u002FHTTP. Wrap web-vitals into OTel metrics so LCP\u002FINP\u002FCLS land on the same backend as the trace that produced them. One pipe instead of two. SSR \u002F edge. Next, Nuxt, SvelteKit, and Astro all expose OTel hooks. Set a single service.name resource attribute and one request stitches together: edge → SSR → hydration → client interaction, all in one trace. One collector, two backends. Run an OpenTelemetry Collector with two exporters. In dev, point it at Jaeger or Grafana Tempo running via docker-compose; open localhost:16686 and you can watch every fetch, render, and hydration span as you click through the app. In prod, swap the exporter to Honeycomb, Grafana Cloud, Dash0, or Sentry’s OTel ingest. Same SDK, same instrumentations, different OTLP endpoint. Sample, or pay. ParentBased(TraceIdRatioBased(0.05)) in prod, AlwaysOn in dev. Tail-sample at the collector to keep the slow and error traces and drop the rest, so the signal that matters survives without renting cloud storage for every render. The dev-time payoff is the part most teams underuse. The next time someone asks why a page is slow on a real device, you already have the trace from when they loaded it. Where each layer runs Same layers, different stages. Pick the cheapest stage where each check can catch the problem. Stage What runs Editor Type checker LSP, linter, Vitest watch Pre-commit Format and lint on staged files only CI on PR Typecheck, full lint, unit, component, contract verify, build, knip, size-limit, AI review CI on preview URL E2E, accessibility (axe + Lighthouse), visual regression Post-merge \u002F nightly Full E2E matrix, dependency updates, security scans, SBOM publish Dev server \u002F production OpenTelemetry traces and metrics: live in dev, sampled in prod For wiring local hooks themselves, Lefthook has become the default modern alternative to Husky: a single Go binary, declarative YAML config, and parallel execution of lint\u002Fformat\u002Ftest commands on staged files. Commit a lefthook.yml to the repo, run lefthook install once, and contributors get the same hook setup automatically. Pair it with lint-staged (or Lefthook’s built-in {staged_files} substitution) so pre-commit only runs against the files that changed. That fast-check pattern keeps the hook under a couple of seconds. Git 2.54 added config-based hooks, which means a small project no longer needs an external hook manager at all. You define hooks in .gitconfig instead of as scripts under .git\u002Fhooks: [hook \"linter\"] event = pre-commit command = pnpm exec oxlint --staged [hook \"format\"] event = pre-commit command = pnpm exec oxfmt --check Multiple hooks per event run in order. Disable a single hook with hook.<name>.enabled = false (useful for opting one repo out of a system-wide config), and list the active ones with git hook list pre-commit. The traditional .git\u002Fhooks\u002F* scripts still run last, so existing setups keep working. For a small project this covers most of what Lefthook does without an extra binary. Lefthook still has the edge for parallel execution and staged-file substitution. One valid alternative skips commit hooks and runs everything server-side in CI as required status checks. You trade a slower red-CI feedback loop for never blocking a contributor with a flaky local hook. If GitHub Actions is the CI you’re wiring this onto, GitHub Actions in Action (Kaufmann, Bos & de Vries, Manning) covers workflow design, reusable actions, matrix builds, secrets, and self-hosted runners. It pays off once you outgrow the default templates and start wiring the layers above into shared workflows. What this gets you Regressions caught before merge. A typed schema at the boundary plus a Playwright check on the critical path catches more shipped bugs than any single layer alone. Refactors get safer. Strict types and a healthy unit and component test suite let you change internals without breaking surface behaviour. Onboarding gets shorter. A new contributor can run one command, see green, and trust that CI will tell them if they break something. No one becomes the bottleneck. The pipeline enforces the standard for accessibility, performance, and i18n, so quality stops riding on a single contributor. Picking your testing shape The layers above tell you what to run. They don’t tell you how much weight to give each one. A solo dev shipping a Vite app needs a different mix than a fifty-engineer team coordinating across a dozen services. The industry argues about this in shapes. The classical Pyramid (Mike Cohn) puts most of the weight on unit tests and very little on E2E. Kent C. Dodds’ Trophy moves the weight to integration tests because frontend bugs live at the component-interaction layer. Spotify’s Honeycomb pushes weight onto integrated and contract tests because in a microservices world, isolation tests prove little and full E2E is brittle. The Ice-cream cone is the anti-pattern you end up with by accident: lots of slow E2E on top, almost nothing underneath. The right answer is “it depends,” but you can be precise about what it depends on. As web.dev puts it in Pyramid or Crab, “the testing strategy that’s right for your team is unique to your project’s context”. Pactflow, from the contract-testing camp, goes further: at scale, full E2E is a tax with diminishing returns once teams and services multiply. The four inputs that change the answer most: Team size. Six developers can keep a real E2E suite green together; sixty cannot. Coordination cost is what kills E2E suites at scale. Backend control. If you don’t own the backend, contract testing goes from “nice” to “the only way you can change anything safely”. Number of services in the flow. Each new service multiplies the surface that has to be set up, seeded, and reset for an E2E run. Deployment cadence. A daily-merge team can’t afford a flaky twenty-minute suite; a quarterly-release team can. Pick yours and the shape that fits will appear: The same pyramid that helps one team can block another from shipping. Pick the shape that fits your constraints. Picking your battles You don’t need every layer on day one. A reasonable order to add them: TypeScript strict + a fast linter + a formatter, wired into Lefthook so format and lint run on staged files at commit time. Vitest for utilities, run on PR. MSW handlers for any module that hits the network, shared between tests and the dev server. Playwright for the single most important user journey, with hydration and CSP listeners wired into a shared fixture. Contract testing the moment consumer and provider deploy on different cadences. Pact if you control both sides, OpenAPI validation if the provider already publishes a spec. Preview deployments and Lighthouse CI (light and dark). OpenTelemetry traces and metrics. Point the SDK at a local Jaeger via docker-compose the moment a “why is this slow?” question takes more than five minutes to answer. Same SDK in prod (different OTLP endpoint) once you have real users. Storybook + visual regression once the design system stabilises. Accessibility audits in component tests and E2E. Knip and bundle-size budgets once the codebase has weight. i18n drift checking once you ship a second locale. AI code review and SBOM generation once the project has external stakeholders to answer to: reviewers, customers, or compliance. Each layer should pay for itself in caught regressions or saved review time. Remove the ones that don’t. Supply chain defaults The pipeline above catches the bugs you write. None of it stops a compromised dependency from running code on your laptop. The 2025–2026 wave of npm attacks (Shai-Hulud, the Rspack postinstall cryptominer, the axios 1.14.1 hijack) made the package manager’s defaults a real part of your security posture. I use pnpm on every new project. Three of its settings do most of the work. 1. Lifecycle scripts blocked by default. Since pnpm 10, preinstall and postinstall scripts in dependencies do not run on pnpm install. You opt specific packages in via pnpm.onlyBuiltDependencies in package.json. Most historical supply chain payloads shipped through postinstall, so this default removes one of the biggest attack vectors. 2. minimumReleaseAge. A pnpm 10.16+ setting that refuses to resolve a published version until it is at least N minutes old. Set it to 1440 (one day) or 10080 (one week) in pnpm-workspace.yaml. Most compromised packages get detected and unpublished within hours, so a 24-hour delay covers the common published-and-pulled incidents. pnpm 11 makes one day the default. Use minimumReleaseAgeExclude for the few internal or first-party packages you need to install the moment they ship. 3. blockExoticSubdeps. Refuses transitive dependencies pinned to git repositories or tarball URLs. Closes a common path for typo-squatting and dependency confusion. A minimal pnpm-workspace.yaml for a new project: minimumReleaseAge: 1440 blockExoticSubdeps: true onlyBuiltDependencies: - esbuild - sharp Pair this with OSV-Scanner and Gitleaks in CI (layer 11 of the pipeline) and you cover both the install-time and the audit-time sides of supply chain security. Related resources If you want to read more or start implementing this: Tools Vite+ – unified toolchain from VoidZero (Vite, Rolldown, Vitest, Oxlint, Oxfmt, Tsdown) pnpm supply chain security – the full list of defaults and settings discussed above Vitest – including browser mode Playwright MSW – network-level API mocking for browser and Node Pact and PactFlow – consumer-driven and bi-directional contract testing Schemathesis, Dredd, Spectral – OpenAPI-based contract testing and linting Lefthook – fast Git hooks manager (modern Husky alternative) Storybook Knip Oxlint Biome Lighthouse CI Lunaria – i18n drift detection size-limit axe-core Syft – SBOM generation CodeRabbit, Greptile – AI code review Reference The Practical Test Pyramid – Ham Vocke’s canonical write-up of Mike Cohn’s pyramid. The Testing Trophy – Kent C. Dodds’ model for where to put the weight of your tests. Testing of Microservices (Honeycomb) – Spotify’s case for integrated tests over isolated unit tests in a microservices world. Pyramid or Crab? Find a testing strategy that fits – web.dev on choosing a shape for your context. Proving E2E tests are a scam – Pactflow’s contract-first counter-position. Contract Testing in Action – Marie Cruz & Lewis Prescott (Manning) on consumer-driven and bi-directional contracts in practice. GitHub Actions in Action – Kaufmann, Bos & de Vries (Manning) on workflows, reusable actions, matrix builds, and self-hosted runners. Frontend testing guide: 10 essential rules for naming tests","2026-04-25T18:07:54.197Z","019dc5d3-a141-771d-be4c-4fce2ee29fe6","https:\u002F\u002Falexop.dev\u002Fposts\u002Fa-modern-quality-pipeline-and-testing-strategy-for-frontend-projects\u002Findex.png","2026-04-25T00:00:00.000Z","a-modern-quality-pipeline-and-testing-strategy-for-frontend-projects","019d70dd-e3e7-76db-84a4-87b896dea004","alexop.dev","The article discusses the evolution of frontend quality pipelines and testing strategies, emphasizing the need for comprehensive checks to ensure code quality in increasingly complex environments. It highlights the importance of integrating various tools like Vite, Vitest, and Oxlint into a unified pipeline that can adapt to different frameworks, including Nuxt. The author advocates for a modern approach where the pipeline and testing strategy are designed together to enhance developer efficiency and code reliability.","A Modern Quality Pipeline and Testing Strategy for Frontend Projects","2026-04-25T18:08:02.112Z","https:\u002F\u002Falexop.dev\u002Fposts\u002Fmodern-frontend-quality-pipeline\u002F","b4cf663ff2cb6932a7923d040313f475d0f879aa91eb3f8a52678d36b150b7c9",[143,144,147,150,151],{"color":6,"id":35,"name":36,"slug":36},{"color":6,"id":145,"name":146,"slug":146},"019dc5d3-c054-70e2-bca4-08e2a2b9a096","vitest",{"color":6,"id":148,"name":149,"slug":149},"019d70de-3c07-76bf-9688-9619e1b0d427","testing",{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":32,"name":33,"slug":33},{"content":153,"createdAt":154,"id":155,"image":156,"isAffiliate":19,"isPublished":19,"publishedAt":157,"slug":158,"sourceId":51,"sourceName":52,"sourceType":53,"summary":159,"title":160,"updatedAt":161,"url":162,"urlHash":163,"tags":164},"Learn how to use composables in Nuxt effectively, avoid common SSR and state pitfalls, and build production-ready patterns in this practical 15-minute guide.","2026-04-25T18:07:52.417Z","019dc5d3-9a44-72c8-8f6c-0262bb4041d2","https:\u002F\u002Fapi.certificates.dev\u002Fstorage\u002FfLgc0NdkTT9Vgq2AhUNulkZwaj6txgVnAAOsHKFu.png","2026-04-22T07:00:00.000Z","composable-best-practices-in-nuxt","This article provides a practical guide on using composables in Nuxt, highlighting best practices to avoid common pitfalls related to server-side rendering (SSR) and state management. It aims to help developers build production-ready patterns efficiently.","Composable Best Practices in Nuxt","2026-04-25T18:08:01.170Z","https:\u002F\u002Fcertificates.dev\u002Fblog\u002Fcomposable-best-practices-in-nuxt?friend=MOKKAPPS","b506b0480c7b2d23a037e48443ae0e8d769398478e0b1f5d56539112166fea86",[165,166,169,172,173],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":167,"name":168,"slug":168},"019d6bd8-ca21-71c5-a236-37d94fe57d24","composition-api",{"color":6,"id":170,"name":171,"slug":171},"019da076-78fb-706b-9a4c-cee0c989cfff","state-management",{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":174,"name":175,"slug":175},"019d6bd8-fba5-743f-8f9f-4e23c0b31581","tutorial",{"content":177,"createdAt":178,"id":179,"image":180,"isAffiliate":18,"isPublished":19,"publishedAt":181,"slug":182,"sourceId":135,"sourceName":136,"sourceType":24,"summary":183,"title":184,"updatedAt":185,"url":186,"urlHash":187,"tags":188},"Your E2E tests pass. The page loads, buttons work. But open the browser console: Hydration failed because the server rendered HTML didn't match the client. This is a hydration mismatch. The server sent one thing and the client replaced it with something else. The page still works, so you don’t notice. Your tests don’t check for it, so they pass. What are SSR and hydration? SSR (server-side rendering) means the server generates HTML and sends it to the browser before JavaScript loads. Users see content before client code boots, and search engines can index it. Astro and Nuxt build on this model. Hydration is the next step: client JavaScript takes over the server-rendered HTML, attaching event handlers and state to the existing markup. The contract: the first client render must match what the server sent. When it does not match, the framework discards the server HTML and re-renders on the client. That re-render is a hydration mismatch. Common causes Anything that produces different HTML on client and server: Reading localStorage or window.matchMedia() during render Calling new Date() or Math.random() during render Formatting dates or numbers differently across server and client Rendering conditional branches based on browser-only state Theme toggles and locale formatting cause most of them. If you use Vue with SSR, the window is not defined error comes from the same root cause. VueUse has a pattern for it: A real bug I found I was working on an Astro page and my theme hook was reading browser state during the first render: function getInitialTheme(): Theme { const stored = localStorage.getItem(SITE.themeStorageKey); if (stored === \"light\" || stored === \"dark\") return stored; return window.matchMedia(\"(prefers-color-scheme: dark)\").matches ? \"dark\" : \"light\"; } export function useTheme() { const [theme, setTheme] = useState<Theme>(getInitialTheme); } The server defaulted to dark, but the browser picked light. React saw the mismatch, logged a hydration warning, and re-rendered from scratch. The page still worked, the button still existed. Normal E2E tests passed. The fix: start with a deterministic value, resolve browser state after mount. export function useTheme() { const [theme, setTheme] = useState<Theme>(\"dark\"); const [mounted, setMounted] = useState(false); useEffect(() => { const preferredTheme = getPreferredTheme(); document.documentElement.classList.toggle(\"dark\", preferredTheme === \"dark\"); setTheme(preferredTheme); setMounted(true); }, []); useEffect(() => { if (!mounted) return; const root = document.documentElement; root.classList.toggle(\"dark\", theme === \"dark\"); localStorage.setItem(SITE.themeStorageKey, theme); }, [mounted, theme]); return { theme, setTheme, toggleTheme: () => setTheme((t) => (t === \"dark\" ? \"light\" : \"dark\")) }; } The core idea Listen to the browser console during a Playwright test. If a hydration warning appears, fail the test. React and Vue log hydration mismatches to the console. You don’t check the console during automated tests, so this fixture does. The fixture Fixtures are Playwright's way of setting up and tearing down what each test needs. Built-in fixtures like `page` and `browser` come for free. You create custom ones with `base.extend()`. Each fixture runs when a test requests it and gets cleaned up afterward. The fixture below injects `hydrationErrors` and `runtimeErrors` into every test that asks for them. I first saw this approach in the npmx.dev open source project and adapted it for my Astro site. My version covers React and Vue hydration strings and catches uncaught runtime exceptions: const HYDRATION_ERROR_PATTERNS = [ \u002Fhydration failed because the server rendered html didn't match the client\u002Fi, \u002Fhydration completed but contains mismatches\u002Fi, \u002Fhydration text content mismatch\u002Fi, \u002Fhydration node mismatch\u002Fi, \u002Fhydration attribute mismatch\u002Fi, ]; function isHydrationError(text: string): boolean { return HYDRATION_ERROR_PATTERNS.some((pattern) => pattern.test(text)); } function toConsoleText(message: ConsoleMessage): string { return message.text().trim(); } export const test = base.extend<{ hydrationErrors: string[]; runtimeErrors: string[]; }>({ hydrationErrors: async ({ page }, use) => { const hydrationErrors: string[] = []; const handleConsole = (message: ConsoleMessage) => { const text = toConsoleText(message); if (isHydrationError(text)) { hydrationErrors.push(text); } }; page.on(\"console\", handleConsole); await use(hydrationErrors); page.off(\"console\", handleConsole); }, runtimeErrors: async ({ page }, use) => { const runtimeErrors: string[] = []; const handleConsole = (message: ConsoleMessage) => { const text = toConsoleText(message); if (message.type() === \"error\" && text.length > 0 && !isHydrationError(text)) { runtimeErrors.push(text); } }; const handlePageError = (error: Error) => { runtimeErrors.push(error.message); }; page.on(\"console\", handleConsole); page.on(\"pageerror\", handlePageError); await use(runtimeErrors); page.off(\"console\", handleConsole); page.off(\"pageerror\", handlePageError); }, }); export { expect }; Drop this into test\u002Fe2e\u002Ftest-utils.ts and import from there instead of @playwright\u002Ftest. Related: a full AI-driven QA workflow with Playwright: Using it test(\"home page hydrates cleanly\", async ({ page, hydrationErrors, runtimeErrors }) => { await page.goto(\"\u002F\", { waitUntil: \"domcontentloaded\" }); await expect(page.getByRole(\"heading\", { name: \"Home\" })).toBeVisible(); expect(hydrationErrors).toEqual([]); expect(runtimeErrors).toEqual([]); }); Start with your homepage. Add one interactive route, then one with a theme toggle or client-only widget. That surfaces most bugs. How npmx.dev does it at scale The npmx.dev project tests hydration correctness for every combination of user settings across every page, around 48 checks from a single fixture. They inject localStorage values via Playwright’s page.addInitScript() before navigation, simulating a returning user with saved preferences. Returning users with non-default settings trigger most hydration mismatches. const PAGES = [\"\u002F\", \"\u002Fabout\", \"\u002Fsettings\", \"\u002Fcompare\", \"\u002Fsearch\", \"\u002Fpackage\u002Fnuxt\"]; test.describe(\"color mode: dark\", () => { for (const page of PAGES) { test(`${page}`, async ({ page: pw, goto, hydrationErrors }) => { await injectLocalStorage(pw, { \"npmx-color-mode\": \"dark\" }); await goto(page, { waitUntil: \"hydration\" }); expect(hydrationErrors).toEqual([]); }); } }); async function injectLocalStorage(page: Page, entries: Record<string, string>) { await page.addInitScript((e: Record<string, string>) => { for (const [key, value] of Object.entries(e)) { localStorage.setItem(key, value); } }, entries); } They repeat this for every setting type, locale, accent color, background theme, package manager, relative dates, each with a non-default value. If any combination causes a hydration mismatch on any page, the test fails. Their fixture uses Vue-specific error strings (\"Hydration completed but contains mismatches\") while mine uses React patterns. The approach is the same, only the strings you match against change. More on how E2E tests relate to unit and integration tests: If you ship an SSR app and do not check for hydration errors in your browser tests, you have one in production right now.","2026-04-09T06:11:38.114Z","019d70de-1de7-70ea-8344-aded9a900a5c","https:\u002F\u002Falexop.dev\u002Fposts\u002Fhow-to-catch-hydration-errors-in-playwright-tests-astro-nuxt-react-ssr\u002Findex.png","2026-04-06T00:00:00.000Z","how-to-catch-hydration-errors-in-playwright-tests-astro-nuxt-react-ssr","The article discusses how to identify and address hydration errors in Playwright tests, particularly in applications using SSR with frameworks like Nuxt and Astro. It explains the concept of hydration mismatches, common causes, and offers solutions to ensure consistent rendering between server and client. The focus is on maintaining a deterministic initial state to prevent hydration warnings during testing.","How to Catch Hydration Errors in Playwright Tests (Astro, Nuxt, React SSR)","2026-04-09T06:11:45.745Z","https:\u002F\u002Falexop.dev\u002Fposts\u002Fcatch-hydration-errors-playwright-tests\u002F","a61a606d501f4750cf6e2136ea2210d1a0550f673021e364846f1ce1953dd9cd",[189,190,191,192],{"color":6,"id":32,"name":33,"slug":33},{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":148,"name":149,"slug":149},{"color":6,"id":62,"name":63,"slug":63},{"content":194,"createdAt":195,"id":196,"image":197,"isAffiliate":19,"isPublished":19,"publishedAt":198,"slug":199,"sourceId":200,"sourceName":201,"sourceType":202,"summary":203,"title":204,"updatedAt":205,"url":206,"urlHash":207,"tags":208},"If you have ever wired up a <label for="…"> to an <input id="…">, duplicated a component twice, and suddenly had duplicate IDs in the document, you already know why “just pick an id string” does not scale. Vue 3.5 added useId(), a small Composition API helper that generates unique-per-application identifiers that stay consistent between server and client renders. Despite the casual phrase “random ids,” useId() is not a source of cryptographic randomness. It produces deterministic, stable strings that are unique within your Vue app instance. That distinction matters: you get uniqueness and SSR safety without Math.random() or global counters that fight hydration. Why useId() exists Manual patterns break down quickly: Hard-coded IDs collide when the same component is used more than once. Math.random() in setup gives different values on server and client, which can cause hydration mismatches in SSR apps. Hand-rolled incrementing counters are easy to get wrong across async boundaries or shared modules. useId() centralizes ID generation in the framework so labels, aria-* attributes, form controls, and more stay valid and predictable. Use Cases for useId() Common situations where you need a DOM-safe unique string (not cryptographic randomness): Creating unique DOM element IDs for anchor links Associating a label and input in a reusable form field component Anchoring headings for in-page navigation (table of contents) Assigning a unique id to custom tooltip or popover elements Distinguishing multiple error callouts or alerts in a single view Generating ids for ARIA attributes (aria-labelledby, aria-describedby, etc.) Marking tab panels and tab buttons with unique relationships Disambiguating ids in nested reusable components (e.g., accordions, tabs) Generating ids for form controls created at runtime (e.g., survey builders) Basic usage Import useId from vue and call it once per logical id you need in the component. Wire the returned string to id, for, or ARIA attributes as usual. <script setup lang="ts"> import { useId } from "vue"; const nameFieldId = useId(); <\u002Fscript> <template> <form> <label :for="nameFieldId">Name<\u002Flabel> <input :id="nameFieldId" type="text" name="name" autocomplete="name" \u002F> <\u002Fform> <\u002Ftemplate> Each call to useId() in the same component instance receives a different id. Each instance of the component receives ids distinct from other instances. That matches what you want for accessible, reusable field groups. Multiple ids in one component Need a pair for email and password? Call useId() separately for each control (or group). <script setup lang="ts"> import { useId } from "vue"; const emailId = useId(); const passwordId = useId(); <\u002Fscript> <template> <div> <label :for="emailId">Email<\u002Flabel> <input :id="emailId" type="email" autocomplete="email" \u002F> <\u002Fdiv> <div> <label :for="passwordId">Password<\u002Flabel> <input :id="passwordId" type="password" autocomplete="current-password" \u002F> <\u002Fdiv> <\u002Ftemplate> SSR and hydration According to the official API docs, ids from useId() are stable across server and client renders. You can use them in Nuxt, custom SSR setups, or any code path that renders on the server first without worrying that the client will “reroll” different strings during hydration. Multiple Vue apps on one page If more than one Vue application mounts on the same document, you can reduce the chance of clashes between apps by setting an id prefix on each app: import { createApp } from "vue"; import AdminRoot from ".\u002FAdminRoot.vue"; const app = createApp(AdminRoot); app.config.idPrefix = "admin"; app.mount("#admin-app"); Use a different prefix per app instance so generated ids remain unique in the combined DOM. Important: do not call useId() inside computed() You should avoid invoking useId() inside a computed() getter. As with other composables, calling it there can cause instance conflicts because id registration is tied to component setup order. Instead, create the id at the top level of <script setup> (or setup()) and close over it inside computeds or methods. <script setup lang="ts"> import { computed, useId } from "vue"; const fieldId = useId(); \u002F\u002F Good: fieldId is fixed for this instance; computed only derives display logic. const describedBy = computed(() => `${fieldId}-hint`); <\u002Fscript> When you might still use something else useId() is extremely useful on the frontend, but it is not the answer for every problem. Here are some cases where you might be tempted to reach for useId() but should not: Entity primary keys from your API—these should be generated by your database or API server Stable keys in v-for when list identity should follow data (prefer a real id from your database model) Correlation IDs for API requests—they should be unpredictable or traceable by policy; use crypto.randomUUID() or server-issued IDs instead of useId() Security-sensitive tokens—use proper random or server-issued secrets For everyday UI plumbing, though, useId() removes a whole class of duplicate-id and SSR bugs with almost no API surface. Summary To sum up, useId() is a powerful tool for generating unique ids for your application. It's a simple, composable API that helps you avoid duplicate-id and SSR bugs with almost no API surface. Uniqueness - Unique per Vue application; distinct for each component instance and on every call SSR - Produces the same id on server and client—safe for hydration Multiple apps - Use app.config.idPrefix to prevent cross-app id collisions when mounting multiple apps PitfallDo - do not call inside computed(); generate the id in setup scope","2026-04-08T06:47:33.045Z","019d6bd8-a30c-720e-b82e-94ac62042df7","https:\u002F\u002Fblog.vueschool.io\u002Fwp-content\u002Fuploads\u002F2026\u002F04\u002Ffeature-v2.jpg","2026-04-03T17:04:54.000Z","generating-random-ids-in-vuejs","019d6bd5-87de-77ef-ac92-98aa56cda920","VueSchool","vueschool","The article discusses the new useId() helper introduced in Vue 3.5, which generates unique identifiers for DOM elements, ensuring consistency between server and client renders. It highlights the importance of unique IDs for accessibility and SSR safety, providing examples of common use cases and basic implementation in Vue components.","Generating Random IDs in Vue.js","2026-04-08T06:47:42.447Z","https:\u002F\u002Fblog.vueschool.io\u002Fvuejs-tutorials\u002Fgenerating-random-ids-in-vue-js\u002F?friend=MOKKAPPS","9174ab0b7d5dd5024c261a80c2b1895cb25c822f78f6b49a83356425d22df98a",[209,212,213,214],{"color":6,"id":210,"name":211,"slug":211},"019d6bd8-c9a8-7783-bd22-03145b355427","vue",{"color":6,"id":167,"name":168,"slug":168},{"color":6,"id":7,"name":8,"slug":8},{"color":6,"id":215,"name":216,"slug":216},"019d6bd8-caef-76b9-bacd-363e31e6d2a9","accessibility",1,20,{"tags":220},[221,226,228,233,237,241,244,248,252,256,260,264,269,273,277,281,285,289,293,297,301,305,309,313,317,321,325,327,329,333,337,341,345,349,353,355,359,363,367,371,375,379,383,387,391,395,399,403,407,411,415,419,423,427,431,435,439,443,447,451,455,459,462,466,470,474,478,482,486,489,493,497,501,505,509,513,517,519,523,527,531,535,537,541,545,549,553,555,557,561,563,567,571,575,579,581,585,589,592,596,600,604,608,612,616,618,620,624,627,631,635,640],{"articleCount":222,"color":6,"createdAt":223,"id":224,"name":225,"slug":225,"updatedAt":223},0,"2026-04-30T04:19:02.605Z","019ddc9c-954c-7703-8288-76d562fec577","accelerator",{"articleCount":217,"color":6,"createdAt":227,"id":215,"name":216,"slug":216,"updatedAt":227},"2026-04-08T06:47:43.120Z",{"articleCount":229,"color":6,"createdAt":230,"id":231,"name":232,"slug":232,"updatedAt":230},8,"2026-04-17T20:27:50.780Z","019d9d20-e07b-7685-9ebb-fae0b963f243","ai",{"articleCount":222,"color":6,"createdAt":234,"id":235,"name":236,"slug":236,"updatedAt":234},"2026-05-05T00:00:19.031Z","019df56f-8257-752e-a918-cdbb07c32b86","ai-agents",{"articleCount":217,"color":6,"createdAt":238,"id":239,"name":240,"slug":240,"updatedAt":238},"2026-06-01T12:00:14.713Z","019e830e-5378-722b-929b-a57d67bcf605","animation",{"articleCount":242,"color":6,"createdAt":243,"id":105,"name":106,"slug":106,"updatedAt":243},4,"2026-04-08T06:47:55.499Z",{"articleCount":229,"color":6,"createdAt":245,"id":246,"name":247,"slug":247,"updatedAt":245},"2026-04-17T19:35:19.300Z","019d9cf0-ca04-75bb-ad86-ce8da1c0be23","architecture",{"articleCount":222,"color":6,"createdAt":249,"id":250,"name":251,"slug":251,"updatedAt":249},"2026-04-23T12:00:11.615Z","019dba36-435e-765d-bfb2-c5be05362c27","astro",{"articleCount":222,"color":6,"createdAt":253,"id":254,"name":255,"slug":255,"updatedAt":253},"2026-06-01T20:00:15.958Z","019e84c5-cc55-7377-9e5d-77240ea8a880","authentication",{"articleCount":222,"color":6,"createdAt":257,"id":258,"name":259,"slug":259,"updatedAt":257},"2026-05-05T00:00:19.020Z","019df56f-824c-7031-9e34-2f47ad139eb6","automation",{"articleCount":222,"color":6,"createdAt":261,"id":262,"name":263,"slug":263,"updatedAt":261},"2026-06-11T16:00:12.019Z","019eb769-9af2-7471-b482-3f1a404f802e","azure",{"articleCount":265,"color":6,"createdAt":266,"id":267,"name":268,"slug":268,"updatedAt":266},2,"2026-04-17T20:27:50.776Z","019d9d20-e077-71cc-a605-8ac2a1566143","backend",{"articleCount":242,"color":6,"createdAt":270,"id":271,"name":272,"slug":272,"updatedAt":270},"2026-04-08T06:47:56.976Z","019d6bd9-010e-772d-b2f0-9378a042a676","best-practices",{"articleCount":222,"color":6,"createdAt":274,"id":275,"name":276,"slug":276,"updatedAt":274},"2026-06-06T00:00:11.711Z","019e9a3a-e5be-74b3-a01a-92c1f9427a2c","beta",{"articleCount":222,"color":6,"createdAt":278,"id":279,"name":280,"slug":280,"updatedAt":278},"2026-06-10T13:53:29.711Z","019eb1cf-3e6e-70f0-a761-0fb9b61d5675","budgeting",{"articleCount":217,"color":6,"createdAt":282,"id":283,"name":284,"slug":284,"updatedAt":282},"2026-06-16T16:11:31.438Z","019ed133-c4ee-70bb-8e21-7dc86e8adee4","bun",{"articleCount":222,"color":6,"createdAt":286,"id":287,"name":288,"slug":288,"updatedAt":286},"2026-05-19T20:00:14.559Z","019e41d3-1ade-77b0-9e4f-e9b97a6361ca","cdn",{"articleCount":217,"color":6,"createdAt":290,"id":291,"name":292,"slug":292,"updatedAt":290},"2026-06-27T16:00:12.237Z","019f09cf-5bcd-751c-8d46-9e123bd784af","clean-code",{"articleCount":217,"color":6,"createdAt":294,"id":295,"name":296,"slug":296,"updatedAt":294},"2026-05-16T18:48:40.777Z","019e321e-8248-75cc-9b69-59c2db6dd846","cli",{"articleCount":222,"color":6,"createdAt":298,"id":299,"name":300,"slug":300,"updatedAt":298},"2026-05-05T00:00:19.014Z","019df56f-8246-747f-be4b-a716863a93ea","cloud-platform",{"articleCount":217,"color":6,"createdAt":302,"id":303,"name":304,"slug":304,"updatedAt":302},"2026-06-16T16:11:31.289Z","019ed133-c458-74d8-a5c9-654f77837e7c","cloudflare",{"articleCount":217,"color":6,"createdAt":306,"id":307,"name":308,"slug":308,"updatedAt":306},"2026-07-27T18:11:45.304Z","019fa4c6-93c3-76ea-baa3-7d5fe541ac5b","cms",{"articleCount":217,"color":6,"createdAt":310,"id":311,"name":312,"slug":312,"updatedAt":310},"2026-04-30T04:19:02.045Z","019ddc9c-931c-743d-a1cb-e4449630fe47","collaboration",{"articleCount":217,"color":6,"createdAt":314,"id":315,"name":316,"slug":316,"updatedAt":314},"2026-06-10T13:53:29.567Z","019eb1cf-3dde-776d-9398-4863764f9ac3","community",{"articleCount":217,"color":6,"createdAt":318,"id":319,"name":320,"slug":320,"updatedAt":318},"2026-05-06T16:00:17.128Z","019dfe04-bee8-7384-bc58-a712f677807c","comparison",{"articleCount":217,"color":6,"createdAt":322,"id":323,"name":324,"slug":324,"updatedAt":322},"2026-05-14T12:00:21.354Z","019e265b-f569-71d8-a02a-a17ec8180644","component-design",{"articleCount":217,"color":6,"createdAt":326,"id":39,"name":40,"slug":40,"updatedAt":326},"2026-07-18T20:00:18.730Z",{"articleCount":242,"color":6,"createdAt":328,"id":167,"name":168,"slug":168,"updatedAt":328},"2026-04-08T06:47:42.915Z",{"articleCount":217,"color":6,"createdAt":330,"id":331,"name":332,"slug":332,"updatedAt":330},"2026-06-27T12:00:13.113Z","019f08f3-a538-74ed-82c5-038edce7100a","copilot",{"articleCount":222,"color":6,"createdAt":334,"id":335,"name":336,"slug":336,"updatedAt":334},"2026-04-25T12:00:12.674Z","019dc482-ff81-73ac-9b1c-6ad47f0afde0","data-management",{"articleCount":222,"color":6,"createdAt":338,"id":339,"name":340,"slug":340,"updatedAt":338},"2026-06-04T20:00:17.367Z","019e9438-e5d7-731f-bf47-8dcd86c6655c","data-privacy",{"articleCount":217,"color":6,"createdAt":342,"id":343,"name":344,"slug":344,"updatedAt":342},"2026-05-05T12:00:17.083Z","019df802-a8bb-775a-b843-93d883c7dfc5","data-science",{"articleCount":222,"color":6,"createdAt":346,"id":347,"name":348,"slug":348,"updatedAt":346},"2026-06-11T16:00:12.028Z","019eb769-9afb-7709-8a67-2a12f5e557c7","deepseek",{"articleCount":217,"color":6,"createdAt":350,"id":351,"name":352,"slug":352,"updatedAt":350},"2026-05-25T08:00:12.834Z","019e5e26-0e21-7366-87c7-0b1334180b0a","dependency-cruiser",{"articleCount":217,"color":6,"createdAt":354,"id":83,"name":84,"slug":84,"updatedAt":354},"2026-04-18T04:30:00.710Z",{"articleCount":265,"color":6,"createdAt":356,"id":357,"name":358,"slug":358,"updatedAt":356},"2026-04-21T12:00:11.373Z","019dafe9-8a6d-7218-81f1-37052cbe9b78","development",{"articleCount":217,"color":6,"createdAt":360,"id":361,"name":362,"slug":362,"updatedAt":360},"2026-06-29T08:00:12.101Z","019f1264-9f44-762d-b5fd-837839fdc586","devtools",{"articleCount":222,"color":6,"createdAt":364,"id":365,"name":366,"slug":366,"updatedAt":364},"2026-05-29T20:00:13.197Z","019e7552-ad8c-731f-ad8b-49253ed0e1b9","docker",{"articleCount":217,"color":6,"createdAt":368,"id":369,"name":370,"slug":370,"updatedAt":368},"2026-06-27T12:00:13.081Z","019f08f3-a518-7607-aa8c-782b4f10c2ed","documentation",{"articleCount":217,"color":6,"createdAt":372,"id":373,"name":374,"slug":374,"updatedAt":372},"2026-04-30T04:19:02.055Z","019ddc9c-9327-744f-a2da-31b64c7b6ba4","editor",{"articleCount":217,"color":6,"createdAt":376,"id":377,"name":378,"slug":378,"updatedAt":376},"2026-07-06T12:00:24.261Z","019f374d-0cc4-71ff-b906-ebaec8b0c343","eslint",{"articleCount":222,"color":6,"createdAt":380,"id":381,"name":382,"slug":382,"updatedAt":380},"2026-05-02T00:00:23.123Z","019de5fc-7e52-740a-807c-d322c373865b","firewall",{"articleCount":217,"color":6,"createdAt":384,"id":385,"name":386,"slug":386,"updatedAt":384},"2026-05-06T16:00:17.134Z","019dfe04-beee-7481-b8e7-4034640e840a","frameworks",{"articleCount":222,"color":6,"createdAt":388,"id":389,"name":390,"slug":390,"updatedAt":388},"2026-04-08T06:47:56.883Z","019d6bd9-00b2-7199-8e88-2530ef258032","generics",{"articleCount":217,"color":6,"createdAt":392,"id":393,"name":394,"slug":394,"updatedAt":392},"2026-07-27T18:11:45.390Z","019fa4c6-9419-7657-844e-58ec868ed664","git",{"articleCount":265,"color":6,"createdAt":396,"id":397,"name":398,"slug":398,"updatedAt":396},"2026-07-15T00:00:22.207Z","019f6313-12bf-7151-81f2-c8b43b09d979","html",{"articleCount":222,"color":6,"createdAt":400,"id":401,"name":402,"slug":402,"updatedAt":400},"2026-05-06T00:00:17.012Z","019dfa95-d673-71ef-be4a-8761512ffe5c","infrastructure",{"articleCount":217,"color":6,"createdAt":404,"id":405,"name":406,"slug":406,"updatedAt":404},"2026-06-16T16:11:31.264Z","019ed133-c43f-704f-8c1a-fbc299c8a3e5","javascript",{"articleCount":217,"color":6,"createdAt":408,"id":409,"name":410,"slug":410,"updatedAt":408},"2026-07-13T08:00:18.266Z","019f5a7d-bf5a-76e0-903a-c87435cc3e09","lazy-loading",{"articleCount":217,"color":6,"createdAt":412,"id":413,"name":414,"slug":414,"updatedAt":412},"2026-05-11T12:00:19.963Z","019e16e8-dbfa-76d6-bb2d-793aee049186","loading",{"articleCount":222,"color":6,"createdAt":416,"id":417,"name":418,"slug":418,"updatedAt":416},"2026-04-25T12:00:12.682Z","019dc482-ff8a-7698-8af5-95db54a26d6b","local-first",{"articleCount":217,"color":6,"createdAt":420,"id":421,"name":422,"slug":422,"updatedAt":420},"2026-05-14T12:00:21.370Z","019e265b-f579-71cd-84b2-ac385b5225ae","maintainability",{"articleCount":217,"color":6,"createdAt":424,"id":425,"name":426,"slug":426,"updatedAt":424},"2026-05-10T16:00:18.613Z","019e129e-34b4-7107-acfb-27f6b8604eb0","management",{"articleCount":217,"color":6,"createdAt":428,"id":429,"name":430,"slug":430,"updatedAt":428},"2026-06-27T12:00:13.065Z","019f08f3-a508-7334-aa03-12b281698ea8","markdown",{"articleCount":217,"color":6,"createdAt":432,"id":433,"name":434,"slug":434,"updatedAt":432},"2026-07-28T12:00:27.878Z","019fa899-02e6-758e-bdcb-8a4a923507df","mcp",{"articleCount":217,"color":6,"createdAt":436,"id":437,"name":438,"slug":438,"updatedAt":436},"2026-06-17T12:00:12.439Z","019ed574-0a96-7485-9c90-522e4be3e092","meta-tags",{"articleCount":222,"color":6,"createdAt":440,"id":441,"name":442,"slug":442,"updatedAt":440},"2026-05-26T08:00:14.598Z","019e634c-7105-7073-bc86-c32fa0a4401b","microfrontends",{"articleCount":222,"color":6,"createdAt":444,"id":445,"name":446,"slug":446,"updatedAt":444},"2026-05-19T16:00:13.516Z","019e40f7-5ccc-729c-92ba-bcc0aad8a16f","microvm",{"articleCount":222,"color":6,"createdAt":448,"id":449,"name":450,"slug":450,"updatedAt":448},"2026-05-05T00:00:19.025Z","019df56f-8250-768c-a659-b9f524ff902c","multi-tenant",{"articleCount":222,"color":6,"createdAt":452,"id":453,"name":454,"slug":454,"updatedAt":452},"2026-05-08T04:00:17.998Z","019e05be-4c4d-759e-a51e-8ac760f82f6d","nextjs",{"articleCount":217,"color":6,"createdAt":456,"id":457,"name":458,"slug":458,"updatedAt":456},"2026-04-17T19:35:19.293Z","019d9cf0-c9fc-76a0-8c4e-b818a89c3774","nitro",{"articleCount":460,"color":6,"createdAt":461,"id":32,"name":33,"slug":33,"updatedAt":461},27,"2026-04-08T06:47:55.381Z",{"articleCount":217,"color":6,"createdAt":463,"id":464,"name":465,"slug":465,"updatedAt":463},"2026-04-30T04:19:02.038Z","019ddc9c-9315-735e-a7e8-8424790e8859","nuxt-ui",{"articleCount":217,"color":6,"createdAt":467,"id":468,"name":469,"slug":469,"updatedAt":467},"2026-06-08T12:00:16.030Z","019ea71a-dc9d-7607-9cfa-df0f31ab5876","observability",{"articleCount":222,"color":6,"createdAt":471,"id":472,"name":473,"slug":473,"updatedAt":471},"2026-05-04T20:00:20.503Z","019df493-ce17-76ed-bd80-2a3914e0f409","open-source",{"articleCount":217,"color":6,"createdAt":475,"id":476,"name":477,"slug":477,"updatedAt":475},"2026-06-08T12:00:16.022Z","019ea71a-dc95-72b8-a7e3-70f9e2ac3710","opentelemetry",{"articleCount":242,"color":6,"createdAt":479,"id":480,"name":481,"slug":481,"updatedAt":479},"2026-05-18T12:00:14.389Z","019e3af5-4a35-705c-8ab1-4404b653e0e8","optimization",{"articleCount":217,"color":6,"createdAt":483,"id":484,"name":485,"slug":485,"updatedAt":483},"2026-05-28T20:00:13.016Z","019e702c-50d7-74eb-8849-8b1cebcf411e","orchestration",{"articleCount":487,"color":6,"createdAt":488,"id":62,"name":63,"slug":63,"updatedAt":488},16,"2026-04-08T06:47:42.920Z",{"articleCount":217,"color":6,"createdAt":490,"id":491,"name":492,"slug":492,"updatedAt":490},"2026-06-10T13:53:29.575Z","019eb1cf-3de7-7326-87d9-c55ad1c0fa39","personalization",{"articleCount":217,"color":6,"createdAt":494,"id":495,"name":496,"slug":496,"updatedAt":494},"2026-04-17T19:35:19.263Z","019d9cf0-c9de-70b2-9057-76d771c3379e","pinia",{"articleCount":222,"color":6,"createdAt":498,"id":499,"name":500,"slug":500,"updatedAt":498},"2026-05-02T00:00:23.112Z","019de5fc-7e47-7075-8aeb-9e90f7689f57","postgres",{"articleCount":222,"color":6,"createdAt":502,"id":503,"name":504,"slug":504,"updatedAt":502},"2026-05-19T20:00:14.575Z","019e41d3-1aee-70c8-a07c-cec870115d14","pricing",{"articleCount":217,"color":6,"createdAt":506,"id":507,"name":508,"slug":508,"updatedAt":506},"2026-05-10T16:00:18.603Z","019e129e-34aa-723b-a568-45737915c7bf","qa",{"articleCount":217,"color":6,"createdAt":510,"id":511,"name":512,"slug":512,"updatedAt":510},"2026-05-08T04:00:18.013Z","019e05be-4c5c-75ad-8df5-602b3db57983","react",{"articleCount":242,"color":6,"createdAt":514,"id":515,"name":516,"slug":516,"updatedAt":514},"2026-04-20T12:00:11.653Z","019daac3-2f85-7393-b891-9da3891267ca","reactivity",{"articleCount":242,"color":6,"createdAt":518,"id":42,"name":43,"slug":43,"updatedAt":518},"2026-04-17T20:27:50.585Z",{"articleCount":222,"color":6,"createdAt":520,"id":521,"name":522,"slug":522,"updatedAt":520},"2026-05-26T08:00:14.619Z","019e634c-711a-728f-9b63-20f2c8b37ccb","routing",{"articleCount":222,"color":6,"createdAt":524,"id":525,"name":526,"slug":526,"updatedAt":524},"2026-05-19T16:00:13.509Z","019e40f7-5cc4-72e1-8f8b-692dd29fc716","sandbox",{"articleCount":217,"color":6,"createdAt":528,"id":529,"name":530,"slug":530,"updatedAt":528},"2026-05-14T12:00:21.362Z","019e265b-f571-7677-a537-2f7e96a490bf","scalability",{"articleCount":222,"color":6,"createdAt":532,"id":533,"name":534,"slug":534,"updatedAt":532},"2026-05-04T20:00:20.521Z","019df493-ce28-75e9-93d5-13251407a27b","scanning",{"articleCount":242,"color":6,"createdAt":536,"id":125,"name":126,"slug":126,"updatedAt":536},"2026-04-27T08:00:12.420Z",{"articleCount":217,"color":6,"createdAt":538,"id":539,"name":540,"slug":540,"updatedAt":538},"2026-06-17T12:00:12.428Z","019ed574-0a8b-7566-976f-8c281c820ed0","seo",{"articleCount":217,"color":6,"createdAt":542,"id":543,"name":544,"slug":544,"updatedAt":542},"2026-06-17T12:00:12.433Z","019ed574-0a91-74d8-b806-56681bb4b477","sitemap",{"articleCount":217,"color":6,"createdAt":546,"id":547,"name":548,"slug":548,"updatedAt":546},"2026-07-18T16:00:27.576Z","019f75f5-23b8-72eb-a2bf-79dd1fed3863","software-development",{"articleCount":217,"color":6,"createdAt":550,"id":551,"name":552,"slug":552,"updatedAt":550},"2026-04-17T19:35:19.297Z","019d9cf0-ca00-749d-9101-1c63bf62e215","spas",{"articleCount":265,"color":6,"createdAt":554,"id":66,"name":67,"slug":67,"updatedAt":554},"2026-06-03T16:00:12.620Z",{"articleCount":5,"color":6,"createdAt":556,"id":7,"name":8,"slug":8,"updatedAt":556},"2026-04-08T06:47:43.020Z",{"articleCount":222,"color":6,"createdAt":558,"id":559,"name":560,"slug":560,"updatedAt":558},"2026-04-30T04:19:02.613Z","019ddc9c-9555-7544-a3e3-0605d2c1ea82","startup",{"articleCount":242,"color":6,"createdAt":562,"id":170,"name":171,"slug":171,"updatedAt":562},"2026-04-18T12:00:12.027Z",{"articleCount":222,"color":6,"createdAt":564,"id":565,"name":566,"slug":566,"updatedAt":564},"2026-06-06T00:00:11.717Z","019e9a3a-e5c5-76d3-86e4-576c151a87b3","storage",{"articleCount":217,"color":6,"createdAt":568,"id":569,"name":570,"slug":570,"updatedAt":568},"2026-06-17T12:00:12.446Z","019ed574-0a9e-7712-8bc5-a0102787fe48","structured-data",{"articleCount":217,"color":6,"createdAt":572,"id":573,"name":574,"slug":574,"updatedAt":572},"2026-05-10T16:00:18.597Z","019e129e-34a4-771a-844d-09a7edefcd64","tdd",{"articleCount":222,"color":6,"createdAt":576,"id":577,"name":578,"slug":578,"updatedAt":576},"2026-06-04T20:00:17.351Z","019e9438-e5c6-7681-8704-897c7b499eb4","terms-of-service",{"articleCount":265,"color":6,"createdAt":580,"id":148,"name":149,"slug":149,"updatedAt":580},"2026-04-09T06:11:45.799Z",{"articleCount":217,"color":6,"createdAt":582,"id":583,"name":584,"slug":584,"updatedAt":582},"2026-06-16T16:11:31.088Z","019ed133-c390-75bf-8f1a-5c57cd221f14","threejs",{"articleCount":222,"color":6,"createdAt":586,"id":587,"name":588,"slug":588,"updatedAt":586},"2026-05-02T00:00:23.130Z","019de5fc-7e59-7426-8d46-e79e4bcf0d56","tls",{"articleCount":590,"color":6,"createdAt":591,"id":174,"name":175,"slug":175,"updatedAt":591},10,"2026-04-08T06:47:55.591Z",{"articleCount":242,"color":6,"createdAt":593,"id":594,"name":595,"slug":595,"updatedAt":593},"2026-04-08T06:47:56.778Z","019d6bd9-0049-72ba-8cfa-139b1c1b249d","typescript",{"articleCount":597,"color":6,"createdAt":556,"id":598,"name":599,"slug":599,"updatedAt":556},5,"019d6bd8-ca8b-709c-b9a5-77d4910da162","ui-components",{"articleCount":217,"color":6,"createdAt":601,"id":602,"name":603,"slug":603,"updatedAt":601},"2026-05-11T12:00:19.969Z","019e16e8-dc00-714d-911a-a5bf39238587","user-experience",{"articleCount":217,"color":6,"createdAt":605,"id":606,"name":607,"slug":607,"updatedAt":605},"2026-05-18T12:00:14.379Z","019e3af5-4a29-759a-81b0-b6d502b2449e","v-memo",{"articleCount":222,"color":6,"createdAt":609,"id":610,"name":611,"slug":611,"updatedAt":609},"2026-04-30T04:19:02.228Z","019ddc9c-93d3-763e-ad3c-d3ad78642de7","vercel",{"articleCount":217,"color":6,"createdAt":613,"id":614,"name":615,"slug":615,"updatedAt":613},"2026-07-13T08:00:18.274Z","019f5a7d-bf61-746b-a44b-5c0a16ff57d3","video",{"articleCount":242,"color":6,"createdAt":617,"id":35,"name":36,"slug":36,"updatedAt":617},"2026-04-17T19:35:19.289Z",{"articleCount":217,"color":6,"createdAt":619,"id":145,"name":146,"slug":146,"updatedAt":619},"2026-04-25T18:08:02.132Z",{"articleCount":217,"color":6,"createdAt":621,"id":622,"name":623,"slug":623,"updatedAt":621},"2026-06-27T12:00:13.107Z","019f08f3-a532-7049-a02c-c17a4fd99306","vscode",{"articleCount":625,"color":6,"createdAt":626,"id":210,"name":211,"slug":211,"updatedAt":626},32,"2026-04-08T06:47:42.793Z",{"articleCount":217,"color":6,"createdAt":628,"id":629,"name":630,"slug":630,"updatedAt":628},"2026-04-18T12:00:12.007Z","019da076-78e6-76bd-b0d4-4e0597d36378","vue-router",{"articleCount":222,"color":6,"createdAt":632,"id":633,"name":634,"slug":634,"updatedAt":632},"2026-05-04T20:00:20.510Z","019df493-ce1d-7039-811a-ed57bf081d26","vulnerability",{"articleCount":636,"color":6,"createdAt":637,"id":638,"name":639,"slug":639,"updatedAt":637},3,"2026-05-05T12:00:17.078Z","019df802-a8b6-74d2-a0cd-b0509cf502fa","web-development",{"articleCount":636,"color":6,"createdAt":641,"id":642,"name":643,"slug":643,"updatedAt":641},"2026-05-10T16:00:18.576Z","019e129e-3490-7739-a218-5454a8c15d6e","workflow"]