In attendance: koopersmith, Chris Hobertsen(?), getsource, George Stephanis, duck_, Kailey, lessbloat, Andy Peatling, Dougal, azaozz, Kurt Payne, Matt, Amy Hendrix, Tenpura, Koke, mdawaffe.
JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. in WordPress – Woo!
Koop has found that most WP/PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.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. FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., 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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.?
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 CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. 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, CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings., 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 JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? 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.