React Isn’t The Problem

As React (via Gutenberg) becomes more present in the WordPress world, I’m seeing some common themes pop up in conversations about it. I spoke a bit about this kind of thing at WordCamp US last year, but if you don’t feel like sitting through a half hour video, let me summarise my thoughts.

I agree that React is hard. I strongly disagree with the commonly contrasted view that HTML, CSS, PHP, or vanilla JavaScript are easy. They’re all just as hard to work with as React, sometimes more-so, particularly when having to deal with the exciting world of cross-browser compatibility.

The advantage that PHP has over modern JavaScript development isn’t that it’s easy, or that the tooling is better, or more reliable, or anything like that. The advantage is that it’s familiar. If you’re new to web development, React is just as easy anything else to start with.

I’m honestly shocked when someone manages to wade through the mess of tooling (even pre-Gutenberg) to contribute to WordPress. It’s such an incomprehensible, thankless, unreliable process, the tenacity of anyone who makes it out the other side should be applauded. That said, this high barrier is unacceptable.

I’ve been working in this industry for long enough to have forgotten the number of iterations of my personal development environment I’ve gone through, to get to where I can set up something for myself which isn’t awful. React wasn’t around for all of that time, so that can’t be the reason web development has been hard for as long as I remember. What is, then?

Doing Better

Over the past year or so, I’ve been tinkering with a tool to help deal with the difficulties of contributing to WordPress. That tool is called TestPress, it’s getting pretty close to being usable, at least on MacOS. Windows support is a little less reliable, but getting better. If you enjoy tinkering with tools, too, you’re welcome to try out the development version, but it does still has some bugs in it. Feedback and PRs are always welcome! There are some screenshots in this issue that give an idea of what the experience is like, if you’d like to check it out that way.

TestPress is not a panacea: at best, it’s an attempt at levelling the playing field a little bit. You shouldn’t need years of experience to build a reliable development environment, that should be the bare minimum we provide.

React is part of the solution

There’s still a lot of work to do to make web development something that anyone can easily get into. I think React is part of the solution to this, however.

React isn’t without its problems, of course. Modern JavaScript can encourage iteration for the sake of iteration. Certainly, there’s a drive to React-ify All The Things (a trap I’m guilty of falling into, as well). React’s development model is fundamentally different to that of vanilla JavaScript or jQuery, which is why it can seem incomprehensible if you’re already well versed in the old way of doing things: it requires a shift in your mental model of how JavaScript works. This is a hard problem to solve, but it’s not insurmountable.

Perhaps a little controversially, I don’t think that React is guilty of causing the web to become less accessible. At worst, it’s continuing the long standing practice of web standards making accessibility an optional extra. Building anything beyond a basic, non-interactive web page with just HTML and CSS will inevitably cause accessibility issues, unless you happen to be familiar with the mystical combinations of accessible tags, or applying aria attributes, or styling your content in just the right way (and none of the wrong ways).

React (or any component-based development system, really) can improve accessibility for everyone, and we’re seeing this with Gutenberg already. By providing a set of base components for plugin and theme authors to use, we can ensure the correct HTML is produced for screen readers to work with. Much like desktop and mobile app developers don’t need to do anything to make their apps accessible (because it’s baked into the APIs they use to build their apps), web developers should have the same experience, regardless of the complexity of the app they’re building.

Arguing that accessibility needs to be part of the design process is the wrong argument. Accessibility shouldn’t be a consideration, it should be unavoidable.

Do Better

Now, can we do better? Absolutely. There’s always room for improvement. People shouldn’t need to learn React if they don’t want to. They shouldn’t have to deal with the complexities of the WCAG. They should have the freedom to tinker, and the reassurance that they can tinker without breaking everything.

The pre-React web didn’t arrive in its final form, all clean, shiny, and perfect. It took decades of evolution to get there. The post-React web needs some time to evolve, too, but it has the benefit of hindsight: we can compress the decades of evolving into a much shorter time period, provide a fresh start for those who want it, while also providing backwards compatibility with the existing ways of doing things.

Authentication in WordPress

WebAuthn is now a W3C recommendation, bringing us one step closer to not having to use passwords anymore. If you’re not familiar with WebAuthn, here’s a little demo (if you don’t own a security key, it’ll probably work best on an Android phone with a fingerprint reader).

