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. And the announcement has nothing about where this leaves wordpress.org, the open source PHP CMS that powers 25% of the web.
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:
"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."
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.
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)?
> 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?)?
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.
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.
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.
I don't know if I would call it a framework per se, but absolutely we want to break off individual pieces that can be separately re-used and make them available for everyone. In the meantime if you see something in particular that you're itching for, open a new issue and let us know. You may also want to check out the library of modules here. https://github.com/Automattic/wp-calypso/tree/master/client/...
As a developer at Automattic, the most interesting thing about this to me is that our whole workflow is now public. There are lots of companies that release their code, but it's rare that they also make their development process transparent.
OK. So basically this is an Adobe Air-esque app that is a user interface to WordPress which at the moment only works on Mac.
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..
There are two things here. WordPress.com has been rewritten as a SPA written in React, communicating with the back-end via REST-API. That codebase is now open source for anyone to review and hopefully learn some neat things about scaling a really big React application (or even better, teach us a few things). That codebase is here: https://github.com/Automattic/wp-calypso
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 desktop app is using Electron, the same framework used by Atom, Slack and Visual Studio Code and others to bundle up a JavsScript app + Chromium to be a stand-alone desktop application.
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.
"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.
>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.
Thank's god it's just ONE client for ONE specific app then. Which you can STILL use through a browser.
Get mad at your desktop window manager, then. Tabs are a hack compensating for insufficient control of the workspace. Well, initially it was for saving memory. But we've since moved to executing tabs in their own process.
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.
Actually I see tabs as a form of multiple document interface inside a single window. It's a valid approach to layering complexity as users multi task more. Excel sheets have worked this way for a long time.
Are rich offline capabilities part of the roadmap? For a long time I've been wondering if there would be any benefits from the Simperium project flowing to WordPress.
"Our existing codebase and workflows had served us well, but ten years of legacy was beginning to seriously hinder us from building the modern, fast, and mobile-friendly experiences that our users expect." - Taken from the second paragraph of the article. The reasons behind the project are explained in more detail here: http://ma.tt/2015/11/dance-to-calypso/
The desktop app is currently only for Mac, but we're working on other platforms. WordPress.com, which is a very similar experience, is obviously web based and can be used in any browser on any platform. This entire upgrade utilizes the new WordPress rest API and the new WordPress.com is open source.
Sorry, maybe my previous comment wasn't very clear, let me try again;
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.
>I don't understand what problem this project solves and whom it solves it for.
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.
> This entire upgrade utilizes the new WordPress rest API and the new WordPress.com is open source.
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. :)
>So basically this is an Adobe Air-esque app that is a user interface to WordPress which at the moment only works on Mac.
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.
> 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.
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?
> Code reviews were new for many developers — traditionally at Automattic, we have had no systematic peer code review system outside of the VIP team’s daily code review of client sites.
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"
This is just "Wordpress.Com" in javascript, not wordpress the blogging software. You have to interface with Wordpress.Com to build your own site. The code references Node.JS for the server side, but only as a proxy.
Question unrelated to the actual story - is anyone running a WordPress.com blog as just an API?
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.
That second link soon won't be needed. WordPress 4.4 will include the foundations for the REST API directly in core and 4.5 should include the actual endpoints.
This isn't quite what you mean, I don't think, but I use WordPress as the backend for SaaS apps. So one of my sites, timerdoro.com, is a single-page app, using WordPress as a backend/framework only.
It's a web app too. Wordpress.com has been steadily introducing features (through Jetpack) that allow you to manage your installed Wordpress instances - this brings the two together.
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.
Wodpress.org and PHP won't go away anytime soon, because of the whole community and plugins.
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.
Wasn't Wordpress.com essentially a multi-user edition of Wordpress the open source project? I am curious if Calypso means fewer releases of the Wordpress project?
WordPress.com still is a single WordPress install and all of the millions of websites are still generated and powered by PHP and MySQL.
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.
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.
As it's REST API powered, it doesn't. It could have been anything we wanted it to be. We just went with React & co. because we determined it'd be the best solution.
What's confusing is that, if the React-based admin client uses an API to talk to the PHP wordpress site, why involve node.js at all?
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.
My understanding is that the client and server side code is all of the same thing and Node.js is just used to generate the initial page load with the client continuing on from there. I wasn't involved with it's development so I could very well be incorrect.
> Wasn't Wordpress.com essentially a multi-user edition of Wordpress the open source project? I am curious if Calypso means fewer releases of the Wordpress project?
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.
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.
This is a huge deal. WordPress is probably the largest project in a plurality of projects continually dragging PHP on the ubiquity parade. If they manage to re-write the front-end as well it could be big.
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.
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.
Isn't one of the best aspects of WordPress the powerful plugin ecosystem that adds functionality, much of which is in the admin UI? Or am I missing something?
Sorry, my mistake. WordPress co-founder Matt Mullenweg on his own site describes it more as the project and the "experiment" behind it.
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!).
No worries. I just wanted to make it clear this is not a toe in the water. :-)
> 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. :-)
> We still have a ton to figure out around plugins, extensibility, contributions, Windows and Linux releases, API speed, localization, and harmonizing the WordPress.com API and WP-API so it can work with core WordPress. Thousands more PHP developers will need to become fluent with JavaScript to recreate their admin interfaces in this fashion. I'm also really excited to revisit and redesign many more screens now that we have this first version out the door.
Given that the submitted title ("Experimental WordPress Calypso Written Purely in JavaScript") broke the HN guidelines, we just reverted it to the article title.
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.
As far as I'm concerned rails would provide a better ecosystem for Wordpress.org. Not only is it still used commercially much more so than php in new ventures, but it forces adherence to good architecture which is key for something designed to be extendable like Wordpress. Additionally performance optimization in rails is much easier than php.
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."