Disorganized

JavaScript + WordPress Resources

This post has links to the things I spoke about in my JavaScript + WordPress talk at WordCamp Winnipeg today.

I showed and talked about a number of things, but I didn’t provide any links. That’s what blogs are for! Read on:

JavaScript Frameworks

Rest API and JS Themes

  • WordPress.com REST API – can be used today for any WP.com or Jetpack site. Powers Calypso.
  • WP REST API – formerly a feature plugin, recently merged into core to be released with WP 4.7 in December 2016.
  • A Day of REST – a conference dedicated to building things with the REST API
  • Anadama-React – A React-based recipe theme for WordPress
  • Picard – A prototype theme that uses React and WP-API
Standard
Disorganized

RIP Alex King

A giant of the WordPress world passed away last night. Alex King may not been front-and-centre in the WP world these days, but he had an enormous impact in the early years:

For me it wasn’t just core code contributions, his theme competition was a big early showcase for the power of WP theming and was something I learned from and returned to often in my early couple of years working with WP. I later used his Carrington Framework on a few sites and appreciated the thoughtfulness and power that it gave to big WP sites.

I met him briefly at WordCamp San Francisco in 2012, and was mostly just happy that he knew who I was! I remember acting super awkward, but he was really nice and approachable.

If you have any stories to tell about Alex, post them on your blog! I can’t think of a better way to remember him than to let a thousand stories bloom in the form he contributed so much to. His last request was to send remembrances so that his daughter could know who he was. So do that, too.

RIP Alex.

Standard
Disorganized

Free HTTPS For All From The EFF

Although the HTTP protocol has been hugely successful, it is inherently insecure. …we need to move to a future where every website is HTTPS by default.With a launch scheduled for summer 2015, the Let’s Encrypt CA will automatically issue and manage free certificates for any website that needs them. Switching a webserver from HTTP to HTTPS with this CA will be as easy as issuing one command, or clicking one button.

I’ve wanted to acquire a TLS certificate for my personal sites for a couple of years, but, as the launch post says, “The biggest obstacle to HTTPS deployment has been the complexity, bureaucracy, and cost of the certificates that HTTPS requires.” I even tried to get a free cert from StartSSL, but I was quickly bewildered. The Let’s Encrypt project—and its one-click ease-of-use—sounds awesome.

Standard
Disorganized

What’s New for Web Developers in iOS 8

Here’s a big rundown of iOS 8 and iPhone 6 for web developers and designers, with an excellent summary to kick things off. I’m excited to see that Promises, SPDY, and WebGL have been implemented, amongst a fairly nice-looking list of things.

Breaking uploads was pretty rubbish though.

These lists are a big deal because Safari is now the most important browser with a long (generally one year) update cycle. Unless Apple drops an iOS 8.1, we won’t see anything new for quite a while.

Standard
Disorganized

Buh-Bye YUI

YUI admitted today what has actually been the case for quite some time: YUI is dead. I always remember seeing YUI as a curiosity when everyone was gushing over jQuery, but in a lot of ways they were ahead of their time in promoting things like modularity.

Cheers YUI, even though I never used you, I can tell that some smart people worked hard on real problems in a way that paved the way for the rich JS ecosystem emerging today.

Standard
Web Development

You Should Learn JavaScript

My Automattic colleague Beau Lebens says that JavaScript is the next (or first) programming language you should learn, and I couldn’t agree more. His reasons are great, but his conclusion resonated with me:

…there’s never been a better time to get started with coding, and if you’re going to do it, I suggest starting with JavaScript. Start small, work your way up. View Source. Get on Github. Go nuts.

It’s the “never been a better time” part that really resonated with me. You could argue that I missed the boat on the early days of the web: I hacked together some web pages in the Netscape 1–3 era and gave up when this intimidating DHTML thing showed up. I didn’t understand the difference between JS the language and JS the interface to the utterly bewildering, buggy, non-standardized DOM.1 There were no resources, and definitely no browser compatibility, as the browser wars continued to escalate.2

Fast forward 17 years (!) later, a return to a love of building for the web, and now JS is the most interesting thing to me, the very thing that drove me away from web development initially. It started with jQuery and its simplification of the DOM, but that just proved the gateway into eventually diving deeper into JavaScript proper, and beginning to understand that there was even a difference between DOM and JS (much as WordPress did with PHP for me). If you’re reading this on a modern desktop browser, you have everything you need to start playing around with JavaScript. There’s loads of resources out there (like Khan Academy) to get you on your way.

  1. Ditto for basically everyone else for at least another decade. ↩
  2. “Best viewed in ___” anyone? ↩
