Quantifying WordPress developer experience

When you spend a lot of time with it you get a distinct feel about WordPress developer experience. Some parts get job done and other are synonymous with trouble.

Yet there is rarely organized conversation about this. Which WordPress APIs perform well and why? How do we get more to that point?

I had run WordPress APIs Developer Satisfaction survey to get some measured insights.

Responses

Survey asked two questions of participants:

  1. Their development experience with WordPress — on the scale from 1–Novice to 5–Expert.
  2. How would they rate WordPress APIs on the list of 30 — with possible ratings of: Horrible, Bad, Normal, Good, Excellent.

The results are summarized in following chart.

WordPress developer experience with APIs.

WordPress developer experience with APIs.

You can see raw responses and processed results as a spreadsheet. Thank you to everyone who participated!

Survey attracted responses from experienced developers. 62.7% rated their WordPress experience level 5/5 and 31.3% — 4/5.

The distribution of API ratings was:

  • 40.3% positive (Good or Excellent)
  • 33.1% Normal
  • 26.6% negative (Bad or Horrible)

Familiarity

Most familiar

  1. Admin Menus, Ajax (100%)
  2. Admin Pages, Custom Post Types, Query (97%)
  3. Custom Taxonomies, Database, Plugin (hooks), Queue (CSS and JS), Roles and Capabilities, Settings (95.5%)
  4. Editor, Options and Transients, Rewrite, Shortcode (94%)
  5. Template Tags (92.5%)

It is the norm for experienced developers to be familiar with wide range of APIs.

Least familiar

  1. File Header (71.6%)
  2. XML–RPC (73.1%)
  3. Heartbeat, Theme Modification (79.1%)
  4. REST (80.6%)
  5. Dashboard Widgets, Updater (83.6%)

Even the least familiar APIs show quite high numbers.

REST API, a recent addition, was already familiar to over 80% of those responded.

Quality

(“Excellent” and “Horrible” counted with extra weight)

Best rated

  1. Custom Post Types (73.8% positive)
  2. Plugin (hooks) (75%)
  3. Custom Taxonomies (70.3%)
  4. Queue (CSS and JS) (70.3%)
  5. Options and Transients (57.1%)

Many of staple WordPress APIs got good ratings.

Worst rated

  1. Rewrite (58.7% negative)
  2. XML–RPC (61.2%)
  3. List Tables (52.5%)
  4. Editor (47.6%)
  5. Filesystem (46.6%)

You might have heard horror stories about Rewrite and numbers back them up. Rewrite is worst rated API. It is in stark contrast with routing solutions in modern breed of frameworks and CMSes.

XML–RPC shows why REST API is in such a high demand.

List Tables never quite graduated from their messy semi–internal status.

Editor is rarely mentioned as a problem point, but got significant negative rating.

Conclusions

Winners

WordPress excels at laconic procedural APIs, which enable easy access to powerful functionality. These APIs age well, many of them define WP since early days.

Some of them balance out internal complexity well. For example Query is well rated despite complex implementation.

Losers

WordPress does not offer good APIs to work with complex and persistent data structures.

Many of admin area APIs got negative ratings. Extension developers are often criticized for poor and inconsistent integrations with WordPress admin… But it seems WordPress is coming up short in empowering them to do better.

Progress

Out of newer APIs Custom Post Types and Taxonomies are a smashing success.

REST API is well accepted, more so replacing XML–RPC.

Customizer seems to be an outlier. It has good word of mouth reputation, but numbers show somewhat negative picture.

Summary

Three quarters of experiences fall into normal and positive range. One quarter of experiences is negative.

WordPress developer experience with APIs is quite polarized. Quality of older APIs ranges from very good to very bad.

The newer APIs are mostly successful and well received. However there are significant areas (such as admin) which are in bad shape and have no roadmap for improvement.

Related Posts

4 Comments

  • Are you able to include a link to the WordPress APIs Developer Satisfaction survey?

    • I had closed survey for new responses when I proceeded to work on results.

      Is there anything specific you are interested in about it? As per post it only had two questions so not much to see. :)

  • Thanks for doing this, it’s really interesting.

    • My pleasure. It was indeed very interesting to see how developers perceive different APIs and how that might shape different experiences.

Comments are closed.