Jetpack 4.3 Now in Beta, Admin Interface Rebuilt Using React.js

Automattic is doubling down on its commitment to using JavaScript in its products. In November 2015, the company debuted Calypso, its first React.js-based product powered by the REST API. Shortly after Calypso’s unveiling, Automattic CEO Matt Mullenweg declared that “JavaScript and API-driven interfaces are the future of not just WordPress but the web.”

Today the company announced the next release of Jetpack will include an admin interface that has been entirely re-written from the ground up to use React.js. After thousands of hours of development from Automattic’s engineers and designers, the upcoming release is now in the hands of beta testers.

Jetpack 4.3 admin interface rebuilt with React.js
Jetpack 4.3 admin interface rebuilt with React.js

The Jetpack team is encouraging theme and plugin developers, as well as hosting providers, to test the beta alongside their products to ensure compatibility before the official release. Anyone who wants to preview it and help find bugs can sign up to be a beta tester, which will give you immediate access to 4.3. Beta testers can report bugs by opening a new issue on Jetpack’s GitHub repository or send feedback via the online beta tester form.


  1. It looks great. While I haven’t tested it, I hope it has the feature parity with what we already have in the current version.


  2. Confession to make.

    I’d like to see a proper discussion around React.js and WordPress for the future. I like the premise of React.js as a tech in isolation, but I’m not sure how I feel about it being packed with the many libraries already present and loading on many pages in WP, such as underscore.js, backbone and jquery.

    There’s too much overlap and it imparts a lot of requirements on people wanting to work with. Also, React still is a FB thing (the big corp who’s business is selling our private life to businesses) with a license that isn’t a compatible as you would like. I mean, the license works I guess, but it doesn’t make you feel warm and fuzzy inside either.

    I also feel like, despite that I love JS, we may be undervaluing the PHP side of things and letting the sparkly side of new tech steer us for reasons that have nothing to do with end-user experience and more to do with scratching developer’s itches and for the sake of appearances.

    And I say that as a plugin dev that is continually thinking “I should JS all the things”.

    I don’t think the notion that everything should shift to JS should go as unchallenged as it is currently. Especially now that PHP is in better shape than ever and servers are generally really fast, the business case for overengineering stuff on the clientside isn’t as compelling as it might feel.

    I look at the Node.js ecosystem and for as much cool things about it, there are so many annoying things. Few hosting companies offer an easy node.js server setup, that could take years.

    Working with hundreds of javascript files is to me much more daunting and fragile feeling. If you want to start a React project, you have to set up a pretty complicated environment and configure build steps and processes.

    You have to make tons of choices (do I submit to using JSX? What other libs do I add on like flux? etc etc) and the choices are rarely that clear to make, especially considering how fast things move. As a developer, I hate that the choices consume so much time in my head before even writing a line of code and it nevers leave me with the feeling that it was the best one.

    When coding in pure php, I don’t have to worry about build steps. I don’t have to worry about how I can get pieces of code from different modules to work together. Things just work out of the box.

    You end up with many dozens of different js modules doing different things for which updated packages appear frequently or infrequently that may or may not be compatible.

    And then when you add the difficulty of other plugins adding their own libraries to the mix.

    There’s also something interesting about tinkering with PHP scripts compared to tinkering with JS. If you, say, work in a React.js style, you can’t then start tinkering with the logic in a non-react way, I mean you can, but it will clash in a bigger way. With php code, no matter how it is coded, actions and filters let you pretty much code in ‘your’ way and still end up with something that works OK.

    We are also continuing the raise the barrier to entry for people interested in getting into coding. There is so much implicit knowledge required to work with both sophisticated JS, php, html, css and git.

    Especially when you consider that you now often need to setup a detailed environment just to get started, as well as build steps to package everything up again. That’s a huge ask for people getting started. I’m fearful that we are making things increasingly difficult when we add more tech like React.js.

    I can’t fight the feeling that something is amiss when I’m not a 100% excited about JS taking over an increasing role, when I actually like WordPress and I like coding in javascript a lot.


    1. Agreed. It’s ironic considering that one of the oft-repeaded selling points of WordPress is its low barrier to entry. Now, more and more parts of it are being rewritten in JS. I’m still trying to grasp how the 3.5 media uploader works to add things or modify its behaviour.


  3. Using 4.2 in my site . sometimes , I get Reports on site downtime but the hosting company disagree that the server was down .

    Hope in the new version 4.3 this issue will be solved.


    1. Howdy!

      You can reach out to the Jetpack support team via to contact us directly about issues like this.

      When Jetpack Monitor checks your site, we ping your site’s homepage (via a HTTP HEAD request) every five minutes.

      We tentatively mark your site as down if the HTTP response code is 400 or greater, which indicates either a permissions error or a fatal code error is prohibiting your site from appearing to visitors, or we see more than 3 300-series redirects, suggesting a redirect loop, or if your site fails to respond within 20 seconds.

      Once it is tentatively marked down, we then spin up two separate servers in geographically different locations from a third-party vendor to ensure the problem is not isolated to our network or the location of our primary datacenter.

      If all three checks fail, we mark the site as down and notify you. We’ll continue to check the site and once we have agreement it is back online, we’ll send you the all-clear notice.

      All that being said, *something* is going on that is causing us to see the site is down, really slow, or something else is amiss (a hosting provider throttling/blocking our Monitor service, etc).


      1. Wasn’t aware of the 20 second response time causing a positive downtime report, but I understand it completely and it makes sense! Perhaps this is why my client’s cheap shared hosting site gets so many of these “site down” messages ?


  4. So they spent thousands of hours on this… Hope they feel the ROI is good, compared to other things they could have spent those thousands of hours on.


    1. Why do you care?

      Automatic is a private company that can choose to spend their money anywhere they please. !=


  5. I have a question, as a relatively new WP plugin developer. I rely on the way WP admin is constructed today, in PHP. For example, I show the user a nice settings/options page and I use AJAX to make the user experience better (IMHO).

    Is the future of WP to get rid of our current PHP based Admin logic and move to a completely different design? If so, that sounds like it means the thousands of lines of my own code (and millions of others) will become obsolete a lot faster than I thought it would.

    Welcome anyone setting me straight on this.


Comments are closed.