Drupal is one of the most capable content management systems ever built. The entity/field system is remarkably flexible. Taxonomy, revisions, content workflows, permissions — Drupal solved these problems years before most headless CMS tools existed.
But there are real reasons teams look for alternatives.
PHP hosting is more complex and expensive than Node.js hosting in 2026. A Drupal site needs PHP-FPM, a web server (Apache or Nginx), Composer, and often a separate process for cron jobs. A Node.js app needs node and a port. The deployment story isn’t even close.
Drupal’s learning curve is steep. The hook system, render arrays, plugin architecture, configuration management — a new developer needs weeks to become productive. With Node.js tooling, a junior developer can be shipping features on day one.
Development velocity is slower. PHP doesn’t have the same hot-reload, TypeScript type-checking, and instant-feedback development loops that Node.js developers expect. The Drupal admin interface, while powerful, requires navigating dozens of configuration pages to accomplish what could be a few lines of JSON.
These are legitimate pain points. But most Drupal alternatives throw away everything that makes Drupal good. They start from scratch with simpler content models, fewer features, and none of Drupal’s battle-tested architectural patterns.
What if you didn’t have to choose?
Drupal’s architecture, on Node.js
drop.js implements Drupal’s core architectural concepts natively in Node.js with TypeScript. Not a Drupal wrapper, not a PHP bridge — a ground-up implementation that uses the same patterns but runs on the Node.js runtime.
npx create-drop-app my-site
cd my-site
npm run dev
# 220+ API endpoints ready
# 60-page admin UI runningIf you’ve built Drupal sites, the concepts map directly. If you haven’t, they’re still good patterns — Drupal just happened to prove them out over 20+ years.
Concept mapping: Drupal to drop.js
Entity/Field system
In Drupal, everything is an entity with configurable fields. Nodes, taxonomy terms, users, media — they’re all entities. This is the core abstraction that makes Drupal so flexible.
drop.js uses the same concept. Content types are entities. Each entity has fields with defined types. The difference is how you define them.
Drupal — fields are configured through the admin UI or via PHP configuration arrays, exported as YAML:
# Drupal config/sync/field.storage.node.field_body.yml
langcode: en
status: true
id: node.field_body
field_name: field_body
entity_type: node
type: text_long
settings: {}
cardinality: 1drop.js — fields are defined in JSON config files:
{
"name": "article",
"label": "Article",
"fields": {
"body": {
"type": "text_long",
"label": "Body",
"required": false
},
"summary": {
"type": "string",
"label": "Summary",
"maxLength": 300
}
}
}Same concept, same field types, but JSON instead of YAML/PHP and no admin UI clicking required. The JSON files live in your repository, are reviewable in pull requests, and can be managed across environments with git.
Content types and bundles
Drupal uses “bundles” to create variations of entity types. A “node” entity can have bundles like “article,” “page,” or “event” — each with different fields.
drop.js follows the same pattern. You define content types (bundles) in JSON, each with their own field configuration. The underlying entity system handles storage, revision tracking, and API generation identically regardless of the bundle.
Taxonomy
Drupal’s taxonomy system — vocabularies containing hierarchical terms — is one of its best features. It’s simple enough for tagging but powerful enough for complex classification hierarchies.
drop.js implements the same system. You define vocabularies, create terms with parent/child relationships, and reference them from content via entity_reference fields.
{
"vocabulary": "categories",
"terms": [
{
"name": "Engineering",
"children": [
{ "name": "Frontend" },
{ "name": "Backend" },
{ "name": "DevOps" }
]
},
{
"name": "Design",
"children": [
{ "name": "UI Design" },
{ "name": "UX Research" }
]
}
]
}Hierarchical terms, vocabulary grouping, term references from content — it all works the way a Drupal developer would expect.
Views (query builder)
Drupal’s Views module is arguably the most important contributed module in Drupal’s history. It provides a query builder with filters, sorts, pagination, and relationship handling.
drop.js includes a query builder that covers the same territory: filters, sorts, pagination, and field selection across content types and their references.
# Query articles filtered by taxonomy, sorted by date, paginated
GET /api/articles?filter[category]=engineering&sort=-created&page=1&limit=10It’s not a 1:1 replica of Drupal Views — there’s no visual query builder in the admin UI. But the API-level functionality serves the same purpose for headless architectures where views are consumed by frontend code, not rendered server-side.
Paragraphs
Drupal’s Paragraphs module changed how teams build flexible page layouts. Instead of a single body field, editors compose pages from reusable content components: hero sections, text blocks, image galleries, CTAs, embedded media.
drop.js includes paragraphs as a built-in field type:
{
"name": "landing_page",
"label": "Landing Page",
"fields": {
"sections": {
"type": "paragraphs",
"label": "Page Sections",
"allowed_types": ["hero", "text_block", "image_gallery", "cta", "testimonial"]
}
}
}Each paragraph type has its own field configuration. Editors can add, reorder, and remove paragraph items. The API returns them as structured, typed arrays — ready for your React, Vue, or Svelte components to render.
Revisions
Drupal tracks revisions on every content entity by default. You can view the revision history, compare changes, and revert to any previous version.
drop.js does the same. Every content save creates a revision. The API exposes revision history, and the admin UI lets you browse and restore previous versions. This isn’t a plugin or add-on — it’s built into the entity system.
Permissions and RBAC
Drupal’s permission system is granular: you can control access to view, create, edit, and delete each content type per role. Custom permissions are easy to define.
drop.js ships with 19 permissions and role-based access control. You can define roles with specific permission sets and assign them to users. The permission checks happen at the API level, so they apply whether content is accessed via REST, GraphQL, or JSON:API.
URL aliases
Drupal’s path module and Pathauto generate clean URLs from patterns. /node/42 becomes /blog/2026/my-article-title.
drop.js includes URL alias support with pattern-based generation. You define alias patterns per content type, and the system generates and resolves them automatically.
Content workflow
Drupal’s Content Moderation module provides workflow states: draft, published, archived, plus custom states. Content moves through states based on permissions and editorial process.
drop.js includes a four-state workflow out of the box: draft, in review, published, and archived. State transitions are permission-controlled, and the revision system tracks which user moved content to each state.
draft → in_review → published → archivedThis is built-in. In the Strapi ecosystem, comparable workflow features require an Enterprise license. In Drupal, Content Moderation is in core but requires configuration. In drop.js, it works from the first install.
The migration escape hatch
Here’s the feature that no other Node.js CMS can match: drop.js uses a database schema that is 100% compatible with Drupal 11.
You can export your drop.js SQLite database and import it directly into a Drupal 11 installation. Your content, taxonomy terms, users, revisions, URL aliases — everything transfers. No migration scripts. No data transformation. No field mapping.
# Export from drop.js
cp data/drop.sqlite drupal-export.sqlite
# Import into Drupal 11
# (after configuring Drupal to use the SQLite database)
drush cr
drush updbThis matters for several scenarios:
Enterprise graduation. You start with drop.js for speed and simplicity. The project grows, and the organization needs Drupal’s contributed module ecosystem, enterprise hosting on Acquia or Pantheon, or a larger pool of Drupal developers. You migrate the database directly — no data loss, no content freeze.
Parallel development. Run drop.js for your headless frontend API while maintaining a Drupal backend for specific needs. The databases are interchangeable.
Risk mitigation. Choosing a smaller open-source project always carries risk. If drop.js development slows down, your data isn’t trapped. Drupal is a 20-year-old project with enterprise backing. Your database works there too.
No other headless CMS — Strapi, Payload, Directus, Sanity, Contentful, none of them — can offer this level of data portability to an established, enterprise-grade CMS.
What you give up
Being honest about trade-offs: drop.js is not Drupal, and there are things you lose.
Contributed modules. Drupal has thousands of contributed modules for everything from SEO to e-commerce to advanced access control. drop.js has a fixed feature set. If you need something it doesn’t include, you build it yourself.
Theming layer. Drupal can render full HTML pages with Twig templates. drop.js is headless-only. If you need server-rendered pages from the CMS itself, drop.js isn’t the right tool.
Community size. Drupal has a massive global community, regular conferences, and extensive documentation. drop.js is newer and smaller. Finding help is harder.
Admin UI depth. Drupal’s admin interface, while complex, is extraordinarily capable. Contextual links, in-place editing, layout builder, configurable views-based admin pages — the admin experience is deeper than what drop.js offers.
Maturity. Drupal has handled 20 years of edge cases. drop.js implements the same patterns but hasn’t been battle-tested at the same scale. Bugs and gaps are more likely.
Who should consider this
drop.js makes sense if you’re in one of these situations:
You know Drupal’s architecture but want Node.js tooling. The entity/field system, taxonomy, paragraphs, revisions — you want these patterns without PHP. Your team writes TypeScript and deploys to Vercel or Railway, not Acquia or Pantheon.
You’re starting a new project that might need Drupal later. The database compatibility gives you a real migration path. Start fast with Node.js, graduate to Drupal if the project demands it.
You need enterprise content features without enterprise pricing. Content workflows, multilingual support, RBAC, revisions, hierarchical taxonomy — these are built-in, not paywalled. Self-host on a $5/month VPS and get features that cost hundreds per month on other platforms.
You want a single package with everything included. No plugin marketplace to browse, no compatibility matrix to maintain, no third-party dependencies to audit. One npm install, 220+ endpoints, 60 admin pages, 18 field types.
Drupal is still the right choice for many projects — especially those that need its module ecosystem, enterprise hosting options, or server-rendered output. But if you want Drupal’s proven content architecture running on modern Node.js infrastructure, drop.js is the only tool that delivers it with a genuine migration path back to Drupal if you ever need it.