[wp-hackers] 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 <jayarjo at gmail.com>:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>