React JSON Schema Form Alternative: FormEngine vs RJSF Bundle Size Comparison

When we developed FormEngine, we often heard: "How are you different from react-jsonschema-form?"

Fair question. Both libraries:

• React-based
• Work with JSON: RJSF uses JSON Schema to describe forms, FormEngine uses its own JSON format
• Support Material UI
• Open to customization

But there's one fundamental architectural difference that radically affects bundle size:

• RJSF — adds UI components on top of the base library
• FormEngine — completely replaces UI components during integration

Let's see how this works in practice.

We tested two realistic forms:

Login Form (Simple Case)

• Email + Password fields
• Basic validation
• Submit button

Booking Form (Complex Case)

• Multi-step form
• Conditional logic
• Different field types (text, dates, selects)
• Validation at each step

Test Conditions:

• Production build (minified + gzipped)
• Vite as bundler
• Tree-shaking enabled
• Default configurations
• Two variants: with default UI (FormEngine Core has no default UI, React Suite v5 was used) and with Material UI

Full methodology: formengine.io/documentation/bundle-size-comparison

Here's what happens when switching from default UI to Material UI:

Why Does FormEngine Become Lighter?

Comparison of Different UI Library Usage:

FormEngine + React Suite by default:
├── Core engine (~50 KB)
├── React Suite components (~190 KB)
├── React Suite CSS (~52 KB)
= 244 KB total

FormEngine + MUI:
├── Core engine (~50 KB)
├── MUI components (already in project)
├── Minimal CSS (~0.2 KB)
= 188 KB total (-23%)

Why Does RJSF Become Heavier?

Additive Architecture:

RJSF by default:
├── Core engine (~156 KB)
├── Bootstrap CSS (~19 KB)
= 175 KB total

RJSF + MUI:
├── Core engine (~156 KB)
├── MUI adapter layer (~20 KB)
├── MUI components (already in project)
├── Minimal CSS (~0.2 KB)
= 232 KB total (+32%)

MUI is added on top, not replacing the base components.

A difference of 35–43 KB might seem small, but let's translate it into seconds:

On Slow 3G (Emerging Markets)

On 4G (Typical Conditions)

Conclusion: If you have users on slow networks (emerging markets, mobile internet in subways, poor WiFi) — every second is critical.

You can't say "FormEngine is better than RJSF" or vice versa. The right answer depends on your project:

We initially designed FormEngine for embedding into existing projects with already installed UI libraries. This architectural decision paid off:

• Minus 23–37% bundle when integrating with MUI compared to React Suite
• Complete UI replacement instead of layering
• Zero overhead for components

This is one of the most important differences that affects not only DX but also bundle size:

RJSF: Separate Schemas (Data Schema + UI Schema)

// data-schema.json — describes data
{
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "format": "email"
    },
    "password": {
      "type": "string",
      "minLength": 8
    }
  },
  "required": ["email", "password"]
}

// ui-schema.json — describes UI
{
  "email": {
    "ui:widget": "email",
    "ui:placeholder": "Enter your email"
  },
  "password": {
    "ui:widget": "password",
    "ui:help": "Min 8 characters"
  }
}

Pros of Separation:

• Standardization — JSON Schema is an open standard
• Reusability — one data schema can be used in different UIs
• Validation independent of UI — can validate on backend with the same schema
• Ecosystem — many tools for JSON Schema (generators, validators, documentation)
• Separation of concerns — logic separate from presentation

Cons of Separation:

• Synchronization — need to maintain two files in sync
• Verbosity — more code for simple forms
• Learning curve — need to know both formats

FormEngine: Unified JSON (Data + UI in One JSON)

// form.json — everything in one place
{
  "components": [
    {
      "type": "TextField",
      "key": "email",
      "label": "Email",
      "placeholder": "Enter your email",
      "validation": {
        "required": true,
        "email": true
      }
    },
    {
      "type": "PasswordField",
      "key": "password",
      "label": "Password",
      "help": "Min 8 characters",
      "validation": {
        "required": true,
        "minLength": 8
      }
    }
  ]
}

