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.

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-adminis 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
Your first project goes from starter to published site in about ten minutes.
Your first collection builds the Jx version of a custom post type.
A tour of Jx Studio teaches the workspace before you start.