Standard
WordPress

Evolving the Customizer

The Customizer is great. I’ve been working in and around it to offer site customization features to our WordPress.com users since it launched with 3.41, coinciding with when I joined Automattic on Team Custom. We’ve especially used it to build great tools as part of the Custom Design upgrade, but as we’ve pushed the boundaries of what awesomeness we can unlock for our users, certain aspects of the Customizer have started to create roadblocks for us. Some of these are addressable, and some probably aren’t.

Mobile

The Customizer doesn’t work on a phone/small screen. Anyone who thinks this isn’t a dealbreaker is just wrong. The UI was designed for the desktop web. This could possibly be addressed in core, but it will require a pretty fundamental rethinking of the interface.

Performance

The Customizer can get really slow. This is partly because of its two-requests-to-load model: one for the customize.php app, and one for the frontend XHR that gets injected into a preview iframe. Any slowness on your server is multiplied x2 since there are two requests that happen serially.2 We’ve seen this hit up to 60 seconds on WP.com sometimes3, with similar reports from WP.org users on underpowered hosts like GoDaddy. Some performance work could probably be done here to start fetching the frontend sooner in the customize.php load process.

Speed could possibly be better served by a more fundamental rethink: what if the user wants to start customizing from the frontend of their site and clicking Customize just transitioned you seamlessly into a customization mode via an already bootstrapped, frontend customizer app? This actually has some serious UX considerations I’ll touch on later, but the big advantage for performance is that you’re not throwing away a perfectly good DOM to get the Customizer up and running.

Speed will also be hampered as more things are put in the Customizer. Putting Widgets in there in 3.9 is a great example of this: it’s made Widgets better, but the Customizer worse. As more things are added, speed will suffer, not to mention the UX cost of dumping so much in there.

Uncanny Valley UX

You can enter the Customizer through wp-admin or the frontend of your site via a Customize link in the adminbar. In both cases, the transition begs the question: am I still where I started? Is this admin, or my site? I believe that we should optimize for the frontend flow, where the app is bootstrapped and the Customizer becomes an editing mode you can seamlessly enter. Frontend editing for appearance.

WP Tunnel Vision

One thing we’ve seen in our user testing is that users (especially new ones) don’t care about or really understand the distinction between themes and the things you can do to customize them. They just want to get their site looking the way they want it to look. Therefore, the best customizer UX would blur the line between themes and customize-able options, freely allowing you to preview different “designs” (themes) while then tweaking that theme’s options. The Customizer’s current architecture would make this impossible, as the Customizer “app” itself must do a full refresh for each theme previewed, kicking off the slow 2-request cycle.

Architecture

The Customizer is the first true JS-driven feature in core.4 It reimplements a bunch of Backbone internally, since this was a release before Backbone made it into core. It’s also a JS-driven app wrapped around a PHP-only public API,5 which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen. If the Customizer is going to be awesome, it needs to a seamless way to customize how your site looks – themes vs theme options are just implementation details.

Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.6

Patches Welcome

Some folks might be reading this and wondering why I’m not trying to contribute this vision to core. ‘dI love to, but I don’t think it’s possible architecturally, and particularly not in a backwards compatible manner. This is certainly a case where the optimal use-case on WP.com (new user signup, pre-picked list of themes) may not line up with the best user experience for core users. I might be wrong about this, thus this post. I would genuinely love to be wrong, but I’ve worked with the Customizer extensively over the past two years and I’m pretty sure I’m not.

  1. Actually, 3.4 dropped on June 13, 2012, but we launched the Customizer for WP.com users on May 17. ↩
  2. Also, since the preview iframe just gets the frontend request injected upon XHR completion, any browsers’ optimizations to do things like prefetch resources like images or DNS entries before the page has even started rendering are nullified. The frontend also tends to be the more resource-intensive side of things, which compounds the problem since it’s loaded last. ↩
  3. Obviously there are issues for us to address here, but the previous footnote contains some gotchas that can’t be addressed in the current architecture. ↩
  4. As in, without JS, it just doesn’t work. Until then, everything else in core admin worked with JS disabled. ↩
  5. Many aspects of the JS API are “public” in the sense that they’re not hidden inside a closure, but they are not documented anywhere on the Codex that I’ve seen. I’ve even spoken about this. ↩
  6. Maybe I will customize my blog from my fridge. ↩
Standard

20140413-213305.jpg

Coming together.

Disorganized

More Kitchen Progress

Image

20140412-180413.jpg

Starting to actually feel like a home.

Disorganized

Kitchen in Progress

Image