commandcar is a CLI tool that can easily communicate with any API. It simplifies unreadable and complicated curl commands, and has some nice features to make automation of API calls much simpler and bash scripts more streamlined.
This is a lot of change. But it goes deeper than just the entire technology stack we’re working on now. This was a complete culture-shift for Automattic, a now-400-person company traditionally made up of approximately 100% PHP developers. To get here, we at Automattic took a step back and asked ourselves;
What would WordPress.com look like if we were to start building it today?
As part of answering that question, we made a lot of changes internally:
- Switched to a completely GitHub-based workflow.
- Every commit is now peer-reviewed.
- Shifted to a very component-minded architecture.
- Moved our WordPress codebase to be entirely API-driven. New features are now only launched as a new/modified API endpoint + data layer + UI layer.
- Change in thinking from being very “plugin-oriented” (similar to WP-core) to a much more integrated and cohesive way of thinking of things across the web and mobile apps.
So today, in keeping with the DNA of Automattic, which shares the DNA of WordPress, we’re releasing what we’ve been working on as open source. It’s code-named “Calypso” (long story), and we’re extremely proud of what we’ve built over the last ~18 months. I truly hope that this can help guide or influence WordPress.org‘s future.
I wrote this post in the Calypso/WordPress.com Desktop app, and published it via Jetpack. That feels pretty darned good.
DISCLAIMER: These are my personal thoughts only, based on what I’m seeing around the web over the last few years.
- If you’re trying to provide any custom functionality for WordPress, you pretty quickly end up doing it in PHP because that’s where all of the internal APIs and functionality resides.
That’s been a fine approach for the last 10 years, but I believe that things are changing, and we need to change with them to remain relevant. Full page reloads with heavy server-based everything is no longer really acceptable for a solid UX. With that in mind, here’s a possible future for WordPress, extrapolated out from where some things seem to be going (on the wider web, not necessarily currently within WordPress development):
Plugins would create additional endpoints within the backend API, or would supplement existing ones (e.g. post/meta) with additional data and/or actions. They could also be implemented via pure JS, depending on what they were built to do. Themes could potentially be built using no PHP at all — making queries directly to the API via JS, and then using something like Mustache to template the output back to the user. This would have SEO ramifications, but we can always figure something out there, and search engines are constantly improving.
Unfortunately a crucial point where backwards compatibility would be important would be the Post Editor, which is also where some big performance/UX improvements could potentially be seen by switching to a largely JS-powered UI.
I don’t know if this is really where WordPress will go, or if it is, exactly how it will get there. There’s a project currently to build a core REST API which I’m eagerly observing and will be trying to get more involved in. It has the potential to become the kernel of the future of WordPress if it’s done right. This is going to be a long road either way, so I’m excited for where we can all go from here.
Do you think WordPress can (or should) move in this direction?
On Saturday, I attended the 2012 New Times/TimesOpen Hack Day. It was a long day, but I had a lot of fun. I sat in on an intro session to Arduino which was pretty cool, and also a session on the EchoNest API, which I ended up using in my project. You can find out all about my project on the Readtrack project page.
It’s a bookmarklet-powered little app that analyzes the page you’re looking at (using the AlchemyAPI) and then tries to find related music (using the EchoNest API) which it then plays back to you in your browser (using rdio). I got a “runner up”/honorable mention prize 🙂
One of the most visually-polished projects was “Story Arc”, which showed a visual representation of the frequency of mentions of keywords over the NYT archives. Probably the most fun one was a set of drivers for a DDR pad, hooked up to commands for things like deploying code!