Pros of Unification:

• Simplicity — one file, one source of truth
• Less code — no duplication of field names
• Conditional logic — easier to describe dependencies between fields
• DX — faster to write and understand
• Compactness — less boilerplate

Cons of Unification:

• No standardization — proprietary FormEngine format
• Vendor lock-in — harder to migrate to another library
• Validation only on client — can't reuse schema on backend directly
• Fewer tools — no JSON Schema ecosystem
• UI and data coupling — UI changes can affect logic

Impact on Bundle Size

RJSF (separate schemas):
✦ JSON Schema validator (~15-20 KB)
✦ Standard ajv (might already be in project)
✦ UI Schema parser (~5 KB)
✦ Mapping layer between schemas (~3-5 KB)

Total: ~23-30 KB overhead

FormEngine (unified schema):
✦ Custom validator (~8-12 KB)
✦ Less parsing
✦ No ajv reuse
✦ Proprietary format

Total: ~8-12 KB overhead

Conclusion: FormEngine saves ~10–15 KB on schema parsing, but loses standardization benefits.

Important note: Although FormEngine uses a proprietary format, it is fully open and documented. This means you can study the specification, write your own parsers or form generators, without depending on closed solutions.

Imagine a form where the "Phone" field is shown only if "Contact by phone" is selected:

RJSF Approach

// data-schema.json
{
  "type": "object",
  "properties": {
    "contactMethod": {
      "type": "string",
      "enum": ["email", "phone"]
    },
    "phone": {
      "type": "string",
      "pattern": "^[0-9]{10}$"
    }
  },
  "dependencies": {
    "phone": ["contactMethod"]
  },
  "if": {
    "properties": {
      "contactMethod": { "const": "phone" }
    }
  },
  "then": {
    "required": ["phone"]
  }
}

// ui-schema.json
{
  "phone": {
    "ui:widget": "phone",
    "ui:options": {
      "conditional": {
        "show": {
          "field": "contactMethod",
          "is": "phone"
        }
      }
    }
  }
}

Problem: The condition is described in two places! Data schema says "phone required if...", UI schema says "show phone if...". Need to synchronize.

FormEngine Approach

{
  "components": [
    {
      "type": "RadioGroup",
      "key": "contactMethod",
      "label": "Contact method",
      "options": [
        { "value": "email", "label": "Email" },
        { "value": "phone", "label": "Phone" }
      ]
    },
    {
      "type": "PhoneField",
      "key": "phone",
      "label": "Phone number",
      "conditional": {
        "show": "{{contactMethod === 'phone'}}"
      },
      "validation": {
        "required": "{{contactMethod === 'phone'}}",
        "pattern": "^[0-9]{10}$"
      }
    }
  ]
}

Advantage: Condition described once. UI and validation automatically synchronized.

We've published all data, including scenarios where RJSF is faster. This is our principle: honesty is more important than marketing.

If you find errors in the tests — open an issue, we'll fix it.

All tests are available and reproducible:

GitHub Repository: github.com/optimajet/formengine/tree/master/community/examples/bundle-size

Full Report: formengine.io/documentation/bundle-size-comparison

How to Run Yourself:

git clone https://github.com/optimajet/formengine.git
cd formengine/community/examples/bundle-size
npm install
npm run build
npm run analyze

What You'll Get:

• Bundle size report
• Chunk visualization
• Duplicate packages detection
• Tree-shaking analysis

If you found errors in tests, want to add new scenarios, or disagree with conclusions — write to us:

• GitHub Issues
• hello@optimajet.com

There's no universal winner. And that's good!

• RJSF — excellent choice for quick start and JSON Schema purists
• FormEngine — optimal for integration into existing projects with UI kits

Choose based on your context, not marketing.