[wp-hackers] Advanced Javascript development in core

[Davit Barbakadze]

I think one thing that you guys can do, is providing hooks -
structured, namespaced javascript events for all kind of things and
interactions that happen on client side. That alone can hugely improve
the situation.
Davit Barbakadze


On Sat, Jun 28, 2014 at 5:33 PM, Eric Andrew Lewis
<eric.andrew.lewis at gmail.com> wrote:
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers