Eric Andrew Lewis
2014-06-28 13:33:41 UTC
I've been working on the media grid feature for 4.0, and would like to talk
about Javascript in WordPress.
Our recent Javascript developments have been undoubtedly great for users.
The Media modal is the strongest UI change we've made in recent years (not
counting MP6 which was really a fresh coat of paint). However, becoming a
core javascript developer has a steep learning curve, and working with any
of the media code has confounded most WordPress developers.
There's reason to this - you can create top-notch themes and plugins with a
wheelhouse of PHP/CSS/HTML, without diving deep into modern Javascript
practices.
Even if that is the case, we should make a better developer experience in
our Javascript stack, and transition WP developers into an era of
Javascript development smoothly.
The biggest changes we should make are discussing architectural decisions
and documentation.
*Architectural decisions*
How we structure our MV* objects is terribly important. In media and theme
experience, we combine top-level controllers with the top-level views.
Should we be doing this? I don't particularly think so. We should nail down
general module structure, so that when you switch from one module to
another there's familiar architecture. Essentially, we need a City Planning
department for our Javascript.
We need to recognize that we're still just out of the starting gate with
our Javascript modules. Could you imagine if you had the opportunity to
discuss the creation of WP_Query in 2005? That's where we are.
*Documentation*
Without documentation it's just interpretive dance. We probably shouldn't
accept code to core that doesn't have enough documentation - although that
begs the question "what is enough?"
I made an interactive documentation plugin for Media
<https://github.com/ericandrewlewis/wp-media-javascript-guide>, with live
examples in the browser right next to the boilerplate code. Maybe we should
consider more documentation that sits inside of WordPress, rather than
abstracting it out.
*Application Framework*
We currently use Backbone.js as an MV* utility library, and build
abstractions on top of it. There are a slew of application frameworks on
the JS scene, including Marionette.js which builds on top of Backbone. Do
you think we should adopt one? We are reinventing the wheel in a lot of
ways. We roll our own region management, custom events bussing, and
handling subviews - all out of the box in any app framework. We can
eliminate boilerplate by using composite/collection views, and provide for
more reusable subcomponents with something like behaviors
<http://marionettejs.com/docs/marionette.behavior.html>.
Eric Andrew Lewis
ericandrewlewis.com
610.715.8560
about Javascript in WordPress.
Our recent Javascript developments have been undoubtedly great for users.
The Media modal is the strongest UI change we've made in recent years (not
counting MP6 which was really a fresh coat of paint). However, becoming a
core javascript developer has a steep learning curve, and working with any
of the media code has confounded most WordPress developers.
There's reason to this - you can create top-notch themes and plugins with a
wheelhouse of PHP/CSS/HTML, without diving deep into modern Javascript
practices.
Even if that is the case, we should make a better developer experience in
our Javascript stack, and transition WP developers into an era of
Javascript development smoothly.
The biggest changes we should make are discussing architectural decisions
and documentation.
*Architectural decisions*
How we structure our MV* objects is terribly important. In media and theme
experience, we combine top-level controllers with the top-level views.
Should we be doing this? I don't particularly think so. We should nail down
general module structure, so that when you switch from one module to
another there's familiar architecture. Essentially, we need a City Planning
department for our Javascript.
We need to recognize that we're still just out of the starting gate with
our Javascript modules. Could you imagine if you had the opportunity to
discuss the creation of WP_Query in 2005? That's where we are.
*Documentation*
Without documentation it's just interpretive dance. We probably shouldn't
accept code to core that doesn't have enough documentation - although that
begs the question "what is enough?"
I made an interactive documentation plugin for Media
<https://github.com/ericandrewlewis/wp-media-javascript-guide>, with live
examples in the browser right next to the boilerplate code. Maybe we should
consider more documentation that sits inside of WordPress, rather than
abstracting it out.
*Application Framework*
We currently use Backbone.js as an MV* utility library, and build
abstractions on top of it. There are a slew of application frameworks on
the JS scene, including Marionette.js which builds on top of Backbone. Do
you think we should adopt one? We are reinventing the wheel in a lot of
ways. We roll our own region management, custom events bussing, and
handling subviews - all out of the box in any app framework. We can
eliminate boilerplate by using composite/collection views, and provide for
more reusable subcomponents with something like behaviors
<http://marionettejs.com/docs/marionette.behavior.html>.
Eric Andrew Lewis
ericandrewlewis.com
610.715.8560