Wing: a jQuery-free WordPress theme built on Vue and spectre.css

The README leads with a compatibility warning, not a feature list

Wing is described as a simple, smooth, data-driven, responsive WordPress theme, and the repository's own description is the same idea in English.

What makes the README worth reading is what it refuses to do. The first section after the screenshot is a warning, and the warning is about jQuery: the theme has no jQuery, and because of that it may have various kinds of compatibility problems with many plugins. The instruction that follows is practical, if blunt: if you hit a compatibility problem, try turning off PJAX.

That is a strange thing for a theme README to lead with, and it tells you a lot about the project. Most themes include jQuery because WordPress plugins assume it is there and because the admin and the block editor keep loading it. A theme that drops it is making a deliberate trade: a lighter page, no jQuery, and a compatibility burden that falls on the plugin author rather than the theme author.

The second section is a disclaimer, and it is unusually direct. Bugs can be filed as issues, but the project does not promise to accept or fix them. Questions about using the theme should go to the wiki or to a Discussions post, and ideas, suggestions or usage questions are asked for in Discussions. The statement that the project is not responsible for any bug and provides no free service is blunt in a way that is at least consistent with a one-person project.

The practical reading for an adopter is that this is a theme maintained by a single author with a project board for plans, a wiki for usage, and a Discussions board for questions. You are choosing a lightweight theme and taking on some of the integration work yourself.

The template files show a small, opinionated page set

The repository layout is small and PHP-template shaped, which is what a WordPress theme looks like from the inside.

The root holds the standard theme entry points: index.php, page.php, single.php, single-note.php, header.php, footer.php, comments.php and functions.php. There is a style.css at the root, which is where a WordPress theme declares its metadata. Alongside them are the specialised page templates: page-archive.php for an archive view, page-links.php for a links page, page-notes.php for a notes view and page-wall.php for a wall view.

The full top level is a short list: a .github directory, a .gitignore, the LICENSE, the README, the template files named above, an inc directory, a static directory, a screenshot and a style.css.

The inc/ directory is where the theme's own logic lives, and static/ is where its assets go. The pair of single templates, single.php and single-note.php, together with single-note.php sitting next to a notes page template, tells you this theme treats a note as a distinct kind of post rather than as a post with a category. A site built around short notes and links, which is the pattern the template names suggest, gets those views for free, and a site built around long articles gets the conventional ones.

The theme also carries a screenshot.png, and a .github/ directory. There is no build configuration in the listing, no package.json and no composer.json, so the theme appears to ship as plain PHP and CSS without a front end build step, which is a meaningful difference from themes that compile their assets.

Vue drives the views, spectre.css supplies the components

The acknowledgements table in the README lists the third-party libraries with their licences and what each one does, and it is the most informative paragraph in the document.

Vue.js is listed as the driver of view updates and component-based development, and it is the only entry that is doing structural work. spectre.css is a pure CSS component library, normalize.css initialises a consistent browser style, js-cookie switches and records the theme mode on the front end, and qrcode generates a QR code image for sharing an article. dayjs handles time formatting, and Lately does the relative phrasing, turning a timestamp into a form like XX ago. ViewImage is an image lightbox plugin for clicking to enlarge, prettify does code highlighting, and browser.js handles visitor user agent parsing.

One entry is a commercial one. The caomei icon library is listed as a PRO licence, a purchased PRO version whose use is limited to the design notes series of themes, which is a licensing constraint that a site owner should read before using the theme outside that series.

Every other entry is MIT licensed, which is a pleasant thing to see in a WordPress theme dependency list, since the ecosystem is full of components under licences that complicate distribution.

The combination of Vue for behaviour and spectre.css for appearance explains the no-jQuery decision. spectre.css is a CSS-only component framework, so it brings no runtime, and Vue is the only script dependency doing the interactive work, which is consistent with the theme dropping jQuery entirely rather than merely deferring it. The README also says the theme's development plan is tracked on a GitHub projects board, and the usage documentation lives in the wiki, which it describes as still being improved.

What a new user has to do before switching a site over

There is no installation command in the README, and the project points to the wiki for usage documentation rather than embedding it in the repository, so the first step is to read the wiki rather than to run something.

The concrete sequence the documentation points to is short. Read the wiki for how the theme is installed and configured, read the Discussions board for existing questions about use, check the development project board to see what is planned, and read the README's compatibility note about jQuery before you enable anything.

The last of those is the one that will save you time. If your site runs a plugin that assumes jQuery, the theme tells you what to do about it, which is to turn PJAX off and see whether the problem goes away. PJAX is the technique that makes a WordPress page load a partial view over the current one instead of a full page, and it is exactly the kind of feature that depends on the page behaving like a normal document.

What the project does not document is worth naming too. There is no supported list of plugins, no compatibility matrix, no migration notes for existing content, and no versioned release history in the repository, which has no GitHub releases. The README's development plan link is the only forward-looking artefact, and it points at a board rather than a changelog.

So the practical approach for an adopter is to treat the wiki and the Discussions board as the documentation, and to test on a copy of the site rather than switching a live one. The theme's own warnings tell you to expect plugin friction, and the project board tells you what is being worked on.

Where Wing is the wrong choice

The first limitation is the jQuery question, and it is not hypothetical. A theme that ships without jQuery will break plugins that assume it, and while the recommendation to disable PJAX is a good diagnostic, it is not a fix. A site whose plugin set depends on jQuery is a site that needs jQuery, and the theme's position is that the plugin should be updated.

The second limitation is the support model. The disclaimer that bugs may be reported but are not guaranteed to be accepted or fixed is the kind of statement that is honest and also disqualifying for a business site. There is no response time, no patch policy, and no release history in the repository, so the only real signal of maintenance is the project board and the Discussions board. A theme is the layer of a site that most users never see and most developers never touch, which is exactly why it tends to be left alone for years and then quietly rot when the parent WordPress version changes.

The third limitation is the narrow page vocabulary. The template set covers an index, a page, a single post, a single note, and the archive, links, notes and wall views. If your site needs a documentation layout, a membership area, a custom search page or anything else with distinct structure, you are writing templates yourself, and the fact that the theme is data-driven in its marketing description does not change that.

The real alternative is the default block theme that ships with WordPress itself, and the difference in approach is exactly the trade the whole ecosystem is making. The default theme is a full site editor theme with no fixed page set, built on the block system, and it is maintained by the same people who maintain WordPress. Wing is a traditional template theme with a curated set of views, a hand-written front end and a lighter dependency footprint.

If you want the lightest possible page and you accept writing the templates you need, Wing is a reasonable pick. If you want a theme that will still work after the next few WordPress releases without you touching it, the default theme is the safer answer, because its compatibility is part of the release process of the platform itself rather than a side project.

Editorial conclusion

Adopt Wing if you run a WordPress site and want a theme that does not drag jQuery into the page, and if you are comfortable with a theme whose support is a wiki and a Discussions board rather than a documentation site. Do not adopt it if your site depends on plugins that assume jQuery is present, because the theme explicitly says compatibility problems are likely for that reason, and do not adopt it if you need documentation that is complete on day one, since the usage documentation page is described as still being filled in. Before you switch a live site, read the wiki, test your plugin set on a copy, and check the development project board, which is where the author tracks what is planned next.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Tokinx/Wing on GitHub