That I needed to add a disclaimer for the demo indicates the state of WebAuthn authenticator support. It’s nice when it works, but it’s clearly still in progress, and that progress varies. WebAuthn also doesn’t cover how the authenticator device works, that falls under the proposed CTAP standard. They work together to form the FIDO2 Project. Currently, the most reliable option is to purchase a security key, but quality varies wildly, and needing to carry around an extra dongle just for logging in to sites is no fun.

What WordPress Needs

Anything that replaces passwords needs to provide some extra benefit, without losing the strengths of the password model:

  • Passwords are universally understood as an authentication model.
  • They’re portable: you don’t need a special app or token to use them anywhere.
  • They’re extendable: strong passwords can be enforced as needed. Additional authentication (2FA codes, for example) can be added, too.

Magic login links are an interesting step in this direction. The WordPress mobile apps added magic login support for WordPress.com accounts a while ago, I’d love to see this working on all WordPress sites.

A WebAuthn-based model would be a wonderful future step, once the entire user experience is more polished.

The password-less future hasn’t quite arrived yet, but we’re getting closer.

Part 1 of my “Selfies on Seven Continents” series

One of the defining aspects of my 2018 was travel. There was travel for fun, travel for work, and travel for adventure. This year, I was fortunate enough to visit all seven continents, so in honour of my selfie habits over on my photo blog, here are some of my favourite selfies from this year, by continent.

South America

South America was entirely for fun and adventure. My dad and I got to tourist our way around, before we visited Antarctica.

  • Argentina: Boating adventure under the Iguazu Falls.
  • Brazil: At the top of the Iguazu Falls.
  • Argentina: at the Obelisco de Buenos Aires.
  • Argentina: Inside the Casa Rosada, with my dad.
  • Chile: At the Cape Horn Albatross Memorial.
  • Chile: At Punta Arenas airport, about to fly to the next continent…

Antarctica

Leaving from Punta Arenas, we travelled with Aurora Expeditions south along the Antarctic Peninsula, crossing the Antarctic Circle, before returning north again. Visiting Antarctica was one of the most spectacular, other-worldly, and unforgettable experiences of my life. If you’ve ever considered it, I highly recommend taking the plunge! (Both figuratively and literally. )

  • King George Island
  • Deception Island: About to discover the joys of snorkelling in Antarctic waters.
  • A biblical assault on the senses.
  • Neko Harbour: On the Antarctic mainland!
  • Snowball fights on an iceberg south of the Antarctic Circle.
  • Dallmann Bay: The only thing colder than wearing a drysuit in Antarctic waters…
  • Cuverville Island: I am skeptical of silly hat parties.

North America

Work dominated my travel to North America, but there was some time for fun and selfies.

  • San Diego: No selfie collection would be complete without a Sealfie.
  • Orlando: Just me and 700 of my closest friends.
  • Orlando: I’m skeptical of dragons.
  • Nashville: The face of a person who just launched WordPress 5.0.

Asia

Thanks to a long layover, I just managed to visit Asia, dropping in for dinner with some friends in Hong Kong.

  • Hong Kong: How could I pass on a selfie with a giant Garfield?

Europe

Europe was mostly work travel, which meant a distinct lack of selfies, sadly. This is clearly a shortcoming in my selfie taking habits that I need to work on next year.

  • Italy: Visiting the Duomo di Milano.
  • Italy: The joys of the Italian rail system.
  • England: Sunday lunch!

Australia

Home was a place for fun, family, and a little bit of introducing my kids to the excitement of travelling!

  • I don’t know where my children get this from.
  • Melbourne’s primary religion: Australian Football.
  • I. Am. Adorable.
  • I don’t just travel solo…
  • Planning the next adventure.

(I wish I could fit into an economy seat like a three year old.)

Africa

Rounding out the year, my first trip to Africa! Just a little adventure to Kenya, seeing a few of the sights, but leaving plenty more for my next trip.

  • Nairobi: Elephants get all the fun.
  • Hell’s Gate National Park: Zebras run away when you try to take a selfie with them.
  • Nairobi: Hello, new friend!
  • Nairobi: Oh, hello, new friend! (Technically not a selfie, but I love this photo too much to leave it out.)
  • Nairobi: Happy New Year!

