Advanced Javascript development in core

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Advanced Javascript development in core

Eric Andrew Lewis
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
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

K.Adam White
This is *awesome*, thank you for broaching the topic.

I'm very excited to check out the documentation plugin; I'm pretty familiar
with JavaScript, but WordPress is already a large JS codebase and I still
find it hard to make sense of how we do things. This looks like a very
smart and community-oriented way to begin opening up that black box to more
contributors. To paraphrase Siobhan McKeown, the more types of
documentation we have for the JS, the better! API docs and reading through
code barely work even for me, so I'd definitely support more plugin-style
documentation. We've also talked in the past about having more
usage-oriented JavaScript information in the handbook—whether or not that's
the right place for it, if we could put together some common use-cases for
the core JS code we can illustrate how those problems would be tackled.

The question of application framework is an interesting one. I'm lucky to
work with both the creator of LayoutManager
<https://github.com/tbranyen/backbone.layoutmanager> and one of the
Marionette team members, and will ask them for some feedback on this.

This may be premature, but a couple times now at WordCamps I've discussed
the possibilities of having a JS-oriented WordPress event: part lectures,
part contributor day, possibly part training. I'd be interested in helping
to organize something like that, if it's of interest to the community; I
know we'll touch on these things at the dev summit, WCSF, and so on, but it
might be easier to work through some of the architectural questions in
person. It'd also give us a venue to pull in experts from outside the
traditional WP community to discuss the framework question.

Long story short, count me in—and I'll see how many folks I can drag along
with me!

K. Adam White
[hidden email]
401.575.7829


On Sat, Jun 28, 2014 at 9:33 AM, Eric Andrew Lewis <
[hidden email]> 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
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

jayarjo
In reply to this post by Eric Andrew Lewis
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
<[hidden email]> 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
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

Chloé Desoutter
Hi,

I completely approve of what Davit says. Altering the JS-bound behaviours
in WordPress is a pain. JavaScript is callbacks-native, so splitting the
different functionalities properly and working with hooks, events and
actions would not be a huge functional change and would allow for extending
functionalities cleanly w/o having to base our work on plug-ins. As an
example, I wanted to add a second featured image to posts : duplicating the
core feature was a pain as all was tightly bound to given DOM items and
this was not documented.

I would not like WordPress too tightly bound to a high-level, full-featured
third party product. This would mean dependency on a third party,
commitment to either upgrading WordPress as the third-party API evolves or
to ensure ourselves that a given subset of the API is stable. Maybe it's
too early with such technologies. I don't want to promote the "Not Invented
Here" doctrine but with such "new" technologies it's better to be careful
and to build things slowly, checking what the practices of the community
are before commiting the whole WordPress stack to a given tech choice.

Yours sincerely




2014-06-29 12:45 GMT+02:00 Davit Barbakadze <[hidden email]>:

> 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
> <[hidden email]> 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
> > [hidden email]
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

Eric Andrew Lewis
Kadam - agree on all points. Maybe Bocoup wants to host an event this fall? Otherwise we’d be glad to host here in New York. Discussion will definitely happen at WCNYC contributor day/weekend in August, as we’ll have Gregory Cornelius, Scott Taylor, myself and others around. Hope you’re coming to that!  

Regarding hooks in JS, I agree this will be the pathway to customizing JS-driven UI. See #21170 (https://core.trac.wordpress.org/ticket/21170) and Carl Danley’s WP JS Hooks (https://github.com/carldanley/wp-js-hooks) which is a fine implementation in my opinion.  

Chloé - thanks for your thoughts on not coupling too tightly with a third party product, and I agree. We would not adopt a framework that does not match our project’s philosophical and practical goals. However, instead of blanket statements, specific feedback about the software at hand is probably more helpful (see Consider a CSS preprocessor (http://make.wordpress.org/core/2013/11/05/22862-consider-a-css-preprocessor/)).

--  
Eric Andrew Lewis


On Sunday, June 29, 2014 at 8:29 AM, Chloé Desoutter wrote:

> Hi,
>  
> I completely approve of what Davit says. Altering the JS-bound behaviours
> in WordPress is a pain. JavaScript is callbacks-native, so splitting the
> different functionalities properly and working with hooks, events and
> actions would not be a huge functional change and would allow for extending
> functionalities cleanly w/o having to base our work on plug-ins. As an
> example, I wanted to add a second featured image to posts : duplicating the
> core feature was a pain as all was tightly bound to given DOM items and
> this was not documented.
>  
> I would not like WordPress too tightly bound to a high-level, full-featured
> third party product. This would mean dependency on a third party,
> commitment to either upgrading WordPress as the third-party API evolves or
> to ensure ourselves that a given subset of the API is stable. Maybe it's
> too early with such technologies. I don't want to promote the "Not Invented
> Here" doctrine but with such "new" technologies it's better to be careful
> and to build things slowly, checking what the practices of the community
> are before commiting the whole WordPress stack to a given tech choice.
>  
> Yours sincerely
>  
>  
>  
>  
> 2014-06-29 12:45 GMT+02:00 Davit Barbakadze <[hidden email] (mailto:[hidden email])>:
>  
> > 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
> > <[hidden email] (mailto:[hidden email])> 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 (http://ericandrewlewis.com)
> > > 610.715.8560
> > > _______________________________________________
> > > wp-hackers mailing list
> > > [hidden email] (mailto:[hidden email])
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > >  
> >  
> > _______________________________________________
> > wp-hackers mailing list
> > [hidden email] (mailto:[hidden email])
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >  
>  
> _______________________________________________
> wp-hackers mailing list
> [hidden email] (mailto:[hidden email])
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>  
>  


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

Funkatron
In reply to this post by Eric Andrew Lewis
Another place that needs work related to Javascript development is the image editor that's built into attachment pages and the image details modal.  There is a lot of archaic code in this: the html elements have hard coded event attributes and suffer from iditis.  The code is also seriously coupled to the page its on.  They added a view to make it work in the image details modal but its just a wrapper for the current code.  I would love to see this as a proper Backbone view where you just put in an attachment model and you are on your way.
Reply | Threaded
Open this post in threaded view
|

Re: Advanced Javascript development in core

Christian Wach
In reply to this post by Eric Andrew Lewis

On 29 Jun 2014, at 14:19, Eric Andrew Lewis <[hidden email]> wrote:

> Carl Danley’s WP JS Hooks (https://github.com/carldanley/wp-js-hooks) which is a fine implementation in my opinion.  

Agree. I'd love to see this in core.

Cheers,

Christian

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers