The Story Behind the New WordPress.com
developer.wordpress.com
developer.wordpress.com
If they're leading by example, we should ditch WordPress.org and PHP in favor of node.js web apps and frameworks too, since it's the way of the future?
I happen to wholeheartedly agree. It's just that the developers of the 40,000 plugins who have bet their farms on PHP WordPress might at least want a clearer indication of what exactly is happening here.
The only thing I could find about where this leaves wordpress.org is buried in this wired article:
http://www.wired.com/2015/11/wordpress-com-gets-a-new-face-a...
"For the backend code, the team used the popular server-side JavaScript platform Node.js. For users who host their own version of WordPress, Automattic will host the Node.js portion of the code on their own server, with which the Jetpack plugin will communicate, freeing up web hosts from having to support Node.js."
So even if we would move past PHP we wouldn't move past WordPress, its database, and the basic ways it stores and describes information. No need to reinvent that wheel if it works well for your site or product.
No, they kept PHP for the backend, and created a new front-end with node and JS. And that's just for the admin pages.
>If they're leading by example, we should ditch WordPress.org and PHP in favor of node.js web apps and frameworks too, since it's the way of the future?
Perhaps. Do you expect Automattic to tell you what your stack should be?
Besides, if node/Js is the "way of the future" then there's no need to ditch "wordPress.org" since it has already embraced that future.
How?
You thought it's just for wordpress.com?
The linked article is just the (lead?) developers recount of how they've built it.
The official reveal is through the project's site: https://developer.wordpress.com/calypso/
So this all goes to my original point that there is very little clarity on where this leaves wordpress.org. It's clearly a big endorsement of node.js, which is great, but there needs to be some clear strategic intent here for where we're headed with wordpress.org - beyond what seems to be a band-aid.
Where does this leave WordPress.org? Well, let's put it this way: There will be a lot more people building cool things on top of the WordPress.org REST API now that this project has shown what can be done (I expect that over time the REST API will accumulate all the abilities of the Jetpack API)
Does there have to be a better strategy for WordPress.org? I don't fear for a project that has already claimed 25% of the web and is growing market share faster than any other CMS.
The .org community (self-hosted WordPress) is also getting serious about API-based interactions, so this isn't an entirely new direction. I think we'll be seeing front-end JavaScript becoming more and more important there as well. There's still a lot to figure out, but I think the open-sourcing of Calypso that happened today will make it easier to share ideas with the greater WordPress community.
Indeed, we're shipping the first half of the core REST API with 4.4 (just about to hit RC), and the rest in the next release.
In the same vein, the wordpress.com api does indeed appear to be rather well documented -- shouldn't it be rather easy to implement enough of that to allow using this new web-app for interfacing with it? (Even if most of the calls just return 403 or 500 - presumably the app handles that somewhat gracefully)?
(There are some things in the WP.com API that don't make sense for self-hosted sites, and vice versa.)
The list is long: http://jetpack.me/features/ (probably half of those require the connection)
Examples include stats (a pain to scale on shared hosting), related posts (also known to kill database servers), site uptime monitoring, image CDN (including on the fly thumbnailing), and so on.
It basically provides the things that you probably don't want to self-host. You get some of the scaling of WordPress.com while being able to do your own thing (plugins, custom theme, etc.).
https://github.com/Automattic/wp-calypso/blob/master/LICENSE...
I don't have anything against GPL. It just closes a lot of doors for no real reason.
I'm sorry but I don't really understand what the value proposition here is, maybe I missed it in the article? WordPress already has a pretty good user interface, which was build in HTML/CSS/Javascript.
When people complain about WordPress being an outdated architecture it's not the UI they're referring to..
I don't understand what problem this project solves and whom it solves it for. We can already manage multi-site WordPress installations and usually that's done by site admins, not the average content Joe, so does it really need a super fancy new UI?
And what exactly does it mean when you say "WordPress.com is open source"? Maybe I'm out of the loop but the way I understand it is that wordpress.com is a hosted (commercial) service of wordpress.org.
My experience with WordPress is not that the UI is a problem at all, neither multi site management, which I think is in the scheme of things quite niche. The problem with WordPress I hear other developers complain about is the out dated PHP system architecture.
In WordPress.com, "average content Joe", can manage multiple sites, including self-hosted WordPress.org sites (through JetPack plugin).
Disclosure: I'm one of the authors.
Sorry, it's my pet peeve. Downvote away!
Faster (through SPA techniques) admin UI.
>We can already manage multi-site WordPress installations and usually that's done by site admins, not the average content Joe, so does it really need a super fancy new UI?
Yes, since the current UI leaves a lot to be desired. And why keep it to "site admins" and not make it approachable by the "average content Joe"?
Besides "sites admin" in this context is just a fancy name for a person that needs to manage more than one Wordpress sites from the same UI -- it doesn't mean he's super-technical or that the UI shouldn't be made more approachable, faster and better.
To clarify: this uses the WordPress.com REST API, which has been around for a number of years, not the core REST API being integrated into WordPress (the software). Also, not all of WordPress.com is open source (i.e. you can't just clone down WP.com and run it), just the new interface. :)
Secondly, Automattic has also launched a desktop app (osx for now, but linux and windows forthcoming) that makes use of this new codebase... which is possible now because everything is now going through our REST API.
The main benefit of this is speed having the entire app local it makes it really fast. As we continue to develop the app, we'll build in more desktop options and features.
Plus its easier to launch and switch to when its an app in your dock instead of just a tab in your browser.
If every website I visited refused to be in a tab and instead required its own place on my launcher... well, my desktop would be about as useless as my smartphone launcher. 100 applications spread across 8 separate pages, who knows what's open, annoying and time consuming to organize...
I really love tabs.
Are we really killing them now? Sucks to be anyone who isn't Facebook, because 98% of websites aren't going to make the "put it on the dock" cut, and will just be ignored.
KWin used to allow title-bar level tabs but it didn't work in a lot of clients that expected to have complete control of the frame.
Separate windows are not the only way.
That's not available in Chrome without extensions, as far as I know anyway.
Thank's god it's just ONE client for ONE specific app then. Which you can STILL use through a browser.
Nope, it's a full web app -- if you mean the desktop client, that too. Adobe Air was Flash/AS based. And that's not a just a po-tay-to/po-tah-to distinction.
>I'm sorry but I don't really understand what the value proposition here is, maybe I missed it in the article?
Yeah, especially since it includes a full comparison matrix type chart with the benefits and changes from the new stack.
Either is a bag of shit sitting on my desk, whatever the consistency of the contents.
> Yeah, especially since it includes a full comparison matrix type chart with the benefits and changes from the new stack.
The "handy chart"? Or do you have something better in mind than that piece of typical meaningless marketing lip-flapping reformatted as a chart?
Wait... seriously? You had no systemic code review until now?
It's not exactly clear what you did by way of code review before, but that sounds suspiciously close to "almost nothing"
"If you run your own self-hosted WordPress site, you can install the Jetpack plugin to use the Calypso-based editing and management tools."
I've had a few friends ask me to work on their WordPress blogs but I turn them down unless they're willing to migrate to something like Squarespace or Ghost. Most of the time they won't switch because they're used to the WordPress admin. Being able to just fetch a JSON API would actually make me think about working with WordPress.
https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge...
So you can login to wordpress.com either via the web, apps, Air etc to manage/publish to any types of Wordpress installs.
It means that you don't have to use the old wp-admin CMS and can use what they've now built and released.
Wordpress' popularity comes from the plugins, and the WP devs. won't expect plugin authors to rewrite everything into node.js, that just won't happen anytime soon.
Although it would be interesting to see how this will affect the client side code of WordPress. React can be interfaced with any back-end.
This plugin author says "bring it on" :)
I noticed that some of the docs require a login, for ex: https://wpcalypso.wordpress.com/devdocs/design Anyone know if this is a bug, or part of the new approach?
The difference is that rather than using the admin interface that ships with WordPress, we're encouraging usage of this new interface. It still talks to WordPress via a PHP-powered REST API.
In short, it's a new _interface_ for WordPress, not a replacement for WordPress itself.
> https://wpcalypso.wordpress.com/devdocs/design Anyone know if this is a bug, or part of the new approach?
Bug. That's one of our internal staging sites and the devdocs are stripped when pushed out to the production URL.
I've opened an issue for you: https://github.com/Automattic/wp-calypso/issues/577
EDIT: Not private! Just requires a login from any WordPress.com account. There's discussion going on on that ticket to move it somewhere that doesn't require a login but it might not be possible.
Thanks for filing the issue. I will reply there.
> So what does the Node powered REST API provide that PHP powered traditional Wordpress API does not?
Our REST API is PHP-powered and built on top of WordPress: https://developer.wordpress.com/docs/api/
Calypso is a React-based administration client for that API.
As far as I can tell, the node.js portion is just returning an empty admin.html, and that's where client-side React.js kicks in? It seems PHP would be able to do that pretty well, with the advantage of single technology and a more obvious approach for the self-hosted wp.org sites.
https://github.com/Automattic/wp-calypso/blob/master/docs/gu...
I wouldn't expect so. Calypso relies upon WordPress to power the API. Automattic still has a dedicated team devoted to the WordPress project, working alongside the rest of the WordPress community.
> I noticed that some of the docs require a login, for ex: https://wpcalypso.wordpress.com/devdocs/design Anyone know if this is a bug, or part of the new approach?
Good question. Issue filed here: https://github.com/Automattic/wp-calypso/issues/577. I'm not positive, but I think it might be because several of our components require a logged-in user in order to render correctly.
That said, the plugin ecosystem is pretty massive. I wonder how they plan on handling that. Hosting, too. This is going to be pretty interesting for Automattic, PHP, and Node.
At one moment you even dream people understand what was wrong with PHP, then you see node.js.
Today we're announcing something brand new, a new approach to WordPress, and open sourcing the code behind it.
Written purely in JavaScript, leveraging libraries like Node and React.
Submitters: the HN guidelines ask you to use the original title unless it is misleading or linkbait. If you want to say what you think is important about a story, don't do so by rewriting the title—editorializing is against the rules here. Instead, add a comment to the thread, on a level playing field with other commenters.
My understanding is this can be used as an interface to all WordPress blogs. My take is that although this is acting through WordPress.com as an API intermediary, it is only steps away from peeling out the whole PHP layer for these interfaces.
WordPress co-founder Matt Mullenweg described it as:
> At the beginning of last year, we decided to start experimenting and see.
> Today we’re announcing something brand new, a new approach to WordPress, and open sourcing the code behind it. The project, codenamed Calypso, is the culmination of more than 20 months of work by dozens of the most talented engineers and designers I’ve had the pleasure of working with (127 contributors with over 26,000 commits!).
> My understanding is this can be used as an interface to all WordPress blogs.
Yes, that's correct. It works for WordPress.com blogs of course. But self-hosted blogs can also make use of Calypso by installing our Jetpack plugin (https://wordpress.org/plugins/jetpack/) which adds some API endpoints that allow Calypso to communicate with the self-hosted site.
> it is only steps away from peeling out the whole PHP layer for these interfaces
I don't think I would go that far exactly. The php codebase is still there, and users can still use "wp-admin" if they prefer. And the API is also powered by PHP. But now that Calypso only communicates with a site through the API it allows us to separate the view logic and focus on making those endpoints as efficient as possible. I think it's possible the API could be written in a language other than PHP. But that hasn't happened yet and would be a significant task.
I should probably mention I am one of the authors, if that wasn't obvious. :-)
[citation needed]
[citation needed]
[citation needed]