In attendance: koopersmith, Chris Hobertsen(?), getsource, George Stephanis, duck_, Kailey, lessbloat, Andy Peatling, Dougal, azaozz, Kurt Payne, Matt, Amy Hendrix, Tenpura, Koke, mdawaffe.

JavaScript in WordPress – Woo!

Koop has found that most WP/PHP devs are not comfortable with JS. What are the causes?

• History as a language.
• Grabbing what works.
• Browser incompatibility.
• Programmers with strong belief in good/clean code now have a bad opinion of JS.

All WP devs should feel comfortable with JS: reading certainly, writing too. This includes familiarity with JS libraries we use: jQuery, Backbone.

Other sources of confusion:

• Prototypal inheritance
• event based
• functional programming.

How to teach: make developers use it. WP is including more and more JS APIs that devs will need to get comfortable with.

It would be helpful if everything in WP is consistent. There are many different ways of writing JS in WP.

Koop said that there is a one true way and we’re working on standardizing that and getting all the old stuff cleaner. He suggested a style guide for the contributor handbook.

Shredder noted that the JS in cored didn’t fit the original PHP style.

Matt asked who has contributed a JS patch to WP? ~90% of the table. He said that it’s important that the JS stuff is as inclusive as our PHP code.

How about Backbone: ~15% of the table.

Underscore: ~20%.

Backbone is the future of MVWTF in WP.

Matt said that we adopted jQuery as it makes JS easier for us PHP devs. Backbone hasn’t made anything easier for us WP devs since WP isn’t MVC based anywhere else.

Koop said that WordPress sort of is MVC based, we just don’t notice. Posts are not tied to themes. Our JS should be similar.

Ruby/Python: 35%

Underscore adds more functional methods to JS. Filter, first, iteration, mapping, flatten, event throttle, event debounce + simple templating. Good utility library: well documented. ~800 lines.

Backbone is built on top of Underscore. There are conventions that keep your APIs consistent. ~800 lines. Event handling. Models: Key Value + Listeners (change:key_name). Simple means of interacting with REST API (not used much by WP since we have no REST API).

Collections: Ordered list of Models. filter, first, etc. Events for adding/removing/changed models. “Tell me any time any model changes it’s X”.

View: Convention: Root element (specific element, tag/classname so that it will build for you), render method that does nothing by default. You are responsible for writing to fill up your root element with stuff. Root element’s parents, DOM irrelevant. Just build it, listen to events, whatever: don’t care where it is: ensures your logic is compartmentalized and specific to your task at hand.

Lessbloat: What’s a simple example?

Duck: The API documentation isn’t good enough. We need this explanation of Koop’s for everyone.

Peatling: I know a good tutorial: http://bit.ly/zT9WyG

Matt: When we build an interface with Backbone, how do we make it accessible and degrade down to HTML?

Koop: Same principles: make sure tab indices make sense, etc. Many platforms require you to “pollute” your HTML with custom attributes etc. Beauty of backbone is that it’s minimal and doesn’t invade your HTML. You control the render(), you pick your tempting engine, etc. A designer can do CSS without having to know backbone. Not that much magic going on.

In terms of degrading to no-JS experience, you can cross compile templates in both JS and PHP. WordPress doesn’t do that much, largely because where we currently use it is JS only anyway: TinyMCE, Customizer, etc.

We shouldn’t be using Backbone for everything, but it’s a good tool.

But for media, for example, if we didn’t use backbone, we’d have ended up writing backbone anyway. Backbone’s knocked out the edge cases, has documentation, has community. Using it has sped up WordPress development. We just need to get people used to it and get more people contributing.

Lessbloat: Take media as an example. Is there one small piece of it I can look at to teach myself what’s going on?

Duck/Koop: Models are the best fleshed out. Attachment Model is a good one to check out.

Old Bad way: AJAX returns HTML for attachment. Have to parse that, regex, string compare for errors, never stored anywhere convenient client-side, …

New Good way: AJAX/Deferred returns JSON. Putting that in a Backbone model makes it easy to keep track of everything. Change the model in one place, easy to update all the dependent views.

There exists a WP PHP code style. Is there a styleguide for JS? (Koop: Yes – working on getting it in the handbook).

What about JavaScript Unit Tests?

Koop: I would love it. I suggest QUnit: good for browser unit testing, easy to implement/use.

Our build process is very simple. Just minifies. It’d be cool if we had something more sophisticated: grunt (Ben Alman). Integrates with test suites. Koop talked to Ben at the jQuery summit about blockers for using grunt in WP. Will be resolved in the next release. Also wants to show how plugin/themes can use grunt too.

Old school devs: don’t want to touch JS.

Koop: Agreed. We want to expose people to these new tools and show them WordPress is doing exciting things.

Matt: We have this exciting thing, but only 3 people are doing anything with it – that’s the problem.

LESS/SASS precompiling? Maybe. There is a barrier to entry. We already have a perception that JS is either ugly or hard 🙂

Koop: The problem may not be JS, but that where we’re using JS right now is this big new thing: Media. How many people would be comfortable building that from the ground up? Maybe iterations, when it’s already built, will encourage more involvement from more community members.

We’ve tried to write really good inline docs, good commit messages, etc. so that people can pick things up more easily.

Koop wants to take a pass through all WP JS and document them inline.

Koop showed us Docco for JS. Matt said that we should have that for PHP too. Easy to see what code isn’t documented: too much whitespace!

Kurt suggested a make/js blog?

Koop has thought about it.

Matt: Why not just post to core? Don’t separate.

They agreed to use a JavaScript tag?

Shredder: What about mentorship? That was super helpful for me when I started in WP. Can we pair less/more experiences JS folks up?

Koop would love to mentor interested people to bring them up to speed.

Matt: Yes. Expand our workforce: it’d be nice to get more than one JavaScript heavy feature per release.

Kurt: We don’t have a real QA system. Is that the bottleneck with JS features?

We’ve never had QA for anything – probably not the issue.

Koop: we do need more tests. Headless browser, etc. Use the tools that already exist rather that building our own system. Higher learning curve, but faster in the medium/long term.

Action Item

Post to “javascript” tag in make/core.

Other Ideas:

• Links to resources
• JS Styleguide in handbook and Codex
• Best practices on passing data back and forth between PHP and JS.