SurveyJS Form Library: JSON schemas rendered by four framework packages

survey-core holds the model, the framework package only renders

The architecture is a deliberate split, and it is the first thing to understand before you install anything. The framework-independent survey-core package carries the form model, validation, conditional logic, calculations, navigation, and localization. The framework packages do one job: they render that model. survey-react-ui renders it in React, survey-angular-ui in Angular, survey-vue3-ui in Vue 3, and survey-js-ui in plain JavaScript. Installing a rendering package brings survey-core with it, so you never install the core directly. The practical payoff is that form behaviour is testable without a framework in the loop, and the cost is that any mismatch between the core version and a rendering package shows up as behaviour you did not write. The definitions themselves can be written by hand, generated with AI, or assembled visually in SurveyJS Creator, an embeddable drag-and-drop form builder, so the JSON is an output format rather than something you must type from the start.

Four npm packages, and the Vue entry targets Vue 3

Installation is a single command per framework, and the choice is made at install time.

npm install survey-react-ui
npm install survey-angular-ui
npm install survey-vue3-ui
npm install survey-js-ui

Two details are worth reading twice. The Vue entry is survey-vue3-ui, and its documentation link is titled for Vue.js generally, so a Vue 2 codebase has no matching package in this table. And the plain JavaScript package exists for pages with no framework at all, which is the shortest path to a first form if you are evaluating the library. Because the packages render a shared model, mixing two of them in one application means two renderers over one schema, and the README does not describe that arrangement, so treat it as untested.

No SurveyJS backend, so storage and validation of answers are yours

The How It Works section is five steps, and step four is the one that decides your architecture: create or load a JSON form definition, render it, collect responses in the browser, send the submitted data to your backend, then store it in the database or service of your choice. The library runs in the browser and does not require a SurveyJS backend, which is why you keep control of the definitions, the responses, and the storage. What lands on your side of the line is real work: the submit endpoint, the table that holds answers, the rules that decide whether a submitted response is acceptable, and anything to do with payments or third-party services. Backend integration examples exist for PHP, ASP.NET Core, and Node.js, and dropdown choices can be loaded from web services, so an option list can come from your own API rather than from the definition.

The JSON definition is the entire surface area of the form

Form content and structure, validation, conditional logic, navigation, and appearance are all expressed in one JSON form definition, and the feature list shows how much behaviour rides on it. There is conditional visibility, branching, calculated values, and expression-based logic, so a question can appear only when an earlier answer demands it and a total can be computed from other fields. There are dynamic panels, repeating question groups, carry-forward responses, and text piping, which is how one answer is reused inside a later question. Navigation has multiple modes for long forms, and validation, partial submissions, auto-save, and lazy loading are part of the same definition. The upside is that a form becomes data you can store, edit, and ship without rebuilding. The cost is that every behaviour change is a schema change, and a mistake in that schema shows up in the browser rather than at build time. The control catalogue is a separate layer of the same definition: 20 or more built-in question and input types, custom question types and input components, electronic signature and image capture, and reusable composite questions built from other questions.

Localization for 50+ languages is community-supported

The phrase to notice in that section is community-supported. Localization covers more than 50 languages, with multi-language forms and automatic locale selection, plus right-to-left language support, accessible input controls, and keyboard navigation. Two consequences for whoever ships a form. If your users speak a language that no one has contributed yet, the count does not help you, and you would be writing that locale yourself. And right-to-left support is a layout property, not a string property, so it has to be tested with the real form rather than assumed from a translated label. Accessibility is covered in the same section and is backed by a dedicated test directory in the repository, which is a good sign that the claims are checked somewhere.

Styling runs through CSS variables and three theme adapters

Appearance is handled by a shared design token system built on CSS variables, with built-in themes that accept custom branding, and adapters for Bootstrap, Material UI, and shadcn/ui. Below that level you get custom question rendering, reusable UI components, and configurable layouts, navigation controls, validation messages, and form behaviour. The practical test is which design system your application already uses. If it is one of those three, the adapter saves you from restyling every question type by hand. If it is something else, you are writing CSS against the token variables yourself, and the tokens are the contract you depend on, so a change to them in a future release is a change to your stylesheet.

Cloning the repo installs Chromium before you run anything

The root package.json is not the published library. It is named survey-library, marked private, and carries version 1.12.17, while the releases the project publishes are v3.1.2 and v2.5.45 from 2026-09-29 and v3.1.1 from 2026-09-23, which means two release lines ship side by side. Three scripts matter to anyone who clones it.

{
  "scripts": {
    "lint": "eslint . --ext .vue,.js,.jsx,.cjs,.mjs,.ts,.tsx,.cts,.mts --max-warnings=0",
    "pre-push-check": "npm run test --prefix packages/survey-core",
    "postinstall": "playwright install chromium"
  }
}

A dependency install therefore downloads a browser, and the lint gate treats any warning as a failure. The pre-push hook runs the survey-core tests on their own, which tells you where the model behaviour is verified.

Tests are split into four suites, and CI runs on Azure Pipelines

The repository layout shows the shape of the quality process. There are accessibilityTests/, functionalTests/, e2e/, and visualRegressionTests/ directories, plus a tests/ directory and a screenshots/ folder, with playwright.config.ts at the root. The dev dependencies line up: axe-core and axe-playwright for the accessibility suites, and devextreme-screenshot-comparer for comparing rendered output. CI lives in azure-pipelines/, and the README badge points at a build definition on the master branch. Commit hygiene is automated too, with husky, lint-staged, and commitlint.config.mjs, and prepare runs husky install. For a contributor that means the first push is checked by a commit message convention, not only by tests. Documentation sources sit in docs/, with templates/, utils/, build-scripts/, rollup.helpers.mjs, tsconfig.json, and .eslintrc.js around them, while CONTRIBUTING.md, CODE_OF_CONDUCT.md, CHANGELOG.md, and a CLAUDE.md file sit at the root.

Editorial conclusion

Use it when a form has to change without a frontend rebuild, when you want branching, calculated values, or partial submissions without writing them, and when you would rather own the database than rent a form backend. Do not expect a server to appear: there is no SurveyJS backend, so the submit handler, the storage, and the answer schema are yours to build and secure. Two checks before you commit. First, note that the Vue package listed targets Vue 3, so an older Vue codebase has no matching entry in the installation table. Second, note that localization is community-supported for 50+ languages, so verify the quality of the locale you need instead of trusting the count.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. surveyjs/survey-library on GitHub