So, that’s been my year of travel. I flew 202,717km, visiting 28 cities in 12 different countries, maintaining an average speed of 23km/h over the year.

I’m looking forward to an exciting 2019, I hope your 2019 will be excellent, too. Happy New Year, everyone!

Iterating on Merge Proposals

Developing new WordPress features as plugins has been a wonderfully valuable process for all sorts of features to come into being, from the MP6 Dashboard Redesign, to oEmbed endpoints, and including multiple Customiser enhancements over the years. Thanks to the flexibility that this model offers, folks have been able to iterate rapidly on a wide range of features, touching just about every part of WordPress.

The “Features as Plugins” idea was first introduced during the WordPress 3.7 development cycle, during which the features were merged after a short discussion during a core chat: it was only in the WordPress 3.8 cycle that the idea of a merge proposal post (called “Present Your Feature” back then) came into being. It was envisioned as a way to consult with WordPress leaders, key contributors, and the wider WordPress community on the readiness of this feature to be released. Ultimately, WordPress leaders would make a decision on whether the feature was right for WordPress, and the release lead would decide if it was ready for that release.

Since then, most feature plugins have published some form of merge proposal post before they were ultimately merged into WordPress, and they’ve nearly all benefited to some degree from this process.

The merge proposal process has worked well for smaller features, but it struggled with larger changes.

The REST API is a great example of where the merge proposal process didn’t work. The REST API was a significant change, and trying to communicate the scope of that change within the bounds of a single merge proposal post didn’t really do it justice. It was impossible to convey everything that was changing, how it all worked together, and what it meant for WordPress.

I’d go so far as to say that the shortcomings of the merge proposal process are at least partially responsible for why the REST API hasn’t seen the level of adoption we’d hoped for. It’s managed to gain a moderate amount of popularity with WordPress development agencies, and a handful of plugins use it in some ways, but it never really entered into mainstream usage in the ways it could’ve.

In a project that prides itself on being willing to try new ideas, the merge proposal process has remained largely static for many years.

Gutenberg is the first opportunity since the REST API was merged where we can examine the shortcomings of the merge proposal process, and see how we can apply the original intent of it to the Gutenberg project’s scope and long term vision.

Merge Consultation

Over the last six months, Gutenberg project leads have been consulting with teams across the WordPress project. Helping them get involved when they didn’t have any Gutenberg experience, explaining how their focus fit into the vision for Gutenberg, and listening to feedback on where things needed to be improved. In many circumstances, this consultation process has been quite successful: the WordPress Media and REST API teams are great examples of that. Both teams have got up to speed on the Gutenberg project, and have provided their valuable experience to make it even better.

That’s not to say it’s been entirely successful. There’s been a lot of discussion about Gutenberg and Accessibility recently, much of it boils down to what Joe Dolson summarised as being “too little, too late”. He’s correct, the Accessibility team should’ve been consulted more closely, much earlier in the process, and that’s a mistake I expect to see rectified as the Gutenberg project moves into its next phase after WordPress 5.0. While Gutenberg has always aimed to prioritise accessibility, both providing tools to make the block editor more accessible, as well as encouraging authors to publish accessible content, there are still areas where we can improve.

While there’s much to be discussed following WordPress 5.0, we can already see now that different teams needed to be consulted at different points during the project. Where Gutenberg has aimed to consult with teams earlier than a previous feature plugin would’ve, we need to push that further, ensuring that teams are empowered to get involved earlier still in the process.

All feature plugins in the future, great and small, will benefit from this iteration.

Creating a framework for more fluid feedback over the entire lifecycle of a feature project is beneficial for everyone. WordPress teams can ensure that their feedback is taken on board at the right time, project leads gain experience across the broad range of teams that work on WordPress, and projects themselves are able to produce a better resulting feature.

They important thing to remember throughout all of this is that everything is an experiment. We can try an approach, discover the weaknesses, and iterate. We’re all only human, we all make mistakes, but every mistake is an opportunity to ensure the same mistake can’t happen again. Sometimes that means changing the software, and sometimes that means changing the processes that help build the software. Either way, we’re always able to iterate further, and make WordPress fun for everyone.