No Views UI: fetching content in Craft when your hands expect Drupal Views
The moment that made Craft feel genuinely different from Drupal wasn't a missing feature — it was a missing screen. I went looking for the equivalent of the Views UI, that page where you click together a filter, a sort, a pager, and export it to config, and there simply isn't one. In Craft you fetch content by writing a query, in Twig or PHP. After the initial "wait, where is it," I've come around: for a developer, this is mostly better. For a site builder, it's a real loss worth naming.
Element queries: the query API is the default, not the escape hatch
Craft's core content-fetching tool is the element query — a fluent, chainable API. Three steps: create one, set params, execute. In Twig:
{% set posts = craft.entries()
.section('news')
.orderBy('postDate DESC')
.limit(10)
.all() %}The PHP mirror is Entry::find()->section('news')->limit(10)->all(). You execute with .all(), .one(), .count(), .exists(), .ids(), or .collect() (a Laravel Collection). You filter and shape with .section(), .orderBy(), .relatedTo(), .search(), and — the nice part — custom-field params like .myCustomField(value). N+1 problems get solved with .with(['relatedThing']) eager-loading, and .cache() caches the result.
If you're a Drupal dev, this should feel eerily familiar — it's the entityQuery / entity-loading code you already drop to when Views can't express what you need. The difference is that in Craft it's the front door, not the fire escape. There's no UI-versus-code impedance mismatch, nothing hiding in the database that a config export half-captures, and every listing on the site is code a developer wrote and committed to git.
GraphQL comes in the box
The other pleasant surprise: Craft's GraphQL is first-party and free — a core feature, not a contrib module you bolt on and pray about. There's a public schema (disabled by default), any number of private schemas guarded by bearer tokens, a "full schema" for logged-in admins, and a bundled GraphiQL IDE. Results are cached by default (toggle with enableGraphQlCaching). Coming from Drupal, where you're weighing the GraphQL contrib module against JSON:API and wiring up permissions by hand, having schemas and scopes as first-class citizens is a small daily relief. (One gotcha to file away: tokens live only in the database, so you recreate them per environment.)
Drupal hides your queries behind a UI and stores them in config; Craft makes you write them and keeps them in git. One is friendlier to a site builder, the other is friendlier to a code reviewer. Craft picked the reviewer.
The honest cost: no Views means no site builders
I don't want to sell the developer-joy version and skip the bill. Losing the Views UI is a genuine loss, and it's a specific one: a site builder who has never written a line of query code cannot build a listing in Craft. In Drupal, a savvy non-developer can assemble a filtered, sorted, paged view of content, tweak it, and never touch a template. In Craft, every "view" is Twig a developer has to write. For a team that leaned on Drupal's site-builder empowerment, that's a real shift in who can do what — work moves from the site builder back to the developer.
There's also a discipline tax. Views bakes in a caching-and-pager layer you get for free; Craft hands you .with() and .cache() and trusts you to remember them. Forget the eager-load and you've written an N+1 that no UI was going to warn you about.
So the trade is clear-eyed: Craft's element queries are the better tool for developers and the honest way to build — no magic, all in code, all reviewable. But you give up the thing Drupal is quietly famous for, the site builder who ships listings without a developer. Whether that's a feature or a loss depends entirely on who's on your team.