Hacker News Reader

The node.js aspect of Calypso is actually pretty minimal, basically to build the shell of the web page. WordPress and PHP still power the API behind Calypso as well as the entire front-end of the site (i.e., what your readers see when they visit your blog). I don't think either of them are going away anytime soon.

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.

> The .org community (self-hosted WordPress) is also getting serious about API-based interactions, so this isn't an entirely new direction.

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.

I just learned about jetpack - does anyone know why the functionality there requires a wordpress.com account (or rather, are there any efforts towards being able to self-host that part?)?

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)?

My hope is that we (the core REST API team) will be able to work with the Automattic/WordPress.com REST API team to harmonise the two, yeah. :)

(There are some things in the WP.com API that don't make sense for self-hosted sites, and vice versa.)

> does anyone know why the functionality there requires a wordpress.com account (or rather, are there any efforts towards being able to self-host that part?)?

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.).

Oh, but I could care less about stats, related posts, site uptime -- if I could get a shiny new ui to do the basics (write posts). That's what I mean - if all the crap I don't care about could just return 403/500 - how much work would it be to get the stuff I need to work with the new SPA?

>So Automattic, maker of the largest open source PHP CMS in the world has thrown out PHP in favor of node.js for their own site.

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.

>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?

Through the availability of said announced open source node/js admin panel + client that works with it too, through its REST interface.

You thought it's just for wordpress.com?

I did. There wasn't anything I noticed in the announcement about wordpress.org. Can you point me to where they mention it's being integrated into the wordpress.org codebase? [I'm aware of the mention about the jetpack plugin in the wired article]

>There wasn't anything I noticed in the announcement about wordpress.org. Can you point me to where they mention it's being integrated into the wordpress.org codebase?

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/

According to https://developer.wordpress.com/calypso/ the jetpack plugin is required for wordpress.org users (mentioned that above) and it sounds like you need to use their node.js hosting. (the point of .org is self-hosting)

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.

This is open source. You can run it locally, host it yourself, put it on Heroku -- whatever your heart desires. And, yes, you can always just use WordPress.com (for free, btw). And that's just out of the box; The sky's the limit if you get involved as a contributor (and you should!)

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.

I think this is a bit of an overstatement. Calypso is a rewritten "dashboard" view and administration panel -- it's a client-side single page web app in React, with "a thin layer of Node.js on the server to build the initial web page," as they put it. This is communicating to the actual WordPress blog/CMS engine over a REST API, that engine is still in PHP, and I suspect it's going to remain PHP for the foreseeable future.

I think the way forward would be for WordPress hosting to come with a version of node.js with standard packages which plugins can use, in combination with the new REST API.

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.