Skip to content

Coming from WordPress

Most of what you know transfers. You still design visually, write in place, model structured content, and publish from the same tool. What changes is the machinery underneath: your content isn't in a database, there's no wp-admin , and no PHP running anywhere. Your pages are built ahead of time instead of assembled on every request. A Jx site is a folder of plain files that Jx Studio edits on your machine, and publishing means pushing those files to git so your host can build them into the finished site. A site that needs a database or server-side logic can have both, described in Databases , but that is a layer you opt into rather than the substrate your pages sit on.

If Cwicly's shutdown is what brought you here, welcome. Losing a good tool mid-project is rough, and you're in familiar company. It's also the failure mode Jx is designed to rule out. Your site is plain files in your own folder and your own repository, so it can't disappear with anyone's product.

The concept map

WordPress Jx Where to look
Theme Starter + Project Styles + tokens Starter templates
Blocks Elements and components Elements
The block editor Edit mode Edit mode
Custom post types + custom fields Content types Content types
Media library Media Media
Plugins Extensions and npm packages Extending
Publish button Commit and sync Publish

The rest of this page walks through each row, then gets honest about what's different.

Themes

A WordPress theme bundles templates, default styles, and options into something you install, and switching themes means starting over. In Jx the same jobs are separate, ordinary parts of your project:

  • A starter template gives you complete pages, components, and content to reshape. Nothing about a starter is special afterward: it's plain files you own, with no parent theme to update or fight.

  • Project Styles sets the default look of every heading, button, link, and form control in one catalog.

  • Design tokens name your colors, fonts, and sizes once, so the whole site draws from one palette.

Blocks and the editor

Gutenberg's blocks split into two ideas. Elements are the building parts (headings, images, sections, buttons), placed from the Insert palette by click or drag. Components are your reusable patterns: select something you built, turn it into a component, and reuse it with per-use properties. They are closer to block patterns, except you make them from your own work instead of registering them with code.

Writing feels like the part of Gutenberg you liked. Open a content page in Edit mode and the canvas becomes the page itself: click any text and type, use slash commands for headings, lists, images, and tables. It saves as Markdown files, not rows in a posts table.

Jx Studio's Edit mode with a content page open for inline writing on the canvas

Custom post types and fields

If you've modeled content with custom post types and Advanced Custom Fields, content types are the same idea made first-class. Name a collection, define its fields (text, numbers, images, dates, required flags, even references from one type to another, such as a post pointing at its author), and every entry gets a matching form.

Entries are files in a folder instead of database rows: Markdown, CSV, or JSON. You can edit a whole collection like a spreadsheet in Grid mode , and pages query collections to build listing and detail pages, which are the archive template and single template reborn. Build one end to end in Your first collection .

Media

Drag files into the Library and they land in your project's public/ folder, with no attachment posts and no uploads table. When the site builds, every image is optimized automatically into multiple sizes and modern formats, which is the job you used to install an optimizer plugin for. See Media .

Plugins

This is the gap. Jx has an extension system , and first-party extensions like the Markdown parser use the same public hooks yours would; Studio can also pull in npm packages of ready-made components through the Imports panel . But there is no plugin marketplace yet, and the catalog is a fraction of the WordPress directory's.

The counterweight: much of what plugins did for you is built in (image optimization, SEO metadata, forms UI, and caching, since a prebuilt page is the cache) or unnecessary (security scanners and backup plugins, when your repository is the backup). The server-backed ones, a members area or a form that stores what visitors send, are a third case: the parts ship with Jx, as database tables and accounts and sessions , but you assemble the feature instead of activating someone else's.

Publishing

There's no Publish button mutating a live server. When you're happy, open Source Control , write a message, and Commit and sync . Studio pushes your files to your repository, and your host rebuilds the site from them. The result is prebuilt pages served from a CDN. The whole flow is in Publish .

What's different, in one list

  • Content isn't in a database. Pages and posts are files you can read, search, and diff. The data that arrives while the site runs, such as comments, sign-ups and orders, goes in a database you add on purpose ( Databases ), kept apart from your writing.

  • No admin login. Editing happens in Studio on your machine, against your files, so there is no hosted dashboard for bots to brute-force. Your site's own visitors can still have accounts; that's the auth extension , and it's separate from how you edit.

  • No plugin marketplace yet. Extensions and npm components exist; a browsable ecosystem doesn't, yet.

  • Publishing is git. Studio handles the git parts with buttons, but a repository and a host are part of the setup.

What you'll miss

  • The plugin directory. Decades of plugins for every niche: commerce, memberships, event calendars. The server-backed pieces are buildable today: data tables give you real reads and writes, auth gives you accounts, sessions, and per-table permissions, and server-side functions cover the logic between them. What's missing is the shortcut: you build the feature instead of installing someone's finished one.

  • Editing from any browser. wp-admin is a website; Studio is an app where your files are. Git lets you set up a second machine, but it's a clone, not a login.

  • The ecosystem's size. Hosts, agencies, themes, and twenty years of tutorials.

What you gain

  • Nothing to maintain. No core, plugin, or PHP updates; no security patching; the published pages are prebuilt files, with no admin login to break into.

  • Fast by default. Prebuilt pages from a CDN and automatically optimized images, with no caching plugins to tune.

  • Version control of everything. Design, settings, and content all live in git, so every change is a reviewable commit you can roll back.

  • Portability. Your content is Markdown any tool can open; moving hosts is a settings change, not a database migration.

  • A real design system. Tokens and Project Styles instead of overriding theme CSS from a child theme.